How to read PageSpeed Insights without being a developer
PageSpeed Insights throws a wall of numbers at you, and most of them do not matter for ranking. Here is the short version: read the field data at the top first, because that is the real-user score Google uses, and treat the big 0 to 100 performance number as a diagnostic, not a verdict. Google's own documentation is clear that the tool reports both “lab data and field data about a page.” Knowing which is which is the whole skill.
Start here: paste the URL, pick mobile
Go to pagespeed.web.dev, paste your page URL, and run it. When the report loads, choose the Mobile tab. Most of your visitors, and the version Google leans on, is mobile. Desktop usually looks better and matters less.
Section 1: field data (the real score, read this first)
At the top you may see a panel labelled "Discover what your real users are experiencing." This is CrUX field data: the experience of actual Chrome visitors over the last 28 days. It shows your four vitals with a colour:
- LCP (Largest Contentful Paint): how fast the biggest thing loads. Good is under 2.5 seconds.
- INP (Interaction to Next Paint): how fast the page reacts to a tap. Good is under 200 milliseconds.
- CLS (Cumulative Layout Shift): how much the page jumps. Good is under 0.1.
- TTFB (Time to First Byte): how fast the server answers. A supporting number, not a vital.
Green passes, orange needs work, red is a real problem. If this whole panel is missing, your site does not have enough traffic to be in Google's field dataset. That is normal for small sites, and it is not a penalty. It just means you rely on the lab section below.
Section 2: the 0 to 100 performance score (a diagnostic, not a grade)
The big coloured number is a lab score from one simulated load. It is useful for spotting problems and for checking that a change helped, but it is not what Google ranks on, and it swings between runs. Do not obsess over moving it from 88 to 92. Use it to see whether you have a real issue, then go fix the cause.
Section 3: diagnostics and opportunities (the to-do list)
Below the score is a list of suggestions: "properly size images," "eliminate render-blocking resources," "reduce unused JavaScript," and so on. This is your to-do list, roughly ordered by impact. You do not have to clear all of it. Focus on the items tied to your worst vital:
- Bad LCP? Look at image and server items. Our fix: the image behind your LCP and a slow LCP overall.
- Bad INP? Look at JavaScript and main-thread items. Our fix: a slow INP.
- Bad CLS? Look at "avoid large layout shifts" and image dimensions. Our fix: layout shift.
What you can safely ignore
Two honest points. First, a perfect 100 is not the goal, and chasing the last few lab points is usually wasted effort that would earn more spent on your content. Get your field vitals into the green and stop. Second, some diagnostics are about third-party scripts you may not be able to remove; note them, but do not tear your site apart for a marginal gain. Speed is one ranking signal among many, and a fast page with nothing worth quoting still loses to a slower page that answers the question.
Then read the causes, not just the symptoms
PageSpeed Insights tells you a number is bad. It is less good at telling you, in plain language, exactly which line of your HTML caused it. That is what we do: paste your link into the full AuditLamp audit or start at the Core Web Vitals hub, and we read your source and name the specific patterns behind the scores, the lazy-loaded hero, the image with no dimensions, the render-blocking tag, so you know what to change. The fix library then walks each one.