PageSpeed Insights Explained: Field Data, Lab Data and Why They Differ

PageSpeed Insights is a free Google tool that takes a URL and returns two different kinds of evidence about it. One is what real Chrome users experienced on that page over the recent past. The other is a single simulated test run by Lighthouse. They answer different questions, they often disagree, and most confusion about PageSpeed Insights comes from reading them as one score.

This guide shows how to read the tool in the right order. You will learn what the real-user block means and when it is missing, how the Core Web Vitals assessment passes or fails, what the lab block adds, and a short list of reasons the two blocks disagree. It is for site owners and developers who have a PageSpeed Insights result open and are unsure what to trust. By the end you will know which block to use to decide whether you have a problem, and which to use to find the cause.

Short answer: PageSpeed Insights shows field data from real Chrome users over the previous 28 days, and lab data from one simulated Lighthouse test. Use field data to decide whether a page has a speed problem, and lab data to find causes. They differ because devices, networks, caching and behaviour differ.

Before you begin

You need a public URL and a browser. No account or key is needed for the web tool. Decide which URL matters: a representative page, not only the home page. Remember that a result describes one URL on one day, so write down the date and keep screenshots or exported figures if you plan to compare later.

If you want to read the numbers through the API or in a script, you will add a Google Cloud API key to your requests; Step 6 covers that. A quick refresher on terms helps. Field data comes from real visits. Lab data comes from a controlled run. The Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). If those terms are new, Core Web Vitals Explained: LCP, INP and CLS Thresholds is a good primer. Running a test does not change your site and carries no risk.

What is the difference between field data and lab data?

	Field data	Lab data
Source	Chrome User Experience Report (CrUX), real Chrome users	A Lighthouse run in a simulated environment
Window	The previous 28-day collection period	One load, right now
Metrics shown	FCP, INP, LCP, CLS and the experimental TTFB	Lighthouse performance metrics and audits
Best used for	Deciding whether users have a problem	Debugging and testing a change before release
Weakness	Needs enough traffic, lags behind changes	One device, one network, one moment

Google's documentation describes field data as a historical record across many devices and networks and lab data as a simulated load on one device with fixed network conditions, and says lab data can miss real-world bottlenecks. CrUX itself only includes publicly discoverable origins and pages with enough visitors to produce a statistically meaningful sample.

Step-by-step instructions

Step 1: Enter the URL and pick mobile or desktop

Type the full URL and press Analyze. The report has a mobile view and a desktop view. Start with mobile, because mobile devices are usually the harder case. In lab data, the mobile test simulates a mid-tier phone on a mobile network and the desktop test uses an emulated desktop with a wired connection, so scores differ by design. Read Mobile Lighthouse Score Lower Than Desktop? Fix the Right Issues if the gap surprises you.

What success looks like: You have both views loaded for the same URL and know which one is which.

Step 2: Read the field data block first

This is the block that reports what real users experienced. Look at three things:

Does it exist? A page needs enough distinct samples from opted-in Chrome users and must be public (crawlable and indexable). A new or low-traffic page may have none.
Is it for the URL or the whole origin? If the page does not have enough data, PageSpeed Insights falls back to origin-level data, which covers all user experiences across all pages of the site. If the origin lacks data too, there is no real-user data at all. Do not read origin figures as if they described one page.
How does each metric sit against its thresholds?

Metric	Good	Needs improvement	Poor
LCP	up to 2.5 s	2.5 to 4 s	over 4 s
INP	up to 200 ms	200 to 500 ms	over 500 ms
CLS	up to 0.1	0.1 to 0.25	over 0.25
FCP	up to 1.8 s	1.8 to 3 s	over 3 s
TTFB (experimental)	up to 800 ms	800 ms to 1.8 s	over 1.8 s

Field figures are 75th percentiles, so they represent the experience of the slower end of visits. The Core Web Vitals assessment in Step 3 uses only INP, LCP and CLS; FCP and TTFB are extra context.

What success looks like: You can say whether field data exists, whether it is for this URL or the origin, and which metrics are good.

Step 3: Work out the Core Web Vitals assessment

The assessment pass rules are simple. It passes when the 75th percentiles of INP, LCP and CLS are all good. If INP has insufficient data, it passes when LCP and CLS are both good. If LCP or CLS has insufficient data, the page or origin cannot be assessed. So "no assessment" does not mean fail. It means Google lacks the data. Separately, use the colour coding to see which metric is the weak one: field distributions show green, amber and red bars for good, needs improvement and poor.

Google says it recommends good Core Web Vitals for success with Search, but does not promise a ranking improvement from them, so treat the assessment as a quality signal about real visitors, not a ranking lever. The related Search Console report groups URLs; see Core Web Vitals Report in Search Console: Read It and Prioritize Fixes.

What success looks like: You can state pass, fail or "not enough data" and name the failing metric.

Step 4: Read the lab block for causes

The lab block is a Lighthouse run. It reports a performance score and also scores for accessibility, best practices and SEO, with the bands 90 and above good, 50 to 89 needs improvement, 0 to 49 poor. It lists lab metrics with a green circle for good, an amber square for needs improvement and a red triangle for poor, and lists audits that suggest improvements. Use it to ask "why". If field LCP is poor, the lab LCP element and its breakdown (time to first byte, load delay, load time, render delay) can show which stage is slow. The full walk-through of that report is in How to Read a Lighthouse Report: Scores, Metrics and What to Fix First.

Lab data cannot measure INP, because there is no real user input in a lab run. Google's guidance says Total Blocking Time is used as a proxy. If your field INP is poor and lab TBT is fine, the problem is in interactions a lab run does not perform.

What success looks like: You have one or two lab findings that explain a weak field metric.

Step 5: Explain any disagreement between the two blocks

Disagreement is normal. Google's web.dev guidance lists the reasons, and these are the ones most often responsible:

Why the numbers differ	Effect
One device and network versus many	Lab results may look better or worse than the field average
Cold cache in the lab, warm cache for returning users	Field loads may be faster
Different LCP elements by screen size, login state, A/B tests	The measured element differs
Back/forward cache restores in the field	Near-instant loads count in field data only
Scrolling and interaction in the field	Field CLS can include shifts a lab run never triggers
Ads and personalised content	Layout shifts vary by visitor
Lab run location	One place, not your user mix

When field looks fine but lab looks bad, Google suggests investigating anyway, because lab runs can reveal room for improvement. When lab looks fine but field is poor, trust the field data and look for what the lab misses. The longer comparison is in Field Data vs Lab Data: Why Lighthouse and Real Users Disagree.

What success looks like: For any gap between the blocks you can name the most likely reason.

Step 6: Use the API for repeat checks

For several URLs, call the PageSpeed Insights API instead of pasting each one. The runpagespeed method takes a required url, a strategy of desktop or mobile (desktop is the default), and one or more category values from accessibility, best practices, performance and SEO. If you pass no category, only performance runs. Add your API key to the request. The response contains lighthouseResult (lab data, including the Lighthouse version and test environment), loadingExperience (field data for the page) and originLoadingExperience (field data for the origin). The API getting-started page also says Google plans to stop including CrUX data in this API and recommends the CrUX API or CrUX History API for field data, so check the current reference before building on those fields.

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https%3A%2F%2Fexample.com%2F&strategy=mobile&category=performance&key=YOUR_API_KEY"

Crawvix uses this API for its Lighthouse checks, running a mobile and a desktop test, so its Lighthouse results come from the same lab engine you see here.

What success looks like: A script returns the lab score and the field category for each URL on your list.

Step 7: Track results over time, not run to run

Field data reflects a trailing 28-day period and PageSpeed Insights updates it daily, so a fix shows up gradually as new visits replace old ones. Do not expect the field block to change the day you deploy. Use lab data to confirm the change worked immediately, then check the field block weekly for several weeks. Record the dates of every release beside your figures.

What success looks like: A simple log lines up releases with lab results now and field results later.

Final verification checklist

You tested the correct URL and recorded the date, device and result.
You know whether the field block is for the URL, the origin or missing.
You read each field metric against its thresholds at the 75th percentile.
You can state the Core Web Vitals assessment as pass, fail or not enough data.
You used the lab block to find a cause, not as the verdict.
You can explain any disagreement between field and lab data.
You treat field changes as lagging by up to 28 days.
No result is described as a ranking promise.

Common mistakes to avoid

Quoting the lab score as "our page speed". It is one run; field data is the experience of real visitors.
Reading origin data as page data. Check which level is shown.
Treating "no data" as a failure. It means too few samples.
Comparing mobile and desktop numbers. They use different conditions and thresholds.
Expecting field data to move the day after a fix. It averages the previous 28 days.
Fixing only what lab flags. If field metrics are fine, you may be solving a lab-only problem.
Committing your API key to a public repository. Keep it in a private configuration file or secret store.

Frequently asked questions

What is a good PageSpeed Insights score?

For the lab category scores, 90 and above is good, 50 to 89 needs improvement and below 50 is poor. The Core Web Vitals assessment is separate and depends on field data.

Why is my PageSpeed Insights score different every time?

Lab runs vary with network, hardware and page changes, so single results move. Run it several times and compare medians rather than reacting to one number.

Why does PageSpeed Insights say "no data available"?

The page and the origin did not have enough distinct samples from opted-in Chrome users, or the URL is not public. Use the lab block until traffic grows.

Does PageSpeed Insights affect my Google ranking?

The tool only reports measurements. Google recommends achieving good Core Web Vitals and says they align with what its ranking systems seek to reward, but it does not promise a boost from a good result. See Lighthouse score vs real user data: which matters?.

Mobile and desktop results differ. Which do I trust?

Both, for different audiences. Check which device most of your visitors use, and fix the weaker one first. Remember the lab devices and thresholds differ.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.