Blog · 7 November 2026 · 9 min read
How to read a PageSpeed Insights report (without a developer)
You pasted your address into pagespeed.web.dev, saw a red 38 and forty lines of technical messages. This article tells you what to read in that report, in what order, and what to skip – so that after ten minutes you know whether you have a problem, how big it is and whom to give it to.
It is two reports in one
The most important thing PageSpeed does not spell out: on one page you get two different measurements, and they can contradict each other.
| Section | Where the data comes from | What it is for | When it is missing |
|---|---|---|---|
| “Discover what your real users are experiencing” (at the top) | From the Chrome browsers of your own visitors over the last 28 days (Chrome UX Report). The value shown is the 75th percentile, meaning three quarters of visits were faster | This is the truth about your site and these are the numbers Google looks at. The “Passed / Failed” Core Web Vitals assessment refers to this section | When the site has too little traffic – then you see a “no data” message, or data for the whole domain instead of this one page |
| “Diagnose performance issues” (below, with the 0–100 score) | One run of the Lighthouse tool on a Google server: a simulated mid-range phone on a slower mobile connection | Diagnosis: it says why the page is slow and what to fix. It gives a list of files and recommendations for your developer | Always present – but it is a lab measurement, not your customers' experience |
That is why customers can “pass” Core Web Vitals while the lab score is orange – or the other way round. Google itself says field data is a history from real devices and networks, while the lab is a controlled one-off test. For the business decision, read the top; for the to-do list, read the bottom.
Look at “Mobile”, not “Desktop”
The tabs at the top switch the device. The desktop score is almost always better and almost always irrelevant: most traffic to small-business sites comes from phones, Google indexes the mobile version, and the lab test simulates a weak phone on purpose. If you remember one number from the report, make it the mobile score. Why a phone differs so much from a laptop is explained in our post on slow mobile sites.
What the 0–100 score means
The big number in the circle is a weighted average of five lab measurements. According to the Lighthouse documentation (version 10 and later) the weights are:
| Metric | Weight | What the user feels |
|---|---|---|
| Total Blocking Time (TBT) | 30% | The page “hangs”: you can see it but cannot tap anything because the phone is busy running scripts |
| Largest Contentful Paint (LCP) | 25% | How long they wait for the biggest element – usually the header photo or the main heading |
| Cumulative Layout Shift (CLS) | 25% | Content jumps while loading: they meant to tap “Call”, they hit a banner |
| First Contentful Paint (FCP) | 10% | How long they stare at a blank screen before anything appears |
| Speed Index | 10% | How quickly the visible part of the screen fills in |
There are three ranges: 0–49 red (poor), 50–89 orange (needs improvement), 90–100 green (good). Two things that will save your nerves: first, the same address run twice can give a score a few points apart – that is normal, Google's server and yours both have better and worse moments; do not react to 72 → 68. Second, a score of 100 is reserved for pages with almost no scripts; for a business site with a form, a map and analytics the realistic goal is the green range, not a perfect score.
The three numbers that decide Google's verdict
In the real-user section, three metrics are marked as Core Web Vitals. The “good” thresholds are the same for every site in the world:
- LCP within 2.5 s – the largest element visible within two and a half seconds.
- INP under 200 ms – the page reacts to a tap within a fifth of a second (this metric exists only in field data; the lab shows TBT instead).
- CLS under 0.1 – content barely moves.
A “Passed” verdict requires all three to be green at the 75th percentile. One orange and the whole thing fails. More on where bad values of each number come from in Core Web Vitals in plain English.
The recommendations: what the common messages mean
Below the score is a list of messages (called “Diagnostics” or “Insights” depending on the version), each with an expandable list of files. The exact wording changes between versions, but on small-business sites the same items keep coming back. In plain language, and who usually fixes them:
| Message | What it means | Who fixes it and how much work |
|---|---|---|
| Serve images in next-gen formats / Properly size images | Photos are too big – uploaded straight from the camera or in an old format. The most common cause of bad LCP | Often you (a compression plugin, re-uploading) or an hour of a webmaster's time |
| Reduce JavaScript execution time / Minimize main-thread work | Too many scripts: plugins, slider, chat, several analytics systems. The main cause of bad TBT and INP | Webmaster: review plugins and widgets, remove unused ones, delay-load the rest. Half a day to a day |
| Eliminate render-blocking resources | Style and script files the browser must fully download before showing anything. Affects FCP and LCP | Webmaster; a well-configured optimisation plugin often handles it. A few hours |
| Reduce initial server response time | The server “thinks” for a long time before sending the first byte – weak hosting, no caching, a heavy theme. Everything else waits for this | Hosting (upgrade or move) or webmaster (server-side cache). From an hour to a migration |
| Serve static assets with an efficient cache policy | The customer's browser downloads the same files on every visit instead of remembering them. Painless on the first visit, painful on every next one | Webmaster or hosting, usually a few lines of configuration. An hour |
| Avoid large layout shifts | Elements without reserved space (images without dimensions, cookie banner, ads, fonts) push content around. This is CLS | Webmaster; usually small template fixes. An hour or two |
| Reduce the impact of third-party code | Chat, map, ad pixels, embedded video – code you do not control but your customer has to download | A business decision (what is really needed) plus webmaster (load after interaction). An hour |
| LCP image was not loaded with priority / Preload LCP image | The biggest photo loads at the end of the queue although it should go first | Webmaster, one change in the page code. Half an hour |
What you can skip
- “Estimated savings” do not add up. If five recommendations show 1.2 s + 0.8 s + 0.6 s…, it does not mean the page will be 3 s faster after all of them. Recommendations overlap; treat the numbers as an order of priority, not a promise.
- The other three circles (accessibility, best practices, SEO) are useful but shallow automated checks of a single page. A green SEO score in PageSpeed does not mean the site ranks well – it means it has a title, a description and can be indexed.
- Individual files in the expandable lists, unless you are the webmaster. Your job is to know which recommendations are at the top; what to do with
jquery.min.jsis the developer's job. - The home page as the only test. Also check the offer, pricing and contact pages – that is where customers decide, and it is often worse there (galleries, maps, forms).
How to turn the report into a to-do list
- Record the starting point. A screenshot of the top section (real users) and the mobile score, with the date. Without it you cannot tell whether anyone improved anything.
- Note which of the three Core Web Vitals are outside green. That defines the problem: bad LCP is usually images and server, bad INP is scripts, bad CLS is the template.
- Copy the top five recommendations in the order the report shows them. Next to each, write who does it, from the table above.
- Start with the server and images, finish with scripts. Server, because everything else waits for it; images, because that is the cheapest and surest gain; scripts last, because they require deciding what to give up.
- Accept the work with a measurement, not a reassurance. Lab measurement right after the fixes, real-user data after 28 days. If the developer says “done” and the mobile score has not moved, it is not done.
The same measurement, plus what PageSpeed does not check
The free Webskan quick scan runs the mobile Lighthouse measurement for your page and, alongside it, checks the https redirect, certificate, security headers and SEO basics. No e-mail, no sign-up, results in about 30 seconds.
Want a ready-made task list instead of copying one out? The in-depth Webskan audit ($69) measures mobile and desktop performance across many pages at once, translates recommendations into specific files and priorities, and also checks technical SEO, security, accessibility and broken links. A re-check after your fixes and 30 days of Webskan Monitor are included.
Sources
- Google, About PageSpeed Insights – field vs lab data, 28 days, 75th percentile, Core Web Vitals assessment
- Chrome for Developers, Lighthouse performance scoring – metric weights and score ranges
- Google Search Central, Understanding Core Web Vitals and Google search results – LCP/INP/CLS thresholds