PageSpeed Insights Explained: Lab vs Field Data

PageSpeed Insights shows two different measurements on the same page, and most confusion comes from mixing them up. The top section is field data — what real Chrome users experienced on your page over the last 28 days. The bottom section is lab data — one simulated page load, run by Lighthouse on the spot, which produces the familiar 0–100 performance score. Google's Core Web Vitals assessment uses the field data. The score is a diagnostic tool, not a verdict.

This guide covers what each section measures, why they disagree, how the score is calculated, and which numbers are worth acting on.

What is PageSpeed Insights?

PageSpeed Insights is Google's free tool at pagespeed.web.dev. You enter a URL, and it returns real-user data from the Chrome User Experience Report (CrUX) where available, plus a Lighthouse lab test with suggested fixes. It has separate Mobile and Desktop tabs; mobile is the one to focus on for most business sites, because it is where real visitors are most likely to struggle.

The top section: field data

According to Google's PageSpeed Insights documentation, field data comes from the Chrome User Experience Report and covers a trailing 28-day collection period. It reflects real visitors, on their own phones and connections.

Key points about how it works:

• Each metric is reported at the 75th percentile. If your LCP is shown as 2.4 seconds, three quarters of visits were at least that fast. The slowest quarter of visits is what this number is protecting.
• It falls back from page to origin. If one URL does not have enough data, PageSpeed Insights shows data for the whole site (the origin). If the origin does not have enough either, there is no field data at all.
• It moves slowly. Because it is a 28-day window, a fix made today takes weeks to show fully.

The Core Web Vitals assessment at the top passes only when LCP, INP and CLS are all in the "good" range at the 75th percentile. The field section also shows supporting metrics such as First Contentful Paint and TTFB. Core Web Vitals explained covers the thresholds for each metric.

The bottom section: lab data and the score

The lab section is a Lighthouse test: one page load, simulated on a mid-range mobile device over a throttled connection (or an emulated desktop for the Desktop tab), run from Google's servers. It produces:

• the performance score, from 0 to 100
• lab values for several metrics
• diagnostics — specific opportunities such as oversized images, render-blocking resources and unused JavaScript

How the performance score is calculated

The score is a weighted blend of five lab metrics. In the current Lighthouse scoring, documented on Chrome's Lighthouse performance scoring page, the weights are:

Notice that INP is not in the list. INP measures real interactions, which a lab load cannot reproduce. Total Blocking Time is the lab stand-in: a page with heavy main-thread work in the lab is likely to respond slowly to real taps. How to improve INP covers the real-world version.

Why do lab and field data disagree?

They measure different things, so disagreement is normal.

When they disagree, trust the field data for "is there a problem?" and use the lab report for "where should I look?".

How to use PageSpeed Insights properly

1. Read the field data first. Does the page or origin pass Core Web Vitals on mobile? If yes, the site is in good shape for real users, whatever the score says.
2. If it fails, note which metric. That decides where you look next: LCP, INP or CLS each have different causes.
3. Use the lab diagnostics to find causes, filtered to the failing metric. The report can show which audits relate to LCP, TBT or CLS.
4. Test the right pages. Check one of each template — home, a service page, an article, a product page — not just the homepage.
5. Run the lab test more than once before deciding a change made a difference.
6. Confirm in Search Console. The Core Web Vitals report groups similar URLs, which is more useful for a whole site than testing pages one by one. The Google Search Console guide explains where to find it.
7. Wait for the field data to catch up after a fix — up to 28 days.

Reading the diagnostics without panicking

The lab report lists every possible improvement, including ones that would save a few milliseconds. Sort them by estimated saving and ignore the long tail. Common worthwhile items are:

• an oversized or lazy-loaded hero image, which delays LCP — see how to improve Largest Contentful Paint
• slow server response, which delays everything — see how to reduce server response time
• large amounts of unused JavaScript from plugins or third-party tags
• images without dimensions, causing layout shift

For a working list of fixes in order, the website speed optimisation checklist is the companion to this article.

A worked example

Say a service business tests its homepage and gets a mobile score of 54, with the field data showing LCP at 3.1 seconds, INP at 180 milliseconds and CLS at 0.02. The Core Web Vitals assessment fails — but only on LCP. INP and CLS are already good.

That changes the job. There is no point spending time on layout shift or interactivity. Filter the lab diagnostics to LCP, and the likely culprits appear: a 900KB hero image that is lazy-loaded, a web font blocking text rendering, and a server response of around a second on uncached loads. Fixing those three is a few hours' work. The score might rise to the 80s; more importantly, LCP in the field should move under 2.5 seconds over the following four weeks.

Had the owner chased the score instead, they might have spent days removing analytics and chat scripts to raise Total Blocking Time — improving a number while the metric that was actually failing stayed failed.

What the score is not

It is not a ranking factor, it is not what Google uses to judge page experience, and it is not a measure of how fast your site feels to your actual customers. Anyone selling a guaranteed score of 100 is selling a lab number.

If you would like someone to read the reports and fix what matters, performance work is part of the WordPress development service, and monthly checks against field data are part of the website maintenance service. The WordPress speed optimisation showcase shows the diagnostic order in practice.