How to read PageSpeed Insights

PageSpeed Insights puts two different measurements on one page: what real Chrome users experienced on your site over the last 28 days, and what a single simulated visit with Lighthouse measured a few seconds ago. Most confusion about the report, from a green score with a failed Core Web Vitals assessment to a score that changes on every run, comes from reading one part as if it were the other. This guide walks through the report from top to bottom, explains what each block is based on, and ends with an order for deciding what to fix first.

From PerfDelta's measurements: Of 5,987 measured websites, 5,749 have origin-level field data in the Chrome UX Report; for the rest, PageSpeed Insights shows only the lab test. Of the websites with field data, 48% pass the Core Web Vitals. More in the data section below.

The two halves of the report: field data and lab data

The upper part, headed Discover what your real users are experiencing, shows field data from the Chrome UX Report (CrUX). It is collected from Chrome users who opted in to usage statistics, aggregated over a rolling 28-day window and reported at the 75th percentile: three out of four page views were at least this fast. These are the values Google uses for the Core Web Vitals in Search, and they change slowly, because one day of new data replaces one day out of 28.

The lower part, headed Diagnose performance issues, is a Lighthouse lab test. Google loads the page once from its own servers, on mobile with an emulated mid-range phone (Lighthouse 13 emulates a Moto G Power) on a throttled slow 4G connection, on desktop without the phone emulation. The performance score, the five lab metrics and every insight and diagnostic below come from that one load.

	Field data (top)	Lab data (bottom)
Source	Chrome UX Report, real Chrome users	One Lighthouse run on Google's servers
Period	Last 28 days, updated daily	The moment you clicked Analyze
Value shown	75th percentile of all page views	The result of a single load
Metrics	LCP, INP, CLS, plus FCP and TTFB	FCP, LCP, TBT, CLS, Speed Index
Used for	Core Web Vitals assessment, Google Search	Performance score, debugging

The lab test has no visitor who clicks or types, so it cannot measure Interaction to Next Paint. Total Blocking Time takes its place as a stand-in for main-thread congestion during load.

Core Web Vitals Assessment: Passed or Failed

The first line of the field section is the verdict: Core Web Vitals Assessment: Passed or Failed. It passes only if all three Core Web Vitals are in the good range at the 75th percentile:

• Largest Contentful Paint at most 2.5 seconds,
• Interaction to Next Paint at most 200 milliseconds,
• Cumulative Layout Shift at most 0.1.

One metric in the needs-improvement range is enough for "Failed", even if the other two are excellent. If there are too few interactions for INP, the assessment is based on LCP and CLS alone. First Contentful Paint and Time to First Byte are shown as other notable metrics and do not affect the verdict.

To find out why the assessment failed, look at the coloured bar under each metric. It shows the share of page views that were good, needed improvement or were poor. A metric whose 75th percentile sits just above the threshold, with most of the bar green, needs a small improvement; a metric with a large red share needs a structural fix. The Core Web Vitals guide explains the three metrics and their thresholds in detail.

This URL or Origin: which field data you are looking at

Above the field data there are two tabs, This URL and Origin. This URL shows data for exactly the address you entered. Origin aggregates every page on the same protocol and host, for example everything on https://www.example.com, weighted by traffic. A URL only gets its own values when it has enough Chrome traffic in the 28-day window. Without them, PageSpeed Insights says there is not enough data for this URL and offers the origin instead.

Three consequences are easy to get wrong:

• The origin is dominated by the pages with the most traffic. A fast home page and a slow product template can produce an origin value that matches neither.
• http and https, and www and the bare domain, are separate origins in CrUX. Test the address your visitors actually land on.
• When a URL has no data of its own, the Core Web Vitals report in Search Console lists it as part of a group of similar URLs. Improving one page then shows up there only when the group as a whole improves.

Why the performance score differs from the field data

A score of 45 next to a passed assessment, or a score of 95 next to a failed one, is not a contradiction. The score is calculated from five lab metrics with fixed weights (Total Blocking Time 30 percent, LCP and CLS 25 percent each, FCP and Speed Index 10 percent each), and each metric is placed on a curve derived from HTTP Archive data. The Lighthouse performance score guide shows the calculation with an example. The field data, in contrast, reflects your actual visitors. The two drift apart for predictable reasons:

• Device and network. The lab phone and connection are deliberately slow. If most of your visitors use recent phones on fast networks, the field is better than the lab; on a site with an audience on budget devices it can be the other way round.
• Cache and repeat visits. The lab always loads with an empty cache. Real visitors often have your CSS, fonts and scripts cached, and back/forward navigations can be restored instantly from the back/forward cache.
• Interactions. TBT in the lab only covers the load. INP in the field covers every click and keypress during the whole visit, including menus, filters and consent banners.
• Layout shifts after load. The lab sees only shifts during load. Shifts caused by scrolling, lazy-loaded ads or late content count in the field.
• Run-to-run variance. Server response, third-party scripts and A/B tests change between runs, so the score can move by several points without any change on your side. Compare the median of several runs rather than single results.

For ranking, only the field data counts. Treat the score as a diagnostic summary of one load, not as the target.

Insights and diagnostics in Lighthouse 13

Since Lighthouse 13, which PageSpeed Insights has used since October 2025, the old list of opportunities is replaced by Insights, the same analyses the Performance panel of Chrome DevTools shows after a recording. A remaining group of Diagnostics covers checks that have no insight yet. Neither group changes the score directly; they explain where the lab metrics come from. The table maps each insight to the metric it mainly affects and to the guide that explains the fix.

Insight (Lighthouse 13)	Mainly affects	Guide
Render-blocking requests	FCP, LCP	Render-blocking resources
LCP breakdown	LCP	LCP breakdown
LCP request discovery	LCP	Preconnect and preload
Network dependency tree	FCP, LCP	Preconnect and preload
Document request latency	TTFB, FCP, LCP	Time to First Byte
Improve image delivery	LCP, page weight	Improve image delivery
Use efficient cache lifetimes	Repeat visits	Efficient cache lifetimes
Font display	FCP, CLS	font-display
Layout shift culprits	CLS	Layout shift culprits
INP breakdown	INP	INP breakdown
Forced reflow	TBT, INP	Forced reflow
Optimize DOM size	INP, TBT	Reduce DOM size
Legacy JavaScript, Duplicated JavaScript	TBT, page weight	Legacy JavaScript
3rd parties	TBT, INP	Third-party code
Modern HTTP	Loading of many small files	flags HTTP/1.1 when six or more static files come from one origin
Optimize viewport for mobile	INP on mobile	a missing viewport meta tag can delay taps by up to 300 ms

Among the diagnostics, Reduce unused JavaScript, Reduce unused CSS, Minify JavaScript and CSS, Reduce JavaScript execution time, Minimize main-thread work and Avoid long main-thread tasks are the ones that most often point at a fix. The savings shown next to an insight are estimates from the lab model; use them to rank, not as a promise.

What to fix first

1. Start with the failed field metric on mobile. Switch to the Mobile tab and note which of LCP, INP or CLS is not green. That metric decides the work, not the colour of the score.
2. Check whether the data is for the URL or the origin. With origin data only, find out which page templates carry the most traffic and test those, because they drive the origin value.
3. Pick the insights that belong to that metric. For LCP: LCP breakdown first, then LCP request discovery, render-blocking requests, document request latency and image delivery. For INP: INP breakdown in DevTools, then 3rd parties, forced reflow, DOM size and JavaScript execution. For CLS: layout shift culprits and font display.
4. Fix the cause with the largest share. If the LCP breakdown shows that most of the time is resource load delay, a smaller image will not help; the image has to be discovered earlier.
5. Verify in the lab, confirm in the field. The lab result changes immediately. The field data needs up to 28 days until the old values have rolled out of the window.

Several pages and competitors: beyond a single-URL test

PageSpeed Insights reports on one URL per test. How your other templates perform, how your competitors compare, or whether last week's deployment made things worse needs further tests. The free PerfDelta website speed test measures several pages of a site on mobile and desktop in one run, shows field and lab data side by side, compares them with up to two competitors and links every finding to the matching guide. For a field-data comparison of up to five sites without a lab run, use the Core Web Vitals benchmark.

Frequently asked questions

Why does PageSpeed Insights say "Core Web Vitals Assessment: Failed" when my score is green?

The assessment uses field data from real users over 28 days; the score uses one lab load. A fast lab load on a powerful test setup says nothing about the interactions and devices of your visitors. If INP fails in the field, the score cannot show it, because the lab does not measure INP.

Why is there no field data for my page?

The Chrome UX Report only contains URLs and origins with enough traffic from Chrome users who share usage statistics. New, small or rarely visited pages have none. PageSpeed Insights then offers the origin data, and if the origin has none either, only the lab test is available.

Why does my score change every time I run the test?

Each run is a new load with its own server response time, third-party responses and network conditions on Google's side. Variations of a few points are normal. Run the test three to five times and use the median, or test in an environment you control.

Which should I trust, the field data or the lab data?

For the question "does my site pass", the field data. For the question "why is it slow", the lab data, because it shows the requests, the main-thread work and the elements involved. The two answer different questions.

How long does it take until a fix shows up in PageSpeed Insights?

In the lab section immediately, in the field section gradually over up to 28 days, because each day of new data replaces one day of old data in the rolling window.