- Published
- Updated
How to read a PageSpeed Insights report
Google PageSpeed Insights is useful, but it is easy to read badly. The report mixes real-user data, lab data, Lighthouse diagnostics, Core Web Vitals, and a visible score. If those signals are treated as one simple grade, the wrong work gets prioritized.
Whether a page scored 92 or 67 matters less than whether the pages that create enquiries, bookings, sales, or trust are fast enough for real users on real devices. Knowing how PageSpeed Insights collects its data and calculates its score makes it much easier to tell those two things apart.
Start with the page being tested
Before reading the report, check whether you tested the right URL.
A homepage score is rarely enough. A website may depend on service pages, listing pages, booking flows, contact forms, checkout pages, product pages, or multilingual landing pages. Those pages may load different images, scripts, widgets, forms, maps, analytics, or payment tools.
If the important page is not tested, the report may look tidy while the business-critical flow is still slow.
Understand field data first
Field data is real-user data when PageSpeed Insights has enough data available. It comes from the Chrome User Experience Report (CrUX): timings collected from Chrome users who have opted in, aggregated over the previous 28 days and refreshed daily.
This is the section that answers: do real users actually experience this page as fast, stable, and responsive?
Three details in how Google aggregates that data change how you should read it:
- Each metric is reported at the 75th percentile. An LCP of 2.4 seconds means three out of four visits had their largest content painted within 2.4 seconds, and one in four were slower. The number deliberately leans towards the slower experiences, not the average visit.
- It is a 28-day rolling window. A fix deployed yesterday barely moves the field data. Expect it to take around four weeks before the field data fully reflects a change.
- URL data falls back to origin data. If the exact URL has too few samples, PageSpeed Insights shows data for the whole origin instead. That number mixes the homepage, articles, and every other page, so it can hide a slow template or flatter one.
The coloured bars under each metric show the distribution: the share of visits that were good, needed improvement, or were poor. A page can sit just inside “good” at the 75th percentile and still have a substantial red slice, which is worth knowing if that slice is the mobile visitors trying to book.
Read field data before the score when it is available. Pay attention to:
- Whether the data is for the exact URL or the whole origin
- Whether mobile and desktop tell different stories
- Whether the page passes Core Web Vitals
- Which metric is weak: LCP, CLS, or INP
- Whether the problem matches real business complaints
Field data can be missing for new pages, low-traffic pages, and private pages. Missing field data does not mean the page is fast. It means PageSpeed Insights does not have enough real-user evidence for that view.
Know the Core Web Vitals thresholds
PageSpeed Insights groups Core Web Vitals into loading, visual stability, and responsiveness.
The current public thresholds are:
- Largest Contentful Paint (LCP): good at 2.5 seconds or faster
- Cumulative Layout Shift (CLS): good at 0.1 or lower
- Interaction to Next Paint (INP): good at 200 milliseconds or faster
The pass or fail verdict at the top of the field data follows a specific rule. When all three metrics have enough data, all three must be good at the 75th percentile. If INP lacks data, which is common on pages with little interaction, LCP and CLS passing is enough. If LCP or CLS lacks data, the page or origin is not assessed at all.
Do not read those numbers mechanically. A page can technically pass and still feel poor if the lead form, booking widget, or navigation becomes usable late. A page can also fail one metric because of a specific template or third-party script that needs focused work rather than a full rebuild.
For the metric details, read the Core Web Vitals guide.
How the performance score is calculated
The large performance score comes from a single Lighthouse lab run, not from field data. Lighthouse loads the page once under controlled conditions (for mobile, a simulated mid-range phone on a throttled connection), measures five metrics, and combines them into one number.
In Lighthouse 10, the weights are:
| Lab metric | Weight | What it stands for |
|---|---|---|
| Total Blocking Time (TBT) | 30% | How long the main thread was blocked during loading |
| Largest Contentful Paint (LCP) | 25% | When the main content appeared |
| Cumulative Layout Shift (CLS) | 25% | How much the layout moved |
| First Contentful Paint (FCP) | 10% | When anything appeared |
| Speed Index | 10% | How quickly the visible page filled in |
INP is not in the score. A lab run that only loads a page does not click anything, so it cannot measure interaction latency. Total Blocking Time is its lab stand-in: heavy JavaScript that blocks the main thread during loading tends to make interactions slow as well. This is why a page can score in the 90s and still fail INP in the field data, for example when a booking widget or filter only becomes expensive once someone uses it.
Each raw metric is converted to a 0–100 score on a curve built from real-world HTTP Archive data. A value equal to the 25th percentile of sites scores 50. A value equal to the 8th percentile, faster than roughly 92% of sites, scores 90. Above about 96, each extra point requires a disproportionately large improvement. Going from 70 to 90 is usually worthwhile engineering. Going from 96 to 100 rarely is.
The score also varies between runs without any change to the page. Network routing, the load on the test machine, A/B tests, and ads that differ between runs all move it. Treat a difference of a few points as noise, and compare several runs before calling something a regression.
That makes the score useful for comparing controlled tests, especially before and after technical changes. It is less useful as a business KPI. Use it to ask better questions:
- Did the score drop after a release?
- Does mobile perform much worse than desktop?
- Did a specific fix improve the lab result?
- Are the same problems repeated across important templates?
Do not use the score as the whole task list.
Separate lab data from field data
Lab data is a controlled test. Field data is what real users experienced.
Both matter, but they answer different questions.
| Signal | What it tells you | Main limitation |
|---|---|---|
| Field data | How real users experienced the page or origin | May be missing, aggregated, or delayed |
| Lab data | What happened in one controlled Lighthouse test | May not match all real devices, networks, or regions |
| Diagnostics | Likely causes and technical clues | Needs engineering judgement before implementation |
If field data is poor but the lab run looks good, look for traffic patterns, third-party variance, geography, device mix, or pages that differ from the tested URL. If lab data is poor but field data looks fine, still review the issues, but prioritize based on business impact.
What the PageSpeed Insights API returns
The structure behind the report becomes clearer when you look at the raw response from the PageSpeed Insights API. A request to runPagespeed with a URL and a strategy (mobile or desktop) returns three separate blocks:
loadingExperience: field data for the exact URL, with each metric’s 75th-percentile value, its distribution, and an overall category.originLoadingExperience: the same field data for the whole origin.lighthouseResult: the lab run, including the Lighthouse version, every audit, and the category scores, which are stored as decimals from 0 to 1 and shown multiplied by 100.
The report page is those three sources placed side by side. They are measured differently, cover different time spans, and can disagree without anything being wrong.
The URL Analyzer on this site calls the API with the mobile strategy. It uses URL-level field data when Google has it, falls back to origin data when it does not, and records which of the two it used, because a passing origin can hide a slow page. It also keeps the Lighthouse version and run warnings, which explain many score changes that are not caused by the page itself.
One change to plan for: Google’s API documentation states that it plans to stop including CrUX field data in the PageSpeed Insights API and recommends the CrUX API or the CrUX History API instead. No date has been announced. If you build monitoring on the PageSpeed Insights API, keep the field data lookup separate so it can be moved to the CrUX API without rewriting the rest.
Read the diagnostics as clues, not orders
PageSpeed Insights lists diagnostics and recommendations from the Lighthouse run. They are useful, but they are not automatically the backlog.
Common findings include image size, unused JavaScript, render-blocking resources, long main-thread work, third-party scripts, font loading, cache policy, layout shifts, and server response time.
The important question is always: which finding explains the problem users feel?
For example:
- If LCP is poor, look at server response, the main image, render-blocking CSS, and when the main content appears.
- If CLS is poor, look at image dimensions, injected banners, embeds, late-loading fonts, and booking widgets.
- If INP is poor, look at JavaScript cost, long tasks, event handlers, and heavy components around forms or menus.
The same warning can matter a lot on one site and barely matter on another.
Check mobile and desktop separately
Mobile and desktop reports should be read separately.
For many businesses, mobile is the most important view. Customers often use phones when comparing services, checking locations, sending enquiries, or making bookings.
Desktop can still matter for B2B, admin-heavy flows, and overseas owners reviewing a property, booking platform, or service provider. But a desktop score should not hide a poor mobile experience.
Decide when to use another tool
PageSpeed Insights is a starting point, not the full investigation.
Move to another tool when the report raises questions it cannot answer:
- Use Lighthouse in Chrome DevTools when you need to reproduce and test fixes locally.
- Use WebPageTest when you need a waterfall, filmstrip, repeat view, test location, or detailed request timing.
- Use Search Console when you need Google-specific Core Web Vitals field data across the site.
- Use browser DevTools when you need to inspect network requests, JavaScript errors, layout, headers, or caching.
The guide to PageSpeed Insights, Lighthouse, and WebPageTest explains how those tools fit together.
Turn the report into work
A PageSpeed report should produce a short, prioritized list, not a giant cleanup project.
For a smaller website, useful next actions often look like:
- Compress or replace the main image on important pages
- Preload or prioritize the real LCP element
- Remove or delay non-essential third-party scripts
- Fix image dimensions and reserved space to reduce layout shifts
- Reduce JavaScript around menus, filters, booking widgets, and forms
- Improve cache headers and CDN delivery
- Check server response time before optimizing front-end details
The best fixes are usually tied to templates and user flows, not isolated warnings.
Official references
PageSpeed Insights changes over time, so the exact interface should be checked against official documentation. Useful references:
- Google PageSpeed Insights documentation
- PageSpeed Insights API documentation
- web.dev Core Web Vitals documentation
- Lighthouse performance scoring documentation
Use those docs for exact interface and metric details. Use the report itself to guide investigation, not to replace judgement.
From report to real performance
The real result is not a better report. It is a page that loads useful content quickly, stays stable, responds to interaction, and helps the visitor complete the next step.
If a website has a PageSpeed report that looks confusing, send me the URL and the report context. I can help interpret the signal, separate noise from useful work, and point to targeted fixes.