A website can achieve a high score in Lighthouse, yet still feel slow to some visitors. This situation does not always mean that one of the tools is incorrect. Often, both are measuring different things: Lighthouse tests pages under controlled conditions, while field data reflects real user experiences with diverse devices, networks, locations, and habits.
Understanding this difference is crucial because website optimization should not stop at chasing a score of 90 or 100. The real goal is to make pages load quickly, feel responsive, and be stable for as many visitors as possible.
Lab Data and Field Data: Two Ways to View the Same Problem
Lab data or synthetic data is collected in a specific testing environment. Lighthouse, for example, runs simulations with predetermined devices, connections, and locations. Because the conditions are relatively consistent, this data is very useful for identifying problem sources and comparing the impact of code changes.
Meanwhile, field data comes from real user experiences. This data is often referred to as Real User Monitoring or RUM. Visitors may be using low-end phones, unstable cellular networks, different browsers, or be far from the server. All these conditions can alter the results they experience.
Google uses data from the Chrome User Experience Report or CrUX to describe the experience of Chrome users who meet certain criteria. However, CrUX is not a recording of every website visitor. Therefore, data from the users themselves is usually more relevant for understanding who is experiencing issues and on which pages those issues occur.
Why Can the Numbers Be So Different?
1. Visitor Devices Are Not the Same
Local testing on modern laptops may show JavaScript running quickly. However, the same script could keep a slower phone's processor busy for several seconds. The impact is most noticeable on INP, which measures how quickly a page responds to clicks, taps, or user input.
A good INP is at or below 200 milliseconds at the 75th percentile. If there is too much JavaScript code, event handlers are too heavy, or rendering processes are done all at once, buttons may feel unresponsive even though the page has finished loading.
2. Connection and Location Affect Wait Times
Testing from an office network or fast Wi-Fi does not always represent visitors opening the website over cellular networks. The user's distance from the server, connection build time, DNS processing, and HTML response size can affect LCP or Largest Contentful Paint.
LCP measures when the main content of the page is visible. A good benchmark is 2.5 seconds or less at the 75th percentile. If the main image is only found by the browser after several CSS and JavaScript files have been processed, the real-world LCP result could be worse than the local testing result.
3. Cache Makes Second Visits Feel Different
New visitors typically do not have assets like CSS, fonts, or images cached in their browsers. In contrast, visitors who have opened the website several times may experience a faster load. Lighthouse running specific tests may be closer to first visit conditions, while field data mixes new and returning visits.
This difference is not a reason to ignore cold load testing. The first visit remains important, especially for landing pages, ads, search results, and campaign pages that receive many new visitors.
4. Page Content Is Not Always the Same
Mobile users may see different menus, banners, or images than desktop users. Websites that use personalization, cookie banners, ads, product recommendations, or dynamic content can also produce different largest elements.
This can change LCP. In one test, the largest element might be a hero image. For another visitor, the largest element could be an article title or a promotional block that appears after additional requests are completed.
Don't Fixate on One Number
User data is not just a single score that applies to everyone. Field data illustrates the distribution of experiences. Some visitors may have an LCP of 1.5 seconds, while others experience 5 seconds.
Therefore, Core Web Vitals are typically assessed using the 75th percentile. Simply put, this target aims to ensure that at least most visits fall into the good category, rather than just chasing the best results from a few tests.
In addition to LCP and INP, also pay attention to CLS or Cumulative Layout Shift. CLS measures how often the layout shifts unexpectedly. A score of 0.1 or less is considered good. Common causes of CLS include images without dimensions, ads appearing without prepared space, dynamic embeds, and fonts that change text size after the page displays.
A More Logical Check Flow
- Start with field data. Check PageSpeed Insights, Search Console, or RUM to see if real users are experiencing issues. Look at mobile and desktop differences, not just the overall score.
- Group the issues. Determine whether the main problems lie with LCP, INP, CLS, server response times, images, JavaScript, or third-party elements.
- Use Lighthouse for diagnosis. After identifying the problematic areas, run several tests to see which files, requests, and processes may be causing the issues.
- Test the truly important pages. Don’t just test the homepage. Check article pages, product pages, forms, checkouts, and pages that receive the most traffic.
- Compare before and after. Save test results under similar conditions. A single improved number is not enough to conclude that the change is safe.
- Monitor after release. New plugins, ad tags, theme changes, or personalization features can cause performance to regress weeks later.
What Does This Mean for Us?
If Lighthouse is good but users are still complaining, don’t immediately add a cache plugin or compress all images. A more useful question is: who is experiencing slowness, on which pages, using what devices, and when performing what actions?
For example, field reports show poor INP primarily on mobile catalog pages. Further investigation finds that product filters run searches and rearrange hundreds of elements every time a button is tapped. The solution may not be a CDN, but rather reducing JavaScript workload, limiting the number of rendered elements, or deferring non-essential processes.
Similarly, if LCP is poor only for visitors from certain regions, the issue could relate to server location, the size of the main image, or backend response times. Optimization becomes more targeted when decisions are made from a combination of real data and diagnostic tools.
What You Can Do Now
- Note the three pages with the highest traffic and test their mobile versions.
- Compare Lighthouse results with field data from PageSpeed Insights or Search Console.
- Check if the main image is immediately visible in the initial HTML and has clear dimensions.
- Investigate unnecessary third-party JavaScript for the initial view.
- Measure important interactions such as searches, filters, menus, and form submissions, not just page load times.
- Establish regular monitoring to catch performance regressions before complaints increase.
Lab scores remain useful, but they are better treated as diagnostic tools, not the final report for all users. A healthy website requires two perspectives: controlled testing to find causes and field data to ensure that improvements are genuinely felt.
Sources & Further Reading
- Core Web Vitals workflows with Google tools
- Why lab and field data can be different
- Getting started with measuring Web Vitals
- Interaction to Next Paint (INP)
- CrUX methodology
– Rio Yotto @rioyotto