Pages Report

The Pages Report reveals the status and evolution of the speed for measured URLs.

It answers questions such as:

• How are we doing with the speed of the measured URLs now, and what is the trend?
• Were optimizations of specific URLs successful?
• Which pages have the greatest impact on the speed changes of the entire domain?

The Pages Report is among the advanced tools. It's particularly appealing to those wishing to delve deeper into the web's speed – typically developers and other speed optimizers.

For website owners and other managers, it may be more suitable to follow the Domains Report.

Status of synthetic metrics (above) and the LPS metric trend for one of the measured websites.

Before diving further, ensure you have these essentials in mind:

• It's crucial to know the differences between various types of speed measurements. The Pages Report utilizes data from synthetic measurements and Google's user data (CrUX).
• You should also understand how we measure web speed in our monitoring.
• We highly recommend properly configuring the measured pages.
• It's also useful to know how the Domains Report or Speed Watchdog functions.

Got it? Let's continue.

Watchdog vs. Domains vs. Pages#

Let's first clarify the relationship between these three major reports in our speed monitoring.

The Watchdog monitors the speed of URLs you have set up and notifies you in case of any improvement or deterioration. It uses synthetic data, so it has very current figures but may not be entirely precise.

The Domains Report cannot report day-to-day changes because it uses data from the Chrome UX Report (CrUX). These are, on the other hand, very accurate, so every Watchdog report is worth verifying with this data. However, Google's user data does not reveal which specific parts of the website are changing.

The Pages Report, once again, does not report changes but allows you to look at which specific URLs caused the changes after each Watchdog report.

How to navigate to the problematic page that's slowing you down? Click on the graph in the Watchdog, then on the link to the Pages Report in the modal window.

The Pages Report displays the status and evolution of metrics for all measured URLs, both for synthetic metrics and Google's user data (CrUX).

🔐 Google's user data (CrUX) for pages is only available in Speed Monitoring PLUS.

What if some URLs lack user data?#

It's quite common that data for some URLs is unavailable or only available for certain periods.

Above, it shows that some pages may not have CrUX data at all. Below, we see a situation where data is only available for certain specific days.

To display data from the Chrome UX Report, pages must meet a certain traffic threshold. It's common for smaller websites to have CrUX data for only a few types of pages.

In the Monitoring Settings documentation, we provide tips on finding better pages that have Google user data.

It's necessary to say that for many websites, you simply won't have this data. That's why synthetic data is also displayed here.

Individual Graphs and Their Significance#

The Pages Report is divided into two tabs: User Data and Synthetic. Above the tables and graphs, you can switch between Mobile and Desktop and select the time period (for user data: 1 month, 3 months, 1 year; for synthetic data: an additional 7 days).

User Data displays metrics from the Chrome UX Report (CrUX) – measurements from real Chrome users. They are more precise but only available for pages with sufficient traffic and cumulatively over 28 days. Synthetic displays data from Lighthouse tests: more metrics and the status for the current day, but without real users, they are not as precise.

User Measurements for Pages#

The data comes from the Chrome UX Report and is available only for pages with a certain amount of traffic. They show the speed very precisely for all Chrome users, but are available only cumulatively for the last 28 days. Google does not provide data for all pages by any means.

In the User Data tab, you will find:

1. Summary – a table of current metric values for each measured URL, color-coded (complies / needs improvement / does not comply).
2. 75th Percentile – a line graph of the development of the 75th percentile over time for each metric (a simple expression of distribution with a single number).
3. Distribution – bar graphs for each metric showing the percentage share of states complies / needs improvement / does not comply for all users; it provides a more detailed view than the 75th percentile.

Here you see the status and development of these user metrics:

• PageSpeed.ONE Score (SPS) – overall speed score derived from CrUX.
• Backend (TTFB) – backend time, meaning server code and infrastructure.
• First Contentful Paint (FCP) – the first rendering of anything on the user's screen.
• Largest Contentful Paint (LCP) – the first largest content element.
• Interaction to Next Paint (INP) – response speed for interactions like clicking.
• Cumulative Layout Shift (CLS) – the sum of unwanted layout shifts on the page.

Synthetic Measurements for Pages#

The status of metrics and their development for URLs specified in the test. The data here comes from Lighthouse tool tests (see how we test). They are available for the specific measurement day and each URL measurement, but may not be accurate, as they do not come from users.

Here you can see the status and development of the following metrics from synthetic measurement:

• Lighthouse Score (LPS) – overall speed score.
• Backend (TTFB) – backend time, meaning server code and infrastructure.
• First Contentful Paint (FCP) – the first rendering of anything on the user's screen.
• Largest Contentful Paint (LCP) – the first largest content element.
• Total Blocking Time (TBT) – the time during which the browser is blocked by executing frontend code.
• Third-Party Total Blocking Time (3PBT) – the time during which the browser is blocked by executing third-party frontend code.
• Cumulative Layout Shift (CLS) – the sum of unwanted layout shifts on the page.

Notes on Metrics and Their Differences#

You might have a few questions when looking at the metrics above, so let's address the most common ones:

1. Why do different types of measurements contain different metrics? The metrics in the user and synthetic sections differ because some can only be obtained from real users (INP) and others only synthetically (LPS, TBT).
2. Why do different types of measurements return different values for the same metrics? The values of metrics obtained from users can vary. For example, CLS is calculated synthetically only during the initial page load, but for users, it's throughout the session.
3. There are many metrics, what should I focus on? Primarily focus on the user values (i.e., CrUX) of the Core Web Vitals metrics (LCP, CLS, INP).

Summary#

What should you remember about the Pages Report?

• The report serves for detailed tracking of metric development for measured URLs.
• It is crucial to carefully select URLs in the settings.
• The Pages Report is more suited for developers and other technicians who wish to dive deeper into speed.
• Even though metrics have the same names, values from different sources can differ.
• Primarily look at Core Web Vitals from CrUX data.

Want to understand the measurement as a whole? Our article on How We Test and the Test Run Detail with the PageSpeed.ONE tester offers a complete guide.