PageSpeed Insights: How to Read the Report and What to Fix First

PageSpeed Insights shows two different reports on one page: real data from Chrome users over the last 28 days and a lab test by Lighthouse on an emulated low-end phone. So a score of 42 in a red circle does not yet mean the site is slow for your customers, and a green "passed" in the top block matters more than any number below it. Here is how to read the report, which recommendations to fix first, who should actually do it and why chasing a score of 100 rarely pays off.

Two blocks in the report and why their numbers differ

You open pagespeed.web.dev, paste a URL and wait about twenty seconds. The top block is titled "Discover what your real users are experiencing". This is field data from the Chrome User Experience Report (CrUX): anonymous statistics from actual visitors of your site using Chrome over 28 days. Google looks at the 75th percentile, in other words the experience of three quarters of users, and issues the verdict "Core Web Vitals passed" or "failed". This verdict is what Search takes into account. If traffic is low, the block stays empty: there is not enough data for the page or even the whole domain.

Below it comes the lab test from Lighthouse. A Google server loads the page once, emulating a mid-range Android phone on slow 4G, and computes a score from 0 to 100. This is synthetic: one run, one location, artificially throttled CPU and network. The numbers in the two blocks disagree all the time, and that is normal. Field data tells you what actually happens. The lab tells you where the bottleneck is and hands you a list of recommendations.

A practical rule we use at Query: read the field verdict as the diagnosis and the lab score as a hint about where to start. Arguing with a client over 67 versus 71 in the lab makes no sense; two consecutive runs can differ by 10 points.

What the 0 to 100 score means and why 100 is not the goal

The website speed score in Lighthouse is a weighted blend of five metrics. As of publication: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, Speed Index 10%. Colour zones: 0 to 49 red, 50 to 89 orange, 90 to 100 green.

Three things worth knowing about this score. First, it is non-linear. Taking a site from 30 to 60 is usually cheaper than from 85 to 95. Second, the score is computed for one page, not the site. The homepage can sit at 90 while a product page with a reviews widget sits at 35. Third, Google does not use the lab score in ranking. What matters for Search is the field Core Web Vitals, and those thresholds are softer than a "green hundred".

So the practical target for a commercial site, in our experience: consistently above 50 on mobile in the lab and "passed" in field data. Beyond that, every point costs more and the business effect fades. The exception is media and large catalogues with traffic in the millions, where every tenth of a second shows up in revenue.

The five metrics you will see in the report

• LCP (Largest Contentful Paint): how long until the biggest element on screen appears, usually a banner or a heading. Good is up to 2.5 s.
• INP (Interaction to Next Paint): how quickly the page responds to a click or tap. Good is up to 200 ms. Replaced FID in March 2024.
• CLS (Cumulative Layout Shift): how much the layout jumps around while loading. Good is up to 0.1.
• FCP (First Contentful Paint): when the first text or image appears. Good is up to 1.8 s.
• TTFB (Time to First Byte): how long the server thinks before responding. Good is up to 0.8 s. Field data only.

The first three are the Core Web Vitals that drive the verdict. What each one means physically and how to improve them one by one, we covered in detail in our article on Core Web Vitals, so we will not repeat that here.

The "Diagnostics" and "Opportunities" sections: how to prioritise

Under the metrics, Lighthouse prints two lists. "Opportunities" come with an estimated saving in seconds: "Serve images in next-gen formats, estimated savings 3.2 s". "Diagnostics" have no seconds; these are structural notes: "Avoid an excessive DOM size", "Minimize main-thread work". Both lists often run to 15 or 20 items, and the developer who received a screenshot has no idea where to begin.

We sort differently: first by which metric the recommendation affects (LCP and CLS weigh 25% each), then by the estimated saving, and only then by effort. Even more important is deciding who owns each item, because half of the notes are not for the developer at all.

Top 8 fixes by impact

This list is built from what most often produced the biggest gains on typical sites running WordPress, OpenCart, Laravel and site builders. The order is approximate; every site has its own bottleneck.

1. Images. Compression, WebP or AVIF, srcset for mobile, lazy loading for everything below the fold. This is often half the page weight gone and the biggest jump in LCP.
2. Page cache and fast hosting. If TTFB is over a second, no front-end optimisation will save you. HTML caching, a current PHP version, OPcache, and Redis for stores.
3. Third-party scripts. Every chat widget or pixel costs 100 to 500 ms of blocking. Anything not needed for the first screen loads with a delay or after interaction.
4. Critical CSS and deferred JS. First-screen styles inline, the rest asynchronously, scripts with defer.
5. Fonts. Self-hosted instead of Google Fonts, WOFF2 format, character subsets, font-display: swap. Often half a second off FCP.
6. Explicit dimensions for images, video and ad slots. Removes most CLS problems in a single day of work.
7. Preload for the LCP element. The hero banner with fetchpriority="high" and preconnect to the CDN.
8. Cleaning up unused code. The longest and most expensive, hence last: disabling redundant plugins, bundle splitting, replacing heavy libraries.

Items 1, 2 and 6 usually cover the path from red to orange. Items 3 to 5 get you to a green verdict in field data. Item 8 is for those who need 90+.

Mobile versus desktop

PSI shows separate tabs, and a gap of 30 to 40 points between them is common. Desktop is tested without CPU throttling and on a fast network, so it is almost always green. The mobile test emulates a mid-range phone on slow 4G, and that is the one showing the real picture for most audiences: in commercial niches mobile traffic passed the halfway mark long ago. Google also indexes sites by their mobile version. So look at the mobile tab and plan the work around it. The desktop score is useful mainly for B2B sites visited from office computers.

How to verify after the fixes

The most common mistake after optimisation: one PSI run, 48 instead of 45, conclusion "it did not help". The working routine looks like this.

1. Before starting, record a baseline: 3 to 5 mobile runs on 3 or 4 typical pages (homepage, category, product, article); note the median, not the best result.
2. After each round of fixes, repeat the same runs. Compare the metrics (LCP, TBT, CLS), not just the overall score.
3. Field data updates with a lag: CrUX collects a 28-day window, so the "passed" verdict changes a month after the fixes, not the next day.
4. Search Console has a Core Web Vitals report with URL groups: it shows how many pages of the site are in the red zone, not just the one you tested.
5. For ongoing control, set up monitoring: PSI has a free API, and you can pull the numbers for key pages automatically once a week.

If you cannot close the list on your own, we do this kind of work as part of technical site improvements: report audit, splitting items between hosting, content and code, the fixes themselves, control measurements. The main takeaway from this article: a PageSpeed Insights report is not a grade on a report card but a list of hints, and you read it from the top, starting with field data, not from the colour of the circle.