Google PageSpeed Insights: how to read the report and what to fix first

PageSpeed Insights is Google's free speed report for one URL at a time, and it gives you two different things in one screen. The top is field data: what real Chrome visitors actually experienced on that page over the last 28 days. The bottom is lab data: a single simulated test run right now, and that run is where the score out of 100 comes from. Read the field data to know whether you have a problem, and read the lab data to find out what is causing it.

Most of the confusion about this tool comes from treating the two halves as one number. They disagree often, and when they disagree the field data is the one that describes your visitors. No account is needed to run it, and you can run it on a competitor's URL as easily as your own.

The top half: field data from real visits

The section headed with your real users comes from the Chrome User Experience Report, a public dataset of anonymised measurements from Chrome users who opted in. It is a rolling 28 day window, and each metric is reported at the 75th percentile, which means three out of four page loads were at least this good.

Two things follow from that. First, the field data is slow to move. Ship a fix today and the 28 day window still contains three and a half weeks of the old page, so give it a month before you judge the result. Second, a page with little traffic has no field data of its own. PageSpeed Insights then falls back to origin level data, which is every page on your domain combined, and tells you it has done so. That origin number is still a useful health check on the site as a whole.

The bottom half: the lab run and the score

The lower section is Lighthouse. It loads the page once in a controlled environment, by default an emulated mid range mobile device on a throttled connection, and scores what it sees. That score is a weighted average of five measurements.

Metric	Weight in the performance score
Total Blocking Time	30 percent
Largest Contentful Paint	25 percent
Cumulative Layout Shift	25 percent
First Contentful Paint	10 percent
Speed Index	10 percent

The bands are fixed: 0 to 49 shows red, 50 to 89 orange, 90 to 100 green. Three metrics carry 80 percent of the score between them, and all three are mostly about JavaScript and images rather than hosting. That is why buying a faster server often moves the number very little.

Because it is one run, the lab score moves between tests. A third party tag that loads on one request and not the next, a cold cache, a busy test queue: any of these shift it by several points. Run it three times and work from the middle result, and treat a change of under five points as noise. For a decision that matters, use the field data.

The three metrics worth your attention

• Largest Contentful Paint is when the biggest thing in the first screen finishes rendering. Good is 2.5 seconds or less.
• Interaction to Next Paint is how long the page takes to respond visibly to a tap or a click. Good is 200 milliseconds or less. This one appears in field data only, because a lab run has nobody tapping anything. Total Blocking Time is the lab stand in for it.
• Cumulative Layout Shift is how much the layout jumps around while loading. Good is 0.1 or less.

These three are the Core Web Vitals, and they also appear in Search Console grouped across your whole site. For the thresholds in full and the cause of each failure, see Core Web Vitals.

What to fix, in the order that pays

Work down this list and stop when the field data goes green. The opportunities panel in the report is sorted by estimated saving, which is a good guide, and the diagnostics underneath it usually tell you more.

What the report says	What is usually behind it	The fix
Largest Contentful Paint element is an image	The hero image is full resolution, lazy loaded, or discovered late	Serve it in WebP or AVIF at the size it displays, set fetchpriority high, and never lazy load anything in the first screen
Eliminate render blocking resources	Stylesheets and fonts in the head that block the first paint	Inline the styles the first screen needs, load the rest asynchronously, and self host fonts with font-display swap
Reduce unused JavaScript	A page builder, a slider, or tag manager containers firing on every page	Split bundles per template, defer anything not needed for the first interaction, and audit what each tag is for
Reduce the impact of third party code	Chat widgets, heat maps, ad scripts, consent tools	Load them after the page is interactive, or on first scroll, and remove the ones nobody reads the output of
Image elements do not have explicit width and height	Reserved space is missing, so content jumps when images arrive	Set width and height attributes or a CSS aspect ratio on every image, ad slot and embed
Reduce initial server response time	Slow application code, no caching, or an origin far from your visitors	Cache the HTML, put a CDN in front, and check database queries on the slowest template

Running it on more than one page

PageSpeed Insights measures a single URL, so test one example of each template rather than every page: the home page, a category page, a product or service page, an article, and the form that takes the money. Those five cover almost every performance problem a site has.

For site wide work, two other free routes help. The Core Web Vitals report in Search Console groups your URLs into good, needs improvement and poor using the same field data, so you can see how many pages a single template fix will move. The PageSpeed Insights API runs the same test from a script, which is how you track a list of URLs on a schedule.

This page covers the PageSpeed Insights report: what each half measures, how the score is built, and what to change. For how much speed work is worth doing against everything else on your list, see site speed and SEO. For the phone specific checks that sit alongside it, see mobile SEO.

Asked and answered: Google PageSpeed Insights

Why does my report say there is not enough field data?

That page has too few Chrome visits in the last 28 days for the dataset to report it on its own. The origin level summary shown instead is a fair proxy for the site, and the lab run below it still tells you exactly what to fix on that URL.

Does a score of 100 improve my rankings?

Speed is one of the signals Google describes in its page experience guidance, and Google is clear that relevant content comes first. The practical read is that it settles close contests and that it moves conversion directly, which is usually the bigger prize. Get into the green bands, then spend the rest of your effort on the page itself.

Why do PageSpeed Insights and Search Console show different numbers?

Search Console reports field data only, grouped across many URLs. The score you are comparing it with is a single lab run on one URL. Compare field to field and the two line up.

Should I test mobile or desktop?

Fix mobile first, because it is the throttled test, it is where most visits come from in most categories, and it is the version Google indexes. Check desktop afterwards for layout shift, which often differs.

How often should I run it?

Run the lab test on every template before a release so a regression never ships. Check the field data monthly, which matches the pace the 28 day window moves at, so you are always working from current numbers.

One more report on the same page

PageSpeed Insights tells you how a page loads for people. A companion check tells you how it reads for an assistant: whether the main text is in the HTML, whether it answers the question near the top, and whether it is cited when asked.

Pick one fast page and test it. Ask an assistant the question that page answers. If it is not used, view the page source and see if the text is actually there. Speed and readability are separate. AI Knows Us shows which pages are cited in answers to your buyer questions, the reading this report leaves out.