← Field notes

Websites

What a website speed score can tell you

How to read a PageSpeed Insights report before you ask for a repair

A desktop monitor with a measuring dial connects to three phones showing the same page layout.

Open PageSpeed Insights and enter the address of a service page a customer would actually use. Save the report link, and write down the date and the selected device mode. Then, before deciding what to fix, work out which part of the report you are reading. A score without its scope is hard to act on and easy to misread.

Separate the two kinds of evidence

PageSpeed Insights shows two different things side by side. One is a lab test: a controlled Lighthouse run of the page, on a fixed device profile, at the moment you asked for it. The other is field data from real visitors, drawn from the Chrome User Experience Report when there is enough of it (About PageSpeed Insights). They answer different questions. The lab run tells you what happened in a test. The field data tells you what visitors have experienced over the previous 28 days.

The field data also has a scope you need to check. When a single URL does not have enough samples, PageSpeed Insights falls back to origin-level data, covering every page on the site. If the origin itself lacks enough data, no real-user data appears at all. Missing field data is a gap in the evidence. It does not mean the page is fast, and it does not mean it is slow.

Keep the labels beside any number you pass on. A mobile lab score, a desktop lab score and an origin-wide history are not the same measurement, and comparing them directly can send a repair conversation in the wrong direction. CrUX presents data aggregated over a rolling 28-day window (CrUX API), so a change you shipped last week is still mixed in with experiences from before it. For a recent change, write down the date it went live, use a fresh lab run and your own check in the meantime, and return to the field data once the window has moved past it.

Turn the score into a question

The headline performance score is a weighted blend of several metric scores. The diagnostic recommendations below it are separate: they do not add or remove points by themselves, although fixing the problems behind them can improve the measured result. Google also documents that scores move between runs as testing conditions change (Lighthouse performance scoring).

Open a flagged finding and identify the element or resource it points to. If it names an image, ask whoever maintains the site which visible image that is and what change they would make. Keep the finding next to the report link so the two travel together. Deleting a service photograph because a report mentioned images is a common overreaction.

Before you treat a small score movement as the result of a repair, repeat the same URL in the same device mode. Testing conditions shift, so one number rising or falling by a few points is weak evidence on its own. If repeated runs disagree widely, ask what changed in the conditions before choosing a fix based on a single run.

Try the page yourself

On your phone, open that service page in a fresh tab. Watch the main information appear, open the menu, and follow the contact link. Note the exact point where something delays or shifts: which control you used, what you did, and what you saw. Record the browser and the connection you were on so the maintainer has a starting point for investigation.

A report also leaves ordinary content questions open. Check that the service is described clearly and that the contact link reaches the intended destination, because no speed score will catch those.

Then send one focused request: the page address, the report finding, your observation, and the customer action affected. Ask for an explanation of the proposed change and a way to check it afterward.

Agree on what will count as checked

After a repair, repeat the page action and run the same lab test settings. Check the specific finding and the overall score, then record what was published and what you could confirm. Leave anything unresolved marked as still open. If a maintainer proposes a larger package of speed work, ask which reported problems it addresses and how each one will be verified.

The practical takeaway

Keep the original report with the follow-up. The next speed conversation can then start from evidence you already have, with the score as the entry point to a question rather than a verdict.

Read more field notes →

Privacy We use information to handle inquiries, proposals, and payments. Read our privacy policy for details and your choices.