To monitor your performance, if you use Google tools ( PageSpeed Insights or Google Lighthouse ), you will have certainly noticed that for the same indicator, the data is different. Why? Which ones should you prioritize to optimize your loading speed? We explain how to find your way around to properly use this information, and improve the performance and speed of your website.
Difference between field data and laboratory data: a question of method
On the PageSpeed Insights results page (whose score is based on Lighthouse ), two families of data coexist, each collected under different conditions.
- Field data : this data is collected over a period of 28 days, from real users from a panel called CrUX . This is Real User Monitoring (RUM). Google is observing the 75th percentile here , which means that in practice, 75% of users have a higher quality experience than what Google reports in PageSpeed Insights. Since it is collected from real users, field data covers a very wide variety of situations: quality and sizes of computer and mobile screens, network quality and variable geographic areas, etc. Note that Google recommends collecting real data yourself , because the insights will be more actionable compared to relying only on the CrUX panel, particularly because this panel does not represent 100% of users.
- Lab data : To display this data, Lighthouse (which serves as the basis for Google’s PageSpeed Insights score) extrapolates the results from a native connection via an algorithm . This is synthetic data, or Synthetic Monitoring . With this data collection mode, the scenarios are limited to the parameters defined for the test: a single type of device, network, and in a given geographic area.
This method is useful, for example, for identifying and fixing bugs.
As you might expect, the fact that the collection methods are different necessarily leads to different results. How can you find your way around, and what can you do to improve your user experience based on these KPIs?
Focus on Core Web Vitals , in order to understand the reasons for the differences between Field and Lab data for these metrics. Note that at the end of 2021, Google announced changes to the design of the PageSpeed Insights interface to make it easier to read and understand the data.
Lighthouse / PageSpeed Insights and Largest Contentful Paint (LCP): why are Field and Lab data different?
Field (top) and Lab (bottom) data: for the same web performance indicators, the results are different due to the data collection context indicated in the gray box
The LCP element is not the same for all users
The most important element on a page, and identified for Lab data to evaluate the Largest Contentful Paint , is not necessarily the same for your visitors in real conditions. Indeed, by doing Lighthouse tests several times on the same page, the LCP element will be identical. On the other hand, for field data, the LCP element will depend on the browsing context specific to each page visit.
Here are some examples of what can cause the LCP element to vary:
- Screen size , which means that not all users see exactly the same content displayed in their browser.
- Whether a user is logged in or not, and the content can then be personalized or not (same in the case of an A/B Test ).
- System fonts installed on the user’s device, which can change the space that text takes up on a given page .
- Testing for Lab data is typically done on a “base” URL . In reality, users often share URLs that contain elements that cause the LCP element to be after the fold ( Fragment Identifiers or Text Fragments ) .
And in practice? As we saw earlier, for Field data, LCP is calculated based on the 75th percentile of all visits to a page. So, if a large percentage of users have a fast-loading LCP element, the page score won’t be affected by those whose LCP element loads slowly – provided that less than 25% of visitors are affected.
Conversely, something like a text block might be identified as LCP on a small screen for Lab data, while the main image is rendered off-screen. However, your Field data might include mostly users with larger screens, and for them, this slow-loading image will be their LCP – with the impact that this has on your score.
The impact of cache state on LCP
Lab data typically corresponds to a page with a “cold” cache , while Field data may correspond to users who already have data cached, and whose loading speed will be better.
Some Synthetic Monitoring tools allow you to test the same page multiple times to simulate the user experience during a “revisit”, however, it is not possible to know the percentage of these visitors for whom data is already cached.
Thus, the LCP in the Field data, for a site with an effective caching strategy, can be much better than that shown in the Lab data.
The impact of AMP or Signed Exchange on LCP
Visitors to sites that use AMP or Signed Exchange (SXG) may experience significantly better loading speed than others.
In addition to cross-origin prefetching, these sites can prefetch content for subsequent pages, which can help optimize for Largest Contentful Paint.
But Lab tools cannot simulate the performance gains achieved in this context, and even if they were able to do so, they could not know the percentage of traffic affected.
The impact of bfcache on LCP
For pages served from a back/forward cache (or bfcache ), loading is nearly instantaneous. This data counts towards your Field test results , but not for Lab data.
The impact of real user interactions on LCP
LCP helps identify the time it takes to display the largest element (text or image), but it can change as the page loads, especially if new content is dynamically added to the viewport .
For Lab data, the browser waits until the page is fully loaded to identify the LCP element; but for Field data, the browser stops detecting the LCP as soon as the user scrolls or interacts.
This principle of calculating LCP makes sense, since on the one hand, a user begins to interact with a page from the moment it appears to be loaded (and not once it is fully loaded); and on the other hand, taking into account an LCP element that would only be displayed following a user interaction would not be relevant.
Therefore, Field data potentially indicates faster LCP based on real user behavior on a page.
PageSpeed Insights / Lighthouse and Cumulative Layout Shift (CLS): why are Field and Lab data different?
The impact of real user interactions on CLS
For Lab data in PageSpeed Insights, Cumulative Layout Shift only considers layout changes above the fold and on load , as this is only a subset of what CLS actually measures.
For Field data from real users, the CLS takes into account any unexpected layout changes throughout its lifetime (such as if elements move as a result of scrolling through content, for example).
Consider the case of lazy loading images or dimensionless iframes : they can generate layout changes following a user scroll . This change only occurs if the user scrolls down the page, and this phenomenon is generally not detectable in Lab data (there is no user interaction in this case).
The impact of personalized content on CLS
Content personalization (including targeted ads, A/B testing, etc.) impacts how elements load on a page, and how they load.
This is because custom content can cause layout changes because it is loaded after the main content, and often inserted dynamically.
It should be noted that Lab data generally corresponds to the performance of a page without personalized content, for an average user.
As for Field data, it is heavily dependent on the amount and degree of layout shift observed from actual users of the site.
The impact of cache and bfcache state on CLS
As we mentioned, images and iframes without dimensions are some of the most common causes of layout shifts. Then there are slow-loading web fonts (which you can easily optimize with Fasterize ).
These phenomena can affect the user experience when first visiting a site, when its cache is empty.
On the other hand, if the resources of a web page are already present in the cache, or in the case of a page served from a bfcache, the images and fonts can be displayed instantly.
So, the CLS score may be better in Field data compared to Lab data.
Why First Input Delay (FID) can only be measured from real users, and why it is different from TBT
To measure FID, user interaction is required.
First Input Delay measures how responsive a page is to user interactions, at the time they are actually interacting.
However, Lab data does not allow us to predict when a user decides to interact with a page, and therefore does not allow us to accurately measure FID.
Other metrics that can be used to assess interactivity with Synthetic Monitoring include Total Blocking Time (TBT) and Time To Interactive (TTI).
Synthetic data does not take into account user behavior
Total Blocking Time (TBT) and Time To Interactive (TTI) help detect FID issues by identifying the degree to which the Main Thread is blocked while a web page is loading.
If a user tries to interact with a page that contains a lot of synchronous JavaScript , for example, there’s a greater chance that the main thread will be blocked by the time they decide to interact.
On the other hand, if a user waits for the JavaScript to finish executing to interact, then the FID may be very low.
In short, the moment when the user chooses to interact with a page is decisive for the FID , and this moment depends a lot on whether the page is interactive or not (which the TBT and TTI cannot assess).
It should also be noted that neither TBT nor TTI take into account the delay following an interaction on a mobile screen, called Tap Delay .
So for a page that is not optimized for mobile viewing, the browser adds a 300ms delay after any tap before executing the event handlers.
Why? Because the browser needs to determine if the user wants to zoom using a double tap before triggering the “mouse” or “click” events. Also, to avoid the Tap Delay issue on a page, it is recommended to always specify a mobile viewport .
This Tap Delay counts for FID because it contributes to the latency phenomenon experienced by real users. But since it is not a Long Task , TBT and TTI are not impacted
As a result, a page may have a bad FID despite very good TBT and TTI scores.
The impact of cache and bfcache status on FID
A good caching strategy can improve FID, just as it can improve LCP.
In real-world browsing conditions, a web page’s JavaScript can be cached, and it takes less time to process , improving loading speed.
The same goes for pages served from the bfcache , as the JavaScript is then fetched from memory. The processing time can then be very low or even zero.
Now that we have seen the different reasons why Field and Lab data can be different for LCP, CLS and FID, you are probably wondering how to choose to measure and optimize your loading speed!
Loading Speed and Core Web Vitals Optimization: How to Choose Between Field and Lab Data?
Let’s not prolong the suspense any longer: give priority to field data !
You should look at Field data to prioritize your user experience optimization efforts.
Indeed, this data reflects the experience of your real users, making it the most appropriate decision-making tool to improve your loading speed, your user experience, and your conversion rates.
Even if your Field data is satisfactory, don’t neglect the Lab data: it can indicate that there is still room for improvement, and it is in your best interest to dig deeper to go further in optimizing your performance.
Our experts are here to help you decipher the subject , and show you how our solution helps you automate all webperf optimizations to transform your site into a real racing car!
It can take just a few milliseconds to see an impact on your revenue. That’s right! Google has noted that just 0.1 seconds less loading time can increase conversions by 8% . So, are you ready to take it to the next level?
Dig deeper into Core Web Vitals, find out what exactly they measure, and how to improve them with pro techniques and tools:
