You pasted your web address into Google’s PageSpeed Insights, waited while it ran, and got back a long page of coloured circles, bars, three-letter abbreviations and a list of warnings with names like “reduce unused JavaScript”. Somewhere near the middle there is a big number, probably orange or red on mobile. The question is what to do with all of it.
This is a guide to how to read a PageSpeed Insights report the way a developer reads it: from top to bottom, knowing which parts describe real visitors, which describe a single test, and which warnings you can safely leave alone. Google adjusts the layout and wording from time to time, so we describe the sections by what they do rather than by exact button labels.
Before the report: the address and the two tabs
PageSpeed Insights tests one URL at a time. The report you get is for that exact address, not your whole site, so a good result for the home page says nothing about your product pages. Test each important template separately.
Once the test finishes, you will see the report split into a mobile view and a desktop view, with mobile normally shown first. They are separate tests with separate data. Switch between them deliberately and do not mix their figures in your notes. If you are new to this, start with mobile; it is usually the weaker result and the one closer to many visitors’ experience.
Section one: what your real users are experiencing
The top block, when it appears, is not a test at all. It is field data from the Chrome User Experience Report: anonymised measurements from real Chrome users who visited the page over the previous 28 days. It shows:
- The Core Web Vitals assessment, a simple passed or failed verdict. It is based on the three Core Web Vitals (loading, responsiveness and visual stability, abbreviated LCP, INP and CLS), each judged at the 75th percentile of visits.
- A bar for each metric, split into good, needs improvement and poor, with a marker showing where the 75th percentile falls.
- A few other metrics such as First Contentful Paint and Time to First Byte. Google treats these as diagnostic, not as Core Web Vitals, so they do not decide the pass or fail.
- A switch between this URL and the whole origin. If the individual page does not have enough visits, the report may show data for your whole domain instead, or nothing at all.
“No data” or a message about insufficient real-user data is common for small business sites and is not an error. It means not enough Chrome users loaded that page for Google to publish figures. You can still use the lab section below.
Why the numbers here often look better or worse than the lab score, and which to trust for which decision, is its own topic: our post on field data versus lab data covers it. For this walkthrough, remember one thing: the top block is history from real people; everything below it is one simulated visit.
Section two: diagnosing performance in the lab
Below the field data, PageSpeed Insights runs Lighthouse on Google’s servers and shows the result. Four circles appear: Performance, Accessibility, Best Practices and SEO. Only the first is about speed. The others are useful checklists, but do not confuse a green SEO circle with good rankings or a red Accessibility circle with a slow page.
The performance score
The Performance number is from 0 to 100, coloured red (0-49), orange (50-89) or green (90-100). It is calculated from a handful of lab metrics, each weighted, so it is a summary rather than a measurement in its own right. The report itself notes that values are estimated and may vary. Treat a change of a few points as noise.
The lab metrics
Under the score you will see five metrics. In plain terms:
- First Contentful Paint (FCP): when the first text or image appeared.
- Largest Contentful Paint (LCP): when the biggest element in view, often a hero image or main heading, finished showing.
- Total Blocking Time (TBT): how long the browser’s main thread was tied up by long tasks, mostly JavaScript, between first paint and the page becoming usable. It is the lab’s rough stand-in for responsiveness, because a lab test has no real person tapping the screen.
- Cumulative Layout Shift (CLS): how much visible content jumped around while loading.
- Speed Index: how quickly the visible area filled in overall.
Of these, LCP, TBT and CLS carry most of the weight in the score. If you only look at three figures, look at those.
The test conditions
Somewhere near the lab results the report lists how the test was run: an emulated mobile device, a throttled connection, the Lighthouse version, and the fact that it was a single page load. This matters when you compare reports. A result from months ago may have used a different Lighthouse version, which on its own can shift a score.
The screenshots
A strip of small screenshots shows the page at intervals as it loaded, and there is usually a final screenshot too. Look at it. A long run of blank frames points to something blocking the first paint. A hero image arriving late explains a slow LCP. If the final screenshot shows a cookie banner or popup covering the page, that banner may be what the test is calling the largest element.
Section three: the list of suggestions
Below the metrics comes the long list that most people find overwhelming. Older versions of the report divided it into Opportunities, which came with an estimated saving in time or file size, and Diagnostics, which described the page without a direct saving. Newer versions regroup many of these checks as “insights”. The idea is the same in both: some items point to a concrete fix with a likely gain, others are background information.
Some practical ways to read the list:
- Use the metric filter. The report lets you show only the audits related to one metric, such as LCP or TBT. If LCP is your problem, filter to it and ignore the rest for now.
- Expand an item before judging it. Each one opens into a table naming the actual files or elements involved. “Reduce unused JavaScript” means little until you see that most of it is a chat widget or a page builder library.
- Look at who owns each file. Files from your own domain you can usually change. Files from other companies’ domains (analytics, ads, maps, video embeds) you can only remove, delay or replace.
- Treat estimated savings as estimates. They are calculated in the simulated test and do not add up neatly. Fixing three items that each claim a second of savings will not make the page three seconds faster.
Further down, a collapsed section lists the audits the page already passes. It is worth a glance once, then you can leave it.
What you can usually ignore
Not every warning deserves attention, especially on a small site. These are the ones that can usually wait:
- Cache-lifetime warnings for third-party files. If the report says Google Analytics or a social widget has a short cache policy, you cannot change another company’s server settings. Your choices are to keep the script, delay it or remove it.
- Small savings on already small files. A suggestion to save a few kilobytes on a stylesheet is real but rarely the thing holding the page back.
- The exact score. Running the same test twice can give different numbers. Work from the metrics and the biggest items in the list, not from one decimal. Whether 100 is even worth aiming for is a separate question.
- Accessibility, Best Practices and SEO circles, when your question is speed. Read them another day.
What you should not ignore: anything that names your largest image, the main font, a render-blocking stylesheet, or a long main-thread task traced back to one script. Those are usually where the gain is.
How to read a PageSpeed Insights report in ten minutes
A report is only useful if it ends in actions. A simple way to get there:
- Note the field data verdict (or “no data”) and which Core Web Vital, if any, is failing.
- Note the three weighted lab metrics: LCP, TBT and CLS.
- Find which of those is furthest from good. That is your focus.
- Filter the suggestions to that metric and expand the top items.
- Write down the specific files or elements named, and whether they are yours or a third party’s.
- Pick two or three changes, make them, then retest the same URL several times and compare the median.
Do this alongside a consistent testing routine; our guide on testing website speed properly explains how to keep conditions fair so that the “after” result means something. The wider context on why these metrics matter at all is in the complete guide to website speed. Our free speed test tool is handy for a quick first reading, but for the full set of sections described here, use PageSpeed Insights itself.
A worked reading, without numbers
Say the mobile report shows field data failing on LCP, while INP and CLS pass. In the lab, TBT is fine, CLS is fine, LCP is poor. The filmstrip shows text appearing early but the large banner photo arriving near the end. Filtering to LCP, the top items mention the banner image’s file size and the fact that it is lazy-loaded.
That report is telling a clear story: the banner is the LCP element, it is too heavy, and it is being told to load late. The fix list is short (resize and compress it, stop lazy-loading it, maybe preload it) and everything else in the report can wait. Most reports, read this way, are simpler than they first appear.
Frequently asked questions
Why does PageSpeed Insights show no field data for my page?
Field data only appears when enough Chrome users have visited that page, or your whole site, during the previous 28 days for Google to publish it. Many small business pages do not reach that level. It is not a fault on your site, and you can still work from the lab results lower down the report.
Is the mobile or desktop result more important?
For most small business sites, mobile deserves attention first. The mobile test emulates a slower device on a throttled connection, so it shows problems more clearly, and many visitors arrive on phones. Check your analytics to see the real split for your own audience, and keep both results in your notes.
Should I fix every item in the suggestions list?
No. Start with the metric that is furthest from good, filter the list to that metric, and work on the few items that name your own large files or blocking scripts. Many remaining items are minor or concern third-party files you cannot change, and fixing them would take effort for very little difference.
Do the Accessibility and SEO scores affect my speed score?
No. They are separate Lighthouse categories that run in the same report. They check different things, such as image alt text, colour contrast or meta tags, and have no effect on the Performance score. They are worth reviewing on their own merits, but not as part of a speed investigation.
Some findings in a report are quick to act on; others lead into the theme, caching or server, which many owners would rather not touch. Those are the ones our speed optimisation team can take on, starting from the same report and ending with a before-and-after comparison.
Next in this series: Why Your PageSpeed Score Changes Every Time You Test
