Two tools look at the same website and return opposite answers. One says the pages are fast, the other flags them as slow. Before you decide which one is wrong, check what each one is actually looking at. In most cases neither is wrong. One reports what a population of real visitors experienced over the past weeks, and the other reports a single simulated page load on a machine you never see.
This guide is written for SEO specialists, developers and agency account managers who have to explain Core Web Vitals reports to someone else. It starts with the difference between measured and simulated evidence, opens up the Chrome UX Report (CrUX) to show who is counted and how, and explains the origin versus URL distinction that causes most confusion. It then walks through Search Console, PageSpeed Insights and Lighthouse, lists the reasons lab and field results diverge, covers empty reports, and ends with a routine for turning a report into a short list of work. No search volumes, difficulty scores or ranking-impact figures are given, because none are available from the sources used here.
Two Kinds of Evidence: Measured Users and a Simulated Load
Every performance number you will ever read falls into one of two buckets. Mixing them is the root of most reporting arguments.
What field data is
Field data (also called real-user monitoring) is collected from the browsers of people who actually visit your pages. Each visitor has a different phone, connection, location and habit, so the result is a spread of values rather than one number. The web.dev article on Web Vitals is explicit about the role of this data: all Core Web Vitals are, first and foremost, field metrics, and lab measurement is not a substitute for field measurement. In its words, only field measurement can accurately capture the complete picture. You can read the full text in the web.dev Web Vitals article (Opens in a new tab).
What lab data is
Lab data is produced by loading a page in a controlled setup. Lighthouse is the best-known example. The PageSpeed Insights documentation describes it as based on a simulated load of a page on a single device and a fixed set of network conditions. Because the setup is controlled, the result is repeatable, and repeatability is what makes lab data good for debugging: you change one thing, measure again, and compare.
The three metrics and their good thresholds
Core Web Vitals is the subset of Web Vitals that applies to all web pages. It has three metrics. Largest Contentful Paint (LCP) covers loading, Interaction to Next Paint (INP) covers interactivity, and Cumulative Layout Shift (CLS) covers visual stability. The good thresholds listed by web.dev are these: LCP within 2.5 seconds of when the page first starts loading, INP of 200 milliseconds or less, and CLS of 0.1 or less. The recommended way to judge them is the 75th percentile of page loads, segmented across mobile and desktop. A page passes if it meets all three targets at the 75th percentile.
The INP article (Opens in a new tab) adds the middle band: above 200 ms and up to 500 ms needs improvement, and above 500 ms is poor. INP observes the latency of clicks, taps and key presses across a visit and reports the worst one while ignoring outliers. Scrolling, hovering and zooming are not observed.
Which tool belongs on which side
According to web.dev, the field tools are the Chrome User Experience Report, PageSpeed Insights and the Core Web Vitals report in Search Console, and all three metrics are supported in them. Chrome DevTools appears on both sides. Lighthouse is a lab tool: it supports LCP and CLS, but not INP, and web.dev suggests looking at Total Blocking Time (TBT) in its place. So an INP-shaped hole in a Lighthouse report is expected behaviour, not a bug.
| Question you are asking | Reach for | Reason |
|---|---|---|
| How do my real visitors experience this page? | Field data | It reflects real devices, networks and behaviour |
| Which templates deserve attention first? | Field data | It shows where actual users struggle |
| Did this deploy make the page faster? | Lab data | Fixed conditions allow a clean before and after |
| Will this release introduce a regression? | Lab data | You can test pages that are not live yet |
| Can people on slow connections even load the page? | Both | Field data raises the flag, lab data reproduces it under constrained conditions |
Inside CrUX: Who Is Counted, For How Long, and What p75 Means
The Chrome UX Report is the dataset behind most field numbers you see in Google tools. Knowing its boundaries is the same as knowing the boundaries of those tools.
What the dataset is
The CrUX documentation (Opens in a new tab) describes it as a dataset that reflects how real-world Chrome users experience popular destinations on the web. It is the dataset of Google's Web Vitals program and represents all the user-centric Core Web Vitals metrics. The same page notes that Google Search uses it for the page experience ranking factor. It gives no figures for how much that factor weighs, so none are quoted here.
User eligibility
The CrUX methodology page (Opens in a new tab) lists who is counted. A user must have usage statistics reporting enabled, must sync browser history, and must not have a sync passphrase set. Supported platforms are desktop Chrome on Windows, macOS, ChromeOS and Linux, and Android Chrome, including Custom Tabs and WebAPKs. Excluded are Chrome on iOS, Android apps using WebView, and other Chromium browsers such as Edge. If your audience leans heavily towards iPhones, the data describes only the eligible slice of your visitors, so compare it with the device split in your analytics.
Page and origin eligibility
Pages and origins must be publicly discoverable and sufficiently popular, and the exact popularity threshold is not disclosed. Discoverability fails if a page returns a non-200 status code or carries a noindex directive in an X-Robots-Tag header or a robots meta tag. All eligibility criteria must be met for an experience to enter page-level data. Experiences that satisfy the user and origin criteria but not the page criterion are left out of page-level data while still counting towards origin-level data. That is why you can see an origin result for a site while an individual URL shows nothing.
How experiences are aggregated
Experiences are combined into page-level and origin-level distributions. Query strings and fragments are stripped from URLs, so variants of one page are grouped together, and iframe experiences roll up into the top-level page. Random noise is added to protect sensitive figures such as traffic volume, and origins or pages that lose more than 20 percent of their traffic to ineligible dimension combinations are removed entirely. Most metrics are published as histograms rather than precomputed percentiles.
The 28-day rolling window
The CrUX API documentation (Opens in a new tab) calls the data a 28-day rolling average of aggregated metrics, updated daily at around 04:00 UTC. PageSpeed Insights likewise describes its real-user metrics as covering the previous 28-day collection period. Three practical consequences follow. A fix does not show its full effect until the older experiences age out of the window. A short regression lingers in the verdict for a while after it is repaired. And a launch-day change is judged over weeks, not by the day.
What the 75th percentile tells you
The CrUX API documentation defines p75 as the value at or below which 75 percent of page loads experienced the metric. It is not an average. One visitor in four may have had a worse experience than the figure shown. The PageSpeed Insights documentation explains the intent: the goal is to make sure pages work well for the majority of users, so focusing on this percentile means pages are judged against harder device and network conditions.
Hypothetical example: when an average hides a problem
Hypothetical example: a news site where most readers arrive on recent phones over fast connections, while a smaller group uses older devices on slow mobile networks. The average looks healthy. If the slower group is large enough, however, the 75th percentile lands in the needs-improvement band. No figures are given because the example only illustrates the logic. Read the tail of the distribution, not its middle.
Origin Level or URL Level: Which Number Are You Looking At
A large share of reporting mistakes comes from reading an origin number as if it described a page, or the other way round. The same dataset exists at two granularities, and tools switch between them without announcing it loudly.
What each level covers
The CrUX API documentation states that for an origin, all data present for all pages in that origin are aggregated together, while for a URL only the data for that specific URL is returned. An origin figure is therefore a blend of every template on the site, including fast ones that dilute a slow checkout flow and slow ones that drag down an otherwise healthy blog.
How PageSpeed Insights switches
The PageSpeed Insights documentation (Opens in a new tab) says that when a URL lacks sufficient data, the tool falls back to origin-level granularity, which encompasses all user experiences on all pages of the website. Always check the label above the field section. If it says the data is for the whole origin, the numbers describe the site, not the URL you typed in.
How Search Console groups pages
Search Console takes a third approach. According to the Search Console help page (Opens in a new tab), the Core Web Vitals report draws on CrUX data and groups URLs into pages with a similar user experience. Labels (Poor, Need improvement, Good) are applied to a URL group for a specific device type. The group takes the status of its most poorly performing metric, so poor CLS with good LCP makes the group poor. The report may also fall back to a broader group when a single group lacks enough data.
| Where you look | Granularity | What it can answer | What it cannot answer |
|---|---|---|---|
| CrUX origin data | All pages of a site combined | Is the site healthy overall? | Which page or template is at fault |
| CrUX URL data | One URL, query strings and fragments stripped | How this exact page performs for real users | Anything, if the URL is not popular enough |
| Search Console group | Pages with similar experience, per device | Which group of pages is failing and on which metric | The exact value for a single URL |
| Lighthouse run | One URL, one simulated load | Why a page is slow and whether a change helped | What real visitors experience |
Why the group is the unit of repair
When Search Console shows many URLs as poor, it does not mean each one was measured separately. They share a user experience, so they share a verdict. The fix therefore belongs in the shared template, component or third-party script, not in each URL. Fixing one page and ignoring the template is how teams spend a month and see no change.
Search Console, PageSpeed Insights and Lighthouse: Three Views of One Page
These three tools are often presented as competitors. They are better understood as three windows with different jobs.
Search Console: the monitoring view
The Core Web Vitals report is for finding out which groups of pages need attention and on which device. It reports mobile and desktop separately, so a group can be Good on desktop and Need improvement on mobile. It leaves out groups without enough LCP and CLS data, and the help page notes that a new property may need a few days before CrUX data shows up.
Search Console validation
After a fix, you can start validation. The monitoring period runs for 28 days. If the issue does not appear on any URL on your site during that window, it is considered fixed; if it appears on any URL, the issue is marked as not fixed and validation can be restarted. The help page also indicates that validation does not trigger re-indexing, so do not use it as a way to request a recrawl.
PageSpeed Insights: two sources on one screen
PageSpeed Insights shows a real-user section covering the previous 28 days and a Lighthouse section that analyzes the URL in a simulated environment for performance, accessibility, best practices and SEO. This is where the two evidence types meet, and it is the screen where most contradictions get noticed.
Two different rules for two different numbers
The performance score is a lab number. In the PageSpeed Insights documentation, a score of 90 or above is considered good, 50 to 89 needs improvement, and below 50 is poor. The Core Web Vitals assessment is a separate rule: the aggregation passes if the 75th percentiles of all three metrics are Good, and if there is not enough INP data, the assessment relies on LCP and CLS alone. A page can hold a 98 in the lab and still fail the assessment in the field, or the reverse. If you want the score itself explained, we cover it in PageSpeed Insights score explained and how to improve it.
Lighthouse: the diagnosis view
Lighthouse is where you find causes. It cannot measure INP, so for interactivity you pair it with TBT and with real-user data. Treat its score as a regression alarm, not as the verdict. For the wider workflow around measurement and optimization, see our page speed and Core Web Vitals guide.
Why Your Lab Score and Field Verdict Disagree
Disagreement is the normal state of affairs. The web.dev article on differences between lab and field data (Opens in a new tab) lists the causes. They fall naturally into three families.
You are not measuring the same person
- Screen size: different viewports show different elements, so a lab run on one emulated device may pick a different LCP element than most of your users see.
- Device and network: field data contains a wide variety of both, while a lab test uses one of each.
- Location: lab tests run from a single geographic location. Your users do not.
- Cache: lab tests typically load a page with a cold cache, while returning visitors often have resources cached, which helps LCP, INP and CLS.
You are not measuring the same page
- Personalization and experiments: targeted ads and A/B tests change which elements load and how they shift the layout, whereas a lab test usually loads a generic version.
- Shared URLs: visitors arriving through links with fragment identifiers may have an LCP element further down the page than the one a lab test measures.
- Unsized lazy media: images or iframes without dimensions cause layout shifts when users scroll to them, which lab tests often miss.
You are not measuring the same moment
- Back and forward cache: restored pages load almost instantly and those visits count in field data. Lab tests ignore bfcache.
- Scrolling and interaction: in the field, LCP stops being measured once the user scrolls or interacts, while in the lab it runs until the page finishes loading. Field CLS also includes shifts after scrolling or interaction.
- Interaction timing: a lab test cannot predict when real users will interact, so it cannot capture INP accurately.
- Tap delay: browsers can add a 300 ms delay after taps on pages without a mobile viewport. That hurts INP but does not show up in TBT.
One number versus a distribution
The article makes a point worth repeating in client meetings: field data is not just one number, it is a distribution of numbers, and field tools usually report the 75th percentile. A single lab run is unlikely to match it exactly. The article also recommends how to use each: field data is what you should use to prioritize your efforts, and lab data is useful when debugging issues or testing features before deploying to production. If field scores are good but lab scores are not, it still suggests looking for further optimizations.
Where lab data still earns its place
Field data shows the outcome, not the cause. To find out whether a slow LCP comes from a heavy image, server delay or a blocking resource, you need a controlled and repeatable run. The same article also suggests using lab data to find users you may be missing, such as those on slow networks or low-end devices who may be struggling to load the site at all. And it recommends collecting your own field data, which can give more detail than CrUX alone. If that collection involves personal data or cookies, the consent rules in your market still apply.
When the Report Is Empty
New sites, low-traffic blogs and niche business sites regularly open Search Console and find no Core Web Vitals data. This is a statement about sample size, not about quality.
Common reasons for missing data
- Popularity threshold: CrUX requires a large enough number of visitors and does not publish the exact cut-off.
- Discoverability: pages that return a non-200 status or carry noindex cannot enter page-level data.
- Audience mix: if most visitors use Chrome on iOS or another Chromium browser, few of them are eligible.
- Brand new property: Search Console may need a few days before CrUX data appears.
- Thin LCP or CLS samples: URL groups without enough data are omitted from the report.
A working routine without field data
- Test your templates on a schedule. Run Lighthouse on the home page, a category page, an article and a product or service page with the same device profile each time, and log the results in a sheet.
- Prevent the usual causes. Declare image dimensions, include a mobile viewport tag, reserve space for lazy media and keep heavy third-party scripts from blocking rendering.
- Consider your own real-user measurement. A lightweight script covers pages CrUX cannot see. Check privacy and consent requirements before you add it.
- Confirm the pages are indexable. Returning 200 and avoiding noindex is a precondition for search visibility and for CrUX eligibility.
- Look again as traffic grows. Data often appears once a threshold is crossed.
Hypothetical example: a young boutique blog
Hypothetical example: a newly launched boutique blog finds no URLs in its Core Web Vitals report during the first weeks. Instead of tinkering endlessly, the owner records mobile Lighthouse results for the article template, sets explicit image sizes, and notices that a comments widget blocks rendering, so it is deferred. Months later, when traffic crosses the threshold, the first URL groups appear and the starting point is already clean. The example has no figures; it only shows the order of work.
What not to conclude
An empty report does not mean the site is fast, and it does not mean it is slow. It means there is no verdict yet. Do not substitute a lab score for the missing field verdict when you tell a client that the site passes Core Web Vitals. The pass decision comes from the 75th percentile of field data.
A Triage Routine for the Next Report
A report is only useful if it ends in an ordered list of work. The routine below puts field data first and lab data second, and it works equally well for an in-house team or an agency.
Step 1: split by device
Search Console reports mobile and desktop separately. Begin with the device class that brings most of your traffic, which you can read from your own analytics. If a group is Good on desktop and Poor on mobile, mobile is the priority.
Step 2: name the weakest metric
Because a group's status follows its weakest metric, find out whether LCP, INP or CLS is holding it back. The causes differ. As general background rather than a sourced rule, LCP problems often involve a late main content element, INP problems a busy main thread during interaction, and CLS problems elements that settle into place after loading without reserved space. Your site may differ.
Step 3: tie the group to a template
Open a few example URLs from the failing group and identify what they share: an article layout, a category listing, a product page, a search result. Repair the shared template so one change reaches many URLs.
Step 4: reproduce in the lab
Run an example URL through PageSpeed Insights and Lighthouse and try to reproduce the field problem. For INP, remember the lab limits and combine real-user data with DevTools profiling.
Step 5: ship, validate, wait
Deploy the fix, start validation in Search Console and let the 28-day window complete. Declaring a fix useless before the window closes is the most common misjudgment.
A decision matrix
| Field result | Lab result | Likely meaning | First move |
|---|---|---|---|
| Poor | Poor | The problem is reproducible | Find the cause in the lab and fix it |
| Poor | Good | The problem depends on real conditions such as device, network, interaction or personalization | List the differences and collect your own field data |
| Good | Poor | Real users are fine, the lab setup may be harsher than their reality | Lower priority, but look for further gains |
| Good | Good | Healthy | Watch for regressions |
| No data | Any | No verdict | Scheduled lab tests and prevention |
Advertising and third parties
On ad-supported sites, field results are often shaped by ad placement: late-loading slots shift layout and heavy ad scripts slow interactions, and a lab run may load ads differently so the problem stays hidden. We discuss that balance in ads and Core Web Vitals: the publisher balance.
What an agency report should contain
Instead of a single score, show the Search Console status per device, the name of the failing metric for each group, the date the fix shipped and the date validation started, plus the lab finding that explains the cause. Avoid promising a ranking outcome. The sources used here describe Core Web Vitals as part of the page experience signal but do not quantify its effect.
Common Misreadings
- Treating a Lighthouse score as the verdict. A score above 90 does not mean the Core Web Vitals assessment passes. The pass decision comes from field data at the 75th percentile.
- Reading origin data as page data. Origin figures blend all pages and say nothing definitive about one URL.
- Reacting to a one-day change. The window is 28 days rolling, so effects arrive late and fade late.
- Assuming CrUX equals all visitors. Chrome on iOS and other Chromium browsers are not counted.
- Looking at averages. The target is the 75th percentile, and the slow tail is where some users hide.
- Fixing one URL and forgetting the group. Search Console groups share an experience, so the fix belongs in the template.
- Searching for INP in Lighthouse. It is not measured there; use TBT as a lab proxy and field data for the real number.
- Confusing validation with re-indexing. Validation is a monitoring window and does not trigger a recrawl.
Frequently Asked Questions
What is the difference between CrUX data and a Lighthouse score?
CrUX is field data: a 28-day rolling aggregate of how eligible Chrome users actually experienced your pages. A Lighthouse score is lab data: one simulated load on one device under fixed network conditions. The Core Web Vitals verdict is taken from the 75th percentile of field data, so a high Lighthouse score does not by itself mean the assessment passes.
Why does PageSpeed Insights show origin data instead of my URL?
When a URL does not have enough field data, PageSpeed Insights falls back to origin-level granularity, which covers the experiences of all users on all pages of the site. It is a useful overall picture but it cannot tell you which specific page is the problem.
Does Core Web Vitals data include every visitor?
No. CrUX only counts eligible Chrome users on supported platforms: those who have usage statistics reporting enabled, sync their browsing history and have no sync passphrase set. Chrome on iOS, Android WebView apps and other Chromium browsers are excluded, so the dataset is a sample of your audience rather than all of it.
How long until a fix shows up in Search Console?
CrUX data is a 28-day rolling average, so improvements enter the distribution gradually. A validation started in Search Console runs for 28 days, and the issue counts as fixed only if it does not appear on any URL during that window. Judge a release after the window, not after a day or two.
What should a small site do if there is no field data?
An empty report is not a verdict. Run Lighthouse on your main templates with a fixed device profile, set image dimensions and a mobile viewport, keep heavy third-party scripts from blocking rendering, consider collecting your own real-user measurements, and check again as traffic grows.
Conclusion
Field data and lab data are not rivals. They answer two different questions. Field data, the 28-day, 75th-percentile summary of eligible Chrome users, tells you whether real people have a good experience and where to start. Lab data, a repeatable simulation, tells you why a page behaves as it does and whether a change helped. Search Console shows groups of similar pages and the weakest metric in each, PageSpeed Insights puts field and lab side by side for one URL or falls back to the origin, and an empty report means there is no verdict yet, not a good or bad one. Use field data to choose, lab data to diagnose, and the validation window to confirm. None of these steps guarantees a particular ranking result; the aim is a measurably better experience for real visitors.
If you need clear technical and reporting articles written consistently, you can look at the SEO content writing service at Akua Adforce; scope and terms are listed on the product page.
Post a comment
Please log in to leave a comment. Login