You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Observatory overview dashboard provides a single view of your zone's performance over the past seven days. It combines synthetic monitoring, real user data, and Cloudflare's analysis to help you quickly identify performance bottlenecks and receive actionable recommendations.
9
+
10
+
## Suggestions
11
+
12
+
The **Suggestions** panel highlights tailored optimizations you can make to improve performance. Examples include:
13
+
14
+
- Reduce Largest Contentful Paint (LCP) with Polish.
15
+
- Reduce Time to First Byte (TTFB) with Argo Smart Routing.
16
+
17
+
These recommendations will vary based on your site's observed performance.
18
+
19
+
Selecting a suggestion expands it to show more detail:
20
+
21
+
-**Why you're seeing this**: Explains the performance issue detected.
22
+
-**What you can do**: Lists recommended actions you can take.
23
+
24
+
## Core Web Vitals
25
+
26
+
The dashboard integrates **Core Web Vitals**, showing values at the 75th percentile (p75). These metrics reflect real user experiences:
27
+
28
+
-**Largest Contentful Paint (LCP)**: How quickly the main content of a page becomes visible.
29
+
-**Interaction to Next Paint (INP)**: How responsive the site is to user interactions.
30
+
-**Cumulative Layout Shift (CLS)**: How visually stable the page layout is.
31
+
32
+
If insufficient real user data is available, metrics may show as **No data**.
33
+
34
+
## Network Performance
35
+
36
+
The **Network Performance** section shows timing data that can help pinpoint where latency occurs.
37
+
38
+
-**Time to First Byte (TTFB)**: Measures the time between the initial request and the first byte of the response.
39
+
-**Time to Last Byte (TTLB) Breakdown**: Provides a breakdown of response phases:
40
+
41
+
- DNS resolution time
42
+
- TCP connection time
43
+
- Request processing time at the server
44
+
- Response transfer time
45
+
46
+
This breakdown helps identify whether delays are caused by DNS, connection setup, server processing, or response delivery.
47
+
48
+
## HTTP Traffic
49
+
50
+
The **HTTP Traffic** section shows how traffic is handled between Cloudflare and your origin server:
51
+
52
+
-**Served by**: Percentage of requests served from Cloudflare versus from your origin.
53
+
-**4xx errors**: Client errors, broken down by Cloudflare edge versus origin.
54
+
-**5xx errors**: Server errors, broken down by Cloudflare edge versus origin.
55
+
56
+
This view helps distinguish between Cloudflare-side issues and origin-side issues.
57
+
58
+
## Synthetic Monitoring
59
+
60
+
The **Synthetic Monitoring** table shows automated test results for your site. Each row includes:
61
+
62
+
-**URL tested**
63
+
-**Last test run**
64
+
-**Repeats** (if scheduled multiple times)
65
+
-**Score** (Pass/Fail)
66
+
67
+
Synthetic monitoring allows you to proactively test site availability and performance under consistent conditions, complementing real user monitoring (RUM).
68
+
69
+
## Using the dashboard
70
+
71
+
Use the Speed Overview dashboard to:
72
+
73
+
- Review **Suggestions** for actionable optimizations.
74
+
- Track **Core Web Vitals** to ensure a good user experience.
75
+
- Analyze **Network Performance** to identify latency bottlenecks.
76
+
- Diagnose errors with **HTTP Traffic** insights.
77
+
- Confirm site reliability using **Synthetic Monitoring** results.
Copy file name to clipboardExpand all lines: src/content/docs/speed/observatory/faq.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,14 +31,14 @@ Check your WAF custom rules to make sure that you are not blocking traffic from
31
31
32
32
There are several reasons why users might not see any Real User Monitoring (RUM) data on the map in Observatory:
33
33
34
-
- Limited Traffic to Specific URL Paths: When users see the map in Observatory, they are filtering data by a specific URL path. If there is no traffic to that particular path, there will be no corresponding RUM data available to display on the map.
35
-
36
34
- Time Required for RUM Data Population: Populating the RUM database takes some time. It means that newly enabled RUM might not have immediate data available, and users may need to wait for some time before RUM data starts appearing on the map.
37
35
38
36
- Progressive Sampling: RUM data is progressively sampled, which means that not all requests are captured. Some requests may pass through the sampling period, resulting in incomplete or missing data points on the map.
39
37
40
38
- Adblockers Impact on RUM Data: RUM data collection relies on third-party JavaScript executing on the real-user browser. However, adblockers or similar browser extensions can block this script, preventing the collection of RUM data, and thereby affecting the completeness of the analytics presented on the map.
41
39
40
+
- The RUM feature needs to be enabled and configured in your environment. If it has not been turned on, or if configuration is incomplete, RUM data may not appear.
41
+
42
42
## What are the potential reasons for discrepancies between RUM analytics and traffic analytics in Observatory?
43
43
44
44
Differences between Real User Monitoring (RUM) analytics and traffic analytics in Observatory can occur due to the following reasons:
Copy file name to clipboardExpand all lines: src/content/docs/speed/observatory/index.mdx
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,20 @@ Observatory uses synthetic tests and real user data from browsers to assess the
17
17
18
18
As its name suggests, synthetic testing uses servers to simulate the conditions that a user might encounter when accessing your website. This has the advantage of being consistent, as the conditions are easily replicated each time the test is run. It also allows you to have an analysis of how a code change might affect the overall performance of your website, as well as test any URL you want. However, due to its synthetic nature, it cannot replicate the breadth and diversity of different conditions that real users will experience.
19
19
20
+
Observatory provides two different types of synthetic tests:
21
+
22
+
### Browser test
23
+
24
+
The browser test loads the requested page in a headless browser and runs Google Lighthouse on it. This reports key performance metrics and provides light suggestions for improvement.
25
+
26
+
### Network test
27
+
28
+
The network test is focused on giving a detailed breakdown of the network and back-end performance of an endpoint. For more information on metrics collected, refer to [Network monitoring metrics](/speed/observatory/test-results/#network-monitoring-metrics).
29
+
30
+
### Network comparison test
31
+
32
+
You can also compare network tests in Observatory by selecting any two completed tests. The results for each test are displayed side by side as histograms, allowing you to easily visualize and compare the full distribution of data points across both tests.
33
+
20
34
## Real user monitoring (RUM)
21
35
22
36
Real user monitoring (also known as RUM), on the other hand, captures real metrics from real users accessing a website. This provides information that synthetic tests cannot capture, as users might access your website from different parts of the world, with different network conditions, ISPs, browsers and computer hardware. However, RUM data is only applied to your own website. Real user data also includes two user interaction metrics that synthetic tests do not offer - [First Input Delay (FID)](https://web.dev/fid/) and [Interaction to Next Paint (INP)](https://web.dev/inp/).
Copy file name to clipboardExpand all lines: src/content/docs/speed/observatory/run-speed-test.mdx
+69-54Lines changed: 69 additions & 54 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,16 +11,12 @@ import { Render } from "~/components";
11
11
## Run Synthetic test
12
12
13
13
1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/login), and select your account and domain.
14
-
15
-
2. Go to **Speed** > **Observatory**.
16
-
14
+
2. Go to **Speed** > **Synthetic Monitoring**.
17
15
3. Enter the URL you want to test. The URL must belong to the zone you are testing from.
18
-
19
-
4. Select the **Region** the automated browser will use.
20
-
21
-
5. Then, you can select, depending on your plan, **Run test once**, **Run daily test** or **Run weekly test**. Refer to the [Quotas](/speed/observatory/run-speed-test/#quotas) section for information on the test frequency available for your plan.
22
-
23
-
6. After the test finishes running, you will get a Lighthouse score and you will have access to the list of the tests run. The test result page will give you details regarding the performance of your website, both for the desktop and mobile versions. Refer to [Understand test results](/speed/observatory/test-results/) for more information.
16
+
4. Select the test type you want to use: **Browser** or **Network tests**.
17
+
5. Select the **Region** the automated browser will use.
18
+
6. Depending on your plan you can select to run the test **once**, **daily** or **weekly**. Refer to the [Quotas](/speed/observatory/run-speed-test/#quotas) section for information on the test frequency available for your plan. Note that these limits may change over time.
19
+
7. After the test finishes running, you will get a Lighthouse score and you will have access to the list of the tests run. The test result page will give you details regarding the performance of your website, both for the desktop and mobile versions. Refer to [Understand test results](/speed/observatory/test-results/) for more information.
24
20
25
21
<Renderfile="user-agents"product="speed" />
26
22
@@ -36,8 +32,7 @@ In the Tested URLs table, in the last column, you can select the three dots > **
36
32
37
33
Once a test has been run, you can enable RUM data in the test results page:
38
34
39
-
1. In **Real user measurements**, select **Enable Rum for free**. You can always manage your website preferences in the **Web Analytics** section in the dashboard which also uses RUM data.
40
-
35
+
1. Go to **Observatory** and select **Enable Rum**. You can choose to enable globally or enable everywhere except the EU.
41
36
2. Once RUM data is running on your site, you can access **Real user measurements** on your test results page. Usually it takes less than five minutes to see the data coming in, but it will depend on traffic.
42
37
43
38
Refer to [Understand test results](/speed/observatory/test-results/) for more information about the results provided by real user data.
@@ -50,47 +45,67 @@ RUM uses a lightweight JavaScript beacon to collect the information Observatory
50
45
51
46
Quota limits for the number of tests you can run per month are currently the following:
52
47
53
-
<table>
54
-
<tr>
55
-
<th>Plan</th>
56
-
<th>Number of one-off tests</th>
57
-
<th>Number of recurring tests</th>
58
-
<th>Frequency of recurring tests</th>
59
-
<th>Regions</th>
60
-
</tr>
61
-
<tr>
62
-
<td>Free</td>
63
-
<td>30</td>
64
-
<td>1</td>
65
-
<td>Weekly</td>
66
-
<td>Iowa, USA</td>
67
-
</tr>
68
-
<tr>
69
-
<td>Pro</td>
70
-
<td>50</td>
71
-
<td>5</td>
72
-
<td>Daily</td>
73
-
<tdrowspan="3">
74
-
Everything in Free and <br /> - South Carolina, USA <br /> - North
75
-
Virginia, USA <br /> - Dallas, USA <br /> - Oregon, USA <br /> - Hamina,
76
-
Finland <br /> - Madrid, Spain <br /> - St. Ghislain, Belgium <br /> -
| Interaction to Next Paint ([INP](https://web.dev/inp/)) | Aims to represent a page's overall responsiveness by measuring all click, tap, and keyboard interactions made with a page. |
39
-
| First input delay ([FID](https://web.dev/fid/)) | Measures the time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction. |
39
+
40
+
Refer to [Data and metrics](/web-analytics/data-metrics/) for more information about the metrics you can find in the Real User Monitoring dashboard. You can find details about [Core Web Vitals](/web-analytics/data-metrics/core-web-vitals/), the debug view and the data collected.
| Wait Time | Measures the time spent waiting for the server to send back the first byte of a response after a request is made. |
47
+
| Load Time | Measures the total time it takes for a web page to fully load in a user’s browser from the network. |
48
+
| Time to First Byte ([TTFB](https://web.dev/articles/ttfb)) | Measures the duration between initiating a web page request and receiving the first byte from the server. |
49
+
| Server Response Time | Measures the time it takes for a server to respond to a request from a user's browser. |
50
+
| Connect Time | Measures the time taken to establish a connection between the user's browser and the web server. |
51
+
| TLS Time | Measures the time required to complete the TLS/SSL handshake between the user's browser and the web server. |
0 commit comments