Field Data vs. Lab Data

TL;DR — Field dataPerformance metrics captured from real users, not lab tests. is real numbers from real people who visited your page. Lab data is a single test run by a tool (usually LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) on a pretend phone in controlled conditions. Google ranks on the field data — the real users — not on your lab score. So a page can score great in the lab and still fail for real visitors, and that’s not a bug.

Two ways to measure a page

There are only two ways to know how fast your page is:

• Ask a tool to load it once in a controlled setup — a fixed device, a fixed network speed, from one location. That’s lab data. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and PageSpeed Insights’ “diagnose” section work this way.
• Watch what actually happened to real people who visited your page on their own phones and laptops over their own connections. That’s field data. For SEO, the field data comes from Google’s Chrome User Experience Report (CrUX), which is built from real Chrome users who opted in to share their experience.

Google’s own web.dev docs put the field-data definition plainly: field data “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” Lab data, by contrast, “is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.”

The one idea to remember

Google ranks on field data. Your Lighthouse or PageSpeed score is a lab number, and it is not what Google uses to rank you. As Google’s John Mueller has put it, Google doesn’t use the 0–100 Lighthouse score for search — it uses the Core Web Vitals separately, measured from real users.

So when your PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. score looks green but your Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Core Web Vitals report says “Poor,” nothing is broken. They’re two different datasets:

• Lab = one simulated visit, throttled to a slow phone.
• Field = a pile of real visits from real devices and networks, summarized.

They frequently disagree, and when they do, the field data is the one that counts for SEO.

So which do I use?

• “How am I doing for ranking?” → Field data. Easiest to see in Google Search Console’s Core Web Vitals report or the top section of PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking..
• “What’s making my page slow / what do I fix?” → Lab data. Run Lighthouse — it lists the problems.
• “I made a change — did it work?” → Test it in the lab immediately, then wait for the field data to catch up (real-user data updates over a rolling 28-day window, so it lags).

Want the mechanics — why the two numbers diverge, the 75th-percentile and 28-day math, which tools give you which, and the myths people trip over? Switch to the Advanced tab.

TL;DR — Field dataPerformance metrics captured from real users, not lab tests. is a distribution of real-user measurement (RUM); for SEO it’s the Chrome UX Report (CrUX), aggregated at the 75th percentile over a rolling 28-day window. Lab data is a single configured observation — synthetic, one fixed device/network/location (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) — a diagnostic, not a ranking input. Neither is universally “more accurate”; which one you need depends on the question. They diverge for concrete reasons (cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., geography, device and network variance, throttling profiles, interaction timing — including INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., which a lab can observe locally for one reproduced interaction but never as a population). Use lab data to test and debug fast; use field data to confirm real-world impact and for anything ranking-related — Google’s ranking systems use Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. field data, and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s report is CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.-sourced, though neither source publishes the exact internal per-URL ranking mechanics. CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. is Chrome-only and opt-in, and its page/origin aggregation has real edge cases (URL normalization, iframeHTML element that displays one webpage inside another — how embeds work. attribution, SPA routes) worth knowing before you trust a number. Bing publishes no CrUX equivalent; this is a Google/Chrome- ecosystem framework.

The definitions, precisely

Google’s web.dev Why lab and field data can be different page gives the cleanest pair of definitions:

• Field data “is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.”
• Lab data “is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” Specifically, a lab test consists of “a single device… connected to a single network… run from a single geographic location.”

If you come from a dev-ops background, you already know these two under different names. MDN maps them cleanly: field data is Real User Monitoring (RUM) — “the performance of a page from real users’ machines,” where “the browsers of real users report back performance metrics experienced” — while lab data is synthetic monitoring, “monitoring the performance of a page in a ‘laboratory’ environment” by “deploying scripts to simulate the path an end user might take.” Field = RUM. Lab = synthetic. Same split, two vocabularies.

Underneath the vocabulary, the two are structurally different kinds of evidence. Field data is a distribution — hundreds or millions of individual real-user sessions rolled up into a population you read at a percentile. Lab data is a single configured observation — one deliberately chosen device/network/location combination, run once (or a few times) so it’s repeatable. Neither is universally “more accurate”: which one is the right evidence depends on the question you’re asking, the population you need to represent, and how the numbers were aggregated. Field data answers “how are my real users actually doing”; lab data answers “why, mechanically, is this page slow.” Google’s own framing backs this up directly — both lab data and field data are important parts of effective performance measurement; they both have their strengths and limitations.

Field data, explained

For SEO, “field data” means one specific dataset: CrUX, the Chrome User Experience Report — “a public dataset of field data gathered from a segment of real Google Chrome users from millions of websites.” Individual user experiences are aggregated into page-level and origin-level distributions.

A few mechanics that matter:

• It’s opt-in and Chrome-only. CrUX gathers data only from users who enabled usage statistic reporting, sync their browser history, and have no sync passphrase set, on supported platforms — explicitly excluding Chrome on iOS, Android WebView, and other Chromium browsers like Microsoft Edge. For a Safari- or Edge-heavy audience, CrUX may capture only a minority of your real users.
• Percentiles, not averages. Google’s field-measurement best practices are explicit: “Whenever possible, rely on percentiles instead of averages,” because “percentiles across a distribution… better describe the full range of user experiences.” And specifically: “To ensure you’re meeting the recommended Core Web Vitals thresholds, you’ll need your report to display the value of each metric at the 75th percentile.” That’s the p75 you’ll see everywhere.
• The 28-day window. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. data behind ranking is a rolling 28-day aggregation. As I’ve written in my Ahrefs Core Web Vitals guide, “the CWV data is on a 28 day rolling average. Any changes you make won’t be seen in the CWV data for a while but will be reflected in lab test data after the changes are made.” That lag is the whole reason you need lab data as a fast feedback loop.

Population and aggregation edge cases worth knowing before you trust a number:

• Page-level vs. origin-level are different distributions, with different eligibility thresholds — a URL can lack enough traffic to appear on its own while the origin still has enough. CrUX’s methodology defines both separately; don’t treat an origin number as if it were that one page’s number, or vice versa.
• URL normalization can group pages you’d consider distinct. CrUX strips query strings and fragments from the page identifier before aggregating, so parameterized variants of a URL can get folded into one record — and in rare cases that can combine experiences from pages your app treats as separate.
• Embedded iframe content is attributed to the top-level page, not reported as its own page record — a slow third-party iframe shows up in the containing page’s numbers, not as a separate CrUX entry.
• Single-page-app route changes can stay attributed to the initial page view. Because of underlying web-platform measurement limits, a JavaScript-driven route transition in an SPA doesn’t always get its own CrUX page record — it can remain folded into the first load.
• Missing data is “unavailable,” not zero and not “good.” If a page or origin doesn’t clear CrUX’s popularity/eligibility bar, the honest read is “we don’t have field data for this,” never a passing score and never a lab estimate standing in for it (see the origin-fallback note below).

Field data is not abstract — it’s an enormous, constantly refreshed dataset. Per the CrUX release notes, the May 2026 release (published June 9, 2026) covered 18,445,974 origins, of which 55.9% had good Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. overall (68.6% good LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., 81.3% good CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., 86.6% good INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.). Nearly half of all origins not passing is your proof that the field and lab datasets really do diverge at scale.

Lab data, explained

For SEO, “lab data” means Lighthouse and the tools built on it — PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.’ lab section, WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., and the Chrome DevTools Performance panel. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. loads your page once in a controlled environment on a throttled connection and reports what happened.

Its strengths are exactly its constraints. Because it holds device, network, and location fixed, it’s reproducible, fast, and available on demand — you can run it against a page that has zero traffic and get a result, which field data can never do. Google frames the value directly: lab tools help you identify opportunities to expand your site’s reach and make it more accessible to users with slower networks or lower-end devices.

But Google is equally direct about its limits: Lighthouse is not a substitute for field data. “Lighthouse is primarily a diagnostic tool listing potential issues,” and the guidance is to “always concentrate on field Core Web Vitals over Lighthouse metrics and scores.”

In my own Ahrefs PageSpeed Insights guide, I make the same point from the practitioner side: “you can have a good score but still have a slow page that doesn’t pass CWV,” because “other factors, such as network conditions, server load, caching, and the user device, also affect page load time.”

Why they diverge — the mechanics

“Different network” is the usual hand-wave. Here’s what’s actually going on. Google’s own framing: field data includes a wide variety of network and device conditions as well as a myriad of different types of user behavior, while lab data “intentionally limits the number of variables involved.” Spelled out, the divergence comes from:

• Caching. Lighthouse loads cold every time. Real users include repeat visitors with warm caches — so their real-world experience is often faster than the lab’s cold load (or slower in ways a cold load can’t see).
• Geography and network variance. The lab runs from one location on one throttled profile. Your real audience is spread across countries, carriers, and connection types. As I put it in my Ahrefs CWV guide, “field data looks at real users, network conditions, devices, caching, etc. But lab data is consistently tested based on the same conditions to make the test results repeatable.”
• Device. One simulated mid-tier phone in the lab vs. the full range of real hardware, from flagships to years-old budget Androids.
• Throttling vs. reality. Lighthouse’s default mobile profile simulates a slow connection (roughly “slow 4G” — on the order of ~1.6 Mbps with ~150 ms round-trip time, plus a ~4× CPU slowdown), per DebugBear’s teardown, which can be far harsher (or gentler) than any individual real user’s actual network.
• Interaction timing. Lighthouse waits for load to finish and measures a passive page load. Real users scroll, tap, and navigate — which is why lab tools can undercount layout shifts that only happen once a real person interacts. INP is trickier than “can’t be measured in a lab”: Chrome DevTools’ Performance panel can record a local INP number while you manually reproduce an interaction (its “Live metrics” view does exactly this). What a lab can’t give you is a population — one person clicking one button once isn’t a 75th-percentile distribution across your real audience, so a good local INP trace still tells you nothing about your field CWV assessment.

None of this is a defect. Google’s stance is that divergence is expected: both lab data and field data are important parts of effective performance measurement; they both have their strengths and limitations.

Which tools give you which

Google’s own About PageSpeed Insights docs sum up the split: “PSI provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.”

Note the origin-level fallback: if a specific URL lacks enough CrUX samples, PSI shows data for the whole origin instead, and if the origin also has insufficient data, PSI will be unable to show any real-user experience data. That’s expected for new or low-traffic pages — not an error, and not something Google fills in with a lab estimate.

TIP Compare the two datasets on one URL

See the field and lab result together—and use each for the job it is good at—with my free Core Web Vitals Checker Free

1. Confirm whether the field result is page-level or an origin fallback and match the mobile or desktop form factor.
2. Use the lab trace to investigate the mechanism behind the slower result.
3. Use CrUX field data—not the Lighthouse score—to judge the ranking-relevant real-user outcome.

Tap to enlarge

The completed comparison reports one metric in different performance bands: mobile LCP is 2.2 seconds and good in field data, versus 5.1 seconds and poor in lab data.

What Google actually ranks on

Field data via CrUX, at p75 over 28 days — that’s the dataset behind the ranking question, not the lab number. Search Console’s Core Web Vitals report is field-only: it “shows how your pages perform, based on real world usage data (sometimes called field data),” and “the data… comes from the CrUX report.” Worth being precise about what that does and doesn’t establish: Google says Core Web Vitals feed its ranking systems and that Search Console’s report is sourced from CrUX — but neither source publishes the exact internal mechanics of how a given public CrUX value is consumed as a per-URL ranking input, so treat “CrUX is field data Google ranks on” as accurate and “this exact public number is the literal internal ranking input” as more than the documentation supports. It’s also worth knowing Search Console’s report groups URLs with similar experiences rather than functioning as a precise per-URL lookup tool — if you need the status of one specific URL, PageSpeed Insights is the better instrument.

Google’s reps have been consistent about this for years. Martin Splitt, back in 2020: field data comes from real users, whereas lab data comes from a strong machine with good internet — so you might not see the same results. John Mueller, in 2021, described the relationship the same way — the lab result is essentially an approximation of what Google’s systems think might happen in the field, which means you can use lab data to improve incrementally but shouldn’t expect a clean one-to-one link between the lab result and the field result. And on the score itself, Mueller was blunt that Google doesn’t use the X/100 Lighthouse score for search — it uses the Core Web Vitals separately, as users see them, which requires a certain amount of real traffic first.

Two important caveats so nobody over-rotates:

• Core Web Vitals is one signal among many. Google’s page-experience docs are explicit: “There is no single signal,” and “getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results.” Passing CWV is table stakes, not a rocket.
• CrUX isn’t the only field data — it’s the ranking-relevant one. Any RUM tool (Cloudflare Web Analytics, SpeedCurve, DebugBear, Treo) also produces “field data” in the general sense, and those can be more granular and more current than CrUX. But only CrUX is what Google’s ranking systems consult. Don’t confuse “we have RUM” with “we can see what Google ranks on.” And don’t assume they’ll agree even when both are “field”: a private RUM setup and CrUX can legitimately disagree because they can cover different browsers, consent states, devices, sampling rates, sessions, and metric-capture timing.
• A lab score is not a ranking prediction. Improving your Lighthouse number is evidence you fixed a mechanism, not evidence your ranking will move — the two datasets measure different things, and only the field number is anywhere near the ranking conversation.

For the deeper treatment of the metrics themselves — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INP, CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. and their thresholds — and the tools that surface them, see the sibling Core Web Vitals hub and the Web Performance Tools hub this article sits under.

What Bing does (or doesn’t)

Bing publishes no public equivalent to CrUX. There’s no Bing real-user field dataset you can query, and no “field vs. lab” ranking framework the way Google, Chrome, and web.dev document one. Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility.’ Site Scan is a synthetic/lab-style crawl-and- audit tool, not a RUM product. Bing does say page speed factors into user experience in a general sense, but it doesn’t cite a CrUX-style dataset. So treat the whole field-vs-lab framework as a Google/Chrome-ecosystem concept — Bing runs on Chromium under the hood but hasn’t shipped a parallel dataset or public stance. If you read “field data” in an SEO context, it means Google.

How to use both in practice

The two datasets aren’t rivals — they’re a workflow:

1. Find failing pages with field data. Start in Search Console’s Core Web Vitals report (site-wide) or PageSpeed Insights’ top section (one URL). This tells you where you stand for ranking.
2. Diagnose with lab data. Run Lighthouse / PSI’s lab section / DevTools to find why — the specific render-blocking resource, oversized image, or layout shift.
3. Iterate fast in the lab. Because lab data is instant and repeatable, it’s your feedback loop while you make changes.
4. Wait for the field to catch up. The 28-day rolling window means your fix won’t fully show in CWV/CrUX for a while — that’s normal, not a sign the fix didn’t work.
5. Confirm real-world impact in the field. Re-check Search Console / PSI’s field section to verify real users actually improved.

Two guardrails that keep this workflow honest:

• Compare like-for-like before you credit (or blame) a fix. Before reading a field number as “moved,” confirm you’re looking at the same population, form factor, and window as your baseline — a shift from origin-level to page-level data, a different device mix, or a different percentile isn’t the fix working (or failing), it’s a different measurement.
• Don’t diagnose a mechanism from one lab run. Even a controlled environment isn’t perfectly reproducible — network, client hardware, and background resource contention can still shift a single Lighthouse run. Repeat the lab test before you attribute a fix’s effect to a specific cause.

The rule of thumb: lab data to test and debug, field data to confirm and rank. Or, in Google’s words, if you have both, field data is what you should use to prioritize your efforts.

Myths worth killing

• “A 100/100 Lighthouse score means I’ll pass Core Web Vitals / rank well.” No — Lighthouse is a single simulated cold load; CWV is field data at p75 over 28 days from real users. They frequently disagree, and only the field data feeds ranking.
• “If field and lab don’t match, something is broken.” No — Google frames divergence as normal. Both datasets have strengths and limitations by design.
• “The Lighthouse Performance score is a ranking factor.” No — per Mueller, Google uses the Core Web Vitals field values, not the 0–100 score.
• “CrUX updates instantly, so I can’t test anything for 28 days.” The defensible framing is: use lab data for immediate testing, and treat field data as the lagging real-world confirmation. (You’ll sometimes hear the stronger industry claim that CrUX data is only ~2 days old rather than 28 — that’s a reasonable point some in the industry make, but it isn’t Google’s official wording, so I’d hold it loosely.)
• “If a page has no traffic, Google estimates its CWV from similar pages or lab data.” No — PSI falls back to origin-level field data, and if that’s also insufficient, it shows no real-user data at all. There’s no lab substitution in the ranking system.
• “Bing has a CrUX equivalent, just less known.” No — no public Bing dataset of this kind exists.

FAQs

Does Google use lab data (Lighthouse) for rankings? No. Per Google’s docs and Mueller directly, the Lighthouse score isn’t a ranking input; ranking uses Core Web Vitals field data from CrUX.

Why does my PageSpeed/Lighthouse score look great but Search Console shows “Poor”? Different datasets, measured differently: one simulated cold load with fixed throttling (lab) vs. an aggregated distribution of real users at p75 over 28 days (field). See “Why they diverge.”

What if my page has no field data? PSI falls back to origin-level data; if the origin also lacks enough CrUX samples, no real-user data is shown. That’s expected for new or low-traffic pages.

Is CrUX the only source of field data? No — any RUM tool produces field data in the general sense. But only CrUX is the field dataset Google’s ranking systems use.

Does Bing have its own version of CrUX? No public equivalent exists as of this writing.

Should I optimize for lab data or field data? Use lab data for fast, repeatable testing while you make changes; confirm real-world impact — and anything ranking-related — with field data, since that’s what Google measures against.

AI summary

A condensed take on the Advanced version:

• Two kinds of evidence, not two competing scores. Field dataPerformance metrics captured from real users, not lab tests. = a distribution of real-user measurement (RUM); for SEO it’s CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., aggregated at the 75th percentile over a rolling 28-day window. Lab data = a single configured, synthetic observation (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.) — a diagnostic, not a ranking input. Neither is universally “more accurate”; which one you need depends on the question.
• RUM vs. synthetic is the same split under dev-ops names: field = RUM, lab = synthetic monitoring (per MDN).
• Why they diverge: cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. (cold lab load vs. warm real caches), geography, device and network variance, throttling profiles (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. ≈ slow 4G + ~4× CPU), and interaction timing. INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. is a nuance, not an absolute: a lab tool can observe one manually reproduced interaction locally, but that’s not a field-level population. Google treats divergence as normal.
• Population and aggregation edge cases: page-level vs. origin-level are different eligibility tiers; CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. strips query stringsThe `?key=value` data tacked onto the end of a URL after a question mark — used for tracking, sessions, filtering, sorting, and search — and one of the biggest sources of duplicate URLs and wasted crawling in SEO./fragments (can group URL variants); iframeHTML element that displays one webpage inside another — how embeds work. content attributes to the top-level page; SPA route changes can stay attributed to the initial load; missing data is unavailable, never zero and never “good.”
• What Google ranks on: Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. field data, at p75/28-day — not the 0–100 Lighthouse score (Mueller: Google uses CWV separately). CWV is one signal among many; a good score doesn’t guarantee top rankings, and neither Google nor Search Console documents the exact internal mechanics of a per-URL CrUX-to-ranking pipeline — treat “CrUX is the field dataset that feeds ranking” as accurate, not “this exact public number is the literal ranking input.”
• Origin fallback: if a URL lacks CrUX samples, PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. shows origin-level data; if that’s also thin, no field data at all. No lab substitution.
• Bing: no public CrUX equivalent — this is a Google/Chrome-ecosystem framework.
• Workflow: Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. (find failing pages, grouped by similar URLs, not a precise per-URL lookup) → Lighthouse/PSI lab (diagnose, repeat the run before trusting a mechanism) → iterate fast in the lab → wait ~28 days → confirm in the field on a like-for-like population/window. Lab to test, field to rank.

Official documentation

Primary-source documentation on field vs. lab data.

Google

• Why lab and field data can be different (and what to do about it) — the definitions of each, why they diverge, and “field dataPerformance metrics captured from real users, not lab tests. is what you should use to prioritize your efforts.”
• Core Web Vitals: field and lab tools — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. as the field source; “LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. is not a substitute for field data.”
• Best practices for measuring Web Vitals in the field — percentiles over averages, and the 75th-percentile threshold.
• About PageSpeed Insights v5 — PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.’s lab + field sections and the origin-level fallback behavior.
• Understanding page experience in Google Search results — “there is no single signal”; good tool scores don’t guarantee top rankings.
• Core Web Vitals report — Search Console Help — the report is field-data-only, sourced from CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program..
• Chrome UX Report: Methodology — what CrUX is, opt-in criteria, and platform coverage.
• Chrome UX Report: Release notes — the live, dated pass-rate stats.

MDN (cross-ecosystem vocabulary)

• RUM vs. Synthetic monitoring — the dev-ops names for field (RUM) and lab (synthetic) data.

Bing / Microsoft

• Bing publishes no CrUX equivalent or “field vs. lab” ranking framework. Its guidance treats page speed as part of general user experience, but there’s no public real-user dataset to cite. See Bing Webmaster Tools help for its general guidance.

Quotes from the source

On-the-record statements from Google (and Google reps). Each link is a deep link that jumps to the quoted passage on the source page.

Google — the definitions

• “Field dataPerformance metrics captured from real users, not lab tests. is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users’ individual experiences.” — web.dev. Jump to quote
• “Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions.” Jump to quote

Google — which to prioritize, and why they diverge

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” Jump to quote
• “PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. provides both lab and field data about a page. Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience — but has a more limited set of metrics.” — About PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.. Jump to quote

Google — field data is what Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. (and ranking) uses

• “The Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. shows how your pages perform, based on real world usage data (sometimes called field data).” — Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. Help. Jump to quote
• “There is no single signal.” — Google page-experience docs, on how ranking systems weigh page experienceGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data.. Jump to quote

Google — measure the field at the 75th percentile

• “Whenever possible, rely on percentiles instead of averages. Percentiles across a distribution for a given performance metric better describe the full range of user experiences.” — web.dev. Jump to quote

Martin Splitt, Google (via Search Engine Journal, June 2020)

• “Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results.” Read the coverage

John Mueller, Google (via Search Engine Journal)

• “One of the things that generally happens with the lab versus field data is that with the lab data it’s basically an assumption. It’s an approximation of what our systems think might happen in the field.” Read the coverage
• “Google doesn’t use the X/100 lighthouse scoreLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. for search, we use the core web vitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. separately (lcpLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., clsCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., fidFirst Input Delay — a retired Core Web Vital that measured the delay before the browser could begin processing a page's first interaction. Good was ≤100 ms. Replaced by INP in March 2024.)… Google uses the values as users see them, which requires a certain amount of traffic first.” (Mueller’s “lighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.” casing and the older FID metric are preserved verbatim.) Read the coverage

Which dataset should I look at?

A quick “which path do I take?” for the question people actually get stuck on.

Start: what am I trying to do?

• “Know if I’m passing for ranking / SEO.” → Field dataPerformance metrics captured from real users, not lab tests.. Site-wide: Search Console’s Core Web Vitals report. One URL: PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (top section). → No field data shown? The page/origin lacks enough traffic. You cannot assess the ranking signal from a lab score — get more real traffic, or judge by a similar page’s field data.

• “Figure out why a page is slow / what to fix.” → Lab data. Run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. (or PSI’s bottom section, or DevTools Performance). It lists the specific issues.

• “I just made a change — did it help?” → Lab data first (instant, repeatable feedback), then field data to confirm — but expect the field to lag ~28 days behind due to the rolling window.

• “Test a page behind a login / not publicly reachable.” → Lab only — run LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. in Chrome DevTools. CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program./field and public PSI can’t see non-public URLs.

• “Check a competitor’s real-user performance.” → Field data via PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — it works on any public URL with enough CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data.

The one rule under all of it: field for assessment and ranking, lab for diagnosis and fast iteration. When the two numbers disagree, the field data is the one that counts for SEO.

Field vs. lab — cheat sheet

The core split

Which tool is which

• Field: CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. · PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (top) · Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. CWV report · DevTools CrUX panel
• Lab: LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. · PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. (bottom) · WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. · DevTools Performance panel

Fast facts

• Google ranks on field data (CrUX at p75/28-day), not the 0–100 lab score.
• A page can score green in the lab and fail in the field — that’s normal, not a bug.
• No field data? PSI falls back to origin-level; if that’s thin too, no real-user data is shown (expected for new/low-traffic pages).
• CrUX is Chrome-only + opt-in — no iOS Chrome, no WebView, no Edge/Safari/Firefox.
• Bing has no CrUX equivalent — field vs. lab is a Google/Chrome concept.
• Rule: lab to test/debug, field to confirm/rank.

Field data fails while the lab test passes

1. Confirm the datasets. Record the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. scope, form factor, 28-day window, and metric alongside the lab device/network profile. If either result is an origin fallback or a different metric, correct the comparison first.
2. Find the affected field segment. Separate mobile from desktop and inspect URLA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. or template groups. If the problem exists only at origin level, sample the slow templates rather than tuning the passing page.
3. Reproduce realistic conditions. Rerun the lab with a slower device/network, cold and warm cache states, and the same page state real users see. If the issue appears, use the trace to identify the bottleneck; if not, continue.
4. Use first-party RUM where available. Segment by geography, device, browser, template, and navigation type. If non-Chrome traffic differs, report that as an audience gap rather than a CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. error.
5. Ship one attributable fix. Verify the mechanism immediately in the lab and watch RUM for early movement. If adjacent CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. regress, roll back or revise.
6. Wait for the field verdict. CrUX is a rolling 28-day aggregate, so compare equivalent windows as older visits age out. Do not declare the fix failed on day one.

What not to do

The recurring mistakes that come straight from confusing the two datasets:

• Chasing a 100/100 Lighthouse scoreLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and calling it done. The lab score isn’t the ranking signal, and a perfect lab run can sit next to a failing field assessment. Google’s own page-experience docs warn that a perfect score just for SEO reasons may not be the best use of your time.
• Treating a lab/field mismatch as a bug to “fix.” It’s expected. Both datasets are measured differently on purpose; divergence is the normal state, not an error.
• Judging your ranking signal off a page with no field dataPerformance metrics captured from real users, not lab tests.. If PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking./Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. shows no CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. data, the lab score tells you nothing about how you’re doing for CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. ranking. Don’t substitute the lab number for the missing field number.
• Expecting a fix to show up in field data immediately. The 28-day rolling window means real-user data lags. Test the fix in the lab for instant feedback; give the field time.
• Assuming any RUM tool’s field data is what Google ranks on. Cloudflare, SpeedCurve, DebugBear, and Treo all produce field data — but only CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. feeds Google’s ranking systems. Great third-party RUM numbers don’t guarantee a passing CrUX assessment.
• Assuming Bing works like Google here. There’s no Bing CrUX equivalent; don’t apply the field-vs-lab ranking framework to Bing.
• Optimizing only for the lab’s single throttled profile. Real users span many devices, networks, and locations. A page tuned to pass one simulated slow-4G run can still fail for a real audience on genuinely worse (or just different) conditions.

Test yourself: Field Data vs. Lab Data

Five quick questions on the two datasets and which one Google ranks on. Pick an answer for each, then check.

Resources worth your time

My related writing

• What Are Core Web Vitals (CWVs) & How To Improve Them — my CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. guide: the field-vs-lab distinction, the 28-day rolling window, and where CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. fits.
• Google PageSpeed Insights For SEOs & Developers — how PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. splits the CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field section from the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab section, and why a good score can still mean a slow page.
• The Beginner’s Guide to Technical SEO — where performance measurement fits in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and ranking, including where page experience sits. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Why lab and field data can be different and Core Web Vitals: field and lab tools (web.dev).
• About PageSpeed Insights and Core Web Vitals report (Google).
• Chrome UX Report: Methodology and Release notes (Chrome for Developers).

From around the industry

• Google Explains Why Field Data is More Reliable Than Lab Data (Search Engine Journal, Southern, June 2020) — Martin Splitt on the real-users-vs-strong-machine split.
• Countries With Slow Internet Can Affect Core Web Vitals Scores (Search Engine Journal, Montti, April 2021) — John Mueller on lab data as an approximation of the field.
• Do Google Lighthouse Scores Affect SEO? (Search Engine Journal, Southern, 2021) — Mueller’s “Google doesn’t use the X/100 lighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. score for search.”
• Why Does Lighthouse Lab Data Not Match Field Data? (DebugBear) — the throttling numbers and mechanics behind the divergence.
• Lab Data & Field Data: what’s the difference and how to use them (Onely) — a solid comparison-table treatment.
• RUM vs. Synthetic monitoring (MDN) — the cross-ecosystem vocabulary for field vs. lab.
• r/TechSEO — the community for Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and performance debugging.

Changelog