Website speed: how to read PageSpeed without chasing 100
Published
Updated
PageSpeed Insights can reduce a useful performance discussion to one coloured number. A score of 62 appears to be a problem and 94 appears to be a success. Yet that score describes one laboratory run under defined conditions. It does not tell you whether actual customers wait for the main offer, whether a filter responds late, or why the layout moves just before a tap.
The better question is: which part of the experience is slow, for whom, and because of what? That answer can justify a specific piece of work. It might be a better hero image, a shorter JavaScript task, or a faster server response. Chasing 100 can instead spend a budget on minor audits that do not remove meaningful user friction.
Identify the evidence before interpreting the score
PageSpeed Insights may present two different kinds of evidence. Field data comes from the Chrome User Experience Report and aggregates experiences from real Chrome users over a recent period. Lab data comes from Lighthouse, a controlled diagnostic run that is useful for reproducing faults and comparing changes.
The two datasets are not expected to match perfectly. Real traffic includes varied phones, networks, locations, cache states and activity after load. A lab run uses one device and network profile and follows a limited path. A sound diagnosis gives each source a distinct role:
- field data shows whether a problem affects users and how broadly;
- lab data helps reproduce the issue, investigate a cause and test a proposed change;
- first-party real-user monitoring, where available, adds page, template, device and interaction context.
Missing URL-level field data is not proof that a page is fast. The sample may be too small, so PageSpeed can fall back to origin data or show only the lab test. Read the scope label before making a decision.
The free website audit can provide a first report. Treat the result as a starting point rather than a quality certificate.
LCP, INP and CLS represent different failures
The current Core Web Vitals are LCP, INP and CLS. Google evaluates their recommended thresholds at the 75th percentile, separated for mobile and desktop. One quick visit therefore cannot cancel out a poor experience for a meaningful share of users.
Largest Contentful Paint (LCP) marks when the largest meaningful element in the initial viewport renders. The recommended good threshold is 2.5 seconds or less. A poor LCP may begin with server latency, a render-blocking resource, a late-discovered hero image or a costly component.
Interaction to Next Paint (INP) describes responsiveness across a visit. The good threshold is 200 milliseconds or less. When a menu, filter or form reacts late, the browser's main thread may be occupied by a long JavaScript task, expensive rendering or too much work in one event handler.
Cumulative Layout Shift (CLS) describes unexpected movement. A good score is 0.1 or less. Common causes include images without dimensions, banners and embeds without reserved space, late-injected content and font swaps.
Do not merge these metrics into a vague idea of speed. Each represents a different kind of harm and leads to a different investigation.
A symptom-to-test decision matrix
This matrix is a triage tool. It does not assert a cause; it narrows the next check.
| Symptom | Inspect first | Frequent causes | Next test |
|---|---|---|---|
| LCP is poor in field and lab data | the LCP element and TTFB | server latency, hero media, blocking CSS or fonts | network waterfall and LCP resource timing |
| LCP is poor only in the field | device, country and page scope | slower hardware, networks, caches or different templates | segment by template and device |
| INP is poor in the field | the responsible interaction | long tasks, third-party code, a large DOM or rendering work | record the click or typing flow in DevTools |
| CLS is poor only in the field | shifts after scrolling and interaction | lazy content, banners, personalisation or SPA transitions | record a longer user journey |
| Lighthouse is poor but field data is good | repeatability of the run | artificial throttling or an uncommon state | repeat tests and use a lower-powered device |
| The score is good but customers complain | the complete customer task | a slow API, search, checkout step or post-load widget | measure the journey, not only the landing page |
The governing principle is to match the proposed fix to the observed symptom. If the LCP element is text, converting every photograph may do little. If chat software causes a long main-thread task, rearranging CSS will not remove it.
Prioritise by customer journey, not audit count
Not every page or millisecond has equal business value. Begin with templates that lead to an enquiry, booking or sale: the service page, category, product, basket and form. Combine three criteria:
- Reach: how many relevant users encounter the problem?
- Severity: does it delay the offer, an interaction or a safe tap?
- Cost and risk: is the fix local, or does it require architectural work?
A small improvement on an obscure page can be worthwhile housekeeping, but it should not displace a fault in the principal commercial template. Conversely, a platform rewrite is not automatically justified when a few expensive scripts can be delayed, removed or scoped more carefully.
Use the Lighthouse score as a repeatable regression check. Run comparable conditions and look at the median of several tests. A two-point difference is not a reliable outcome when the test itself naturally varies.
Optimise images when images are causal
Images often influence LCP and CLS, but “make the images smaller” is not a complete implementation brief. Check whether the browser downloads a file close to its rendered size, whether the hero is mistakenly lazy-loaded, and whether HTML dimensions reserve the correct space before download.
The responsive image generator can help prepare a set of variants. Correct srcset and sizes values let the browser choose a reasonable file, but do not replace thoughtful cropping, compression, format and loading priority. An image well below the fold can usually be lazy-loaded; an LCP candidate should not be needlessly deferred.
HTML width and height do not force a fixed visual size when responsive CSS is used. They supply an aspect ratio early enough for the browser to reserve space, helping prevent CLS.
Media is only one branch of the diagnosis. A fast image cannot compensate for a slow initial server response, a blocking consent manager, or a client-side application that must execute a large bundle before showing useful content.
Turn the audit into a controlled change
A practical performance cycle looks like this:
- choose two or three commercially important templates and record a baseline;
- note the date and scope of field data, then capture repeatable lab runs;
- identify the metric and the element or interaction responsible for it;
- state a falsifiable hypothesis, such as “the hero is discovered too late”;
- change one group of causes and compare laboratory results;
- release safely and monitor real-user data for a meaningful period;
- check business outcomes, errors and the behaviour of the key form as well.
Keep release notes so that a change in performance can be connected to an implementation date. Segment results by template where possible: an origin-wide average can conceal a weak checkout or overstate a problem confined to one campaign page.
Do not promise that green Core Web Vitals automatically improve rankings or conversion. Performance is part of the experience and one of many search considerations. Its clearest value is removing actual waiting, instability or delayed feedback from a user's task.
If several causes overlap and the report needs to become an ordered implementation backlog, review my design and development services or describe the page and its commercial task. A narrow, evidenced diagnosis is more useful than a commitment to “speed up everything”.
Sources
Is your store losing customers somewhere between intent and purchase?
I can turn the symptoms into a practical technical plan.
Tell me what is not working ↗