How to improve your PageSpeed Insights score
A slow site is usually attacked by working through Google's recommendations from top to bottom. The approach looks sensible and often produces weeks of work with nothing to show for it. The reason is that the audit mixes symptoms with minor details, and each requirement carries a very different weight.
Below we go through how to measure performance properly and why intuition misleads even experienced web developers.
Why a single PageSpeed run misleads you
The first rule of optimisation: a PageSpeed score is not a fixed measurement, it is an observation that moves. Run the check on the same URL three times in a row and you will get three completely different numbers.
From our practice: Total Blocking Time on one site came out at 2010 ms on the first run, 1580 ms on the second and 360 ms on the third. The page code had not changed at all.
The right way: run at least three tests in a row with a pause of one to two minutes. A single run often reflects the current load on Google's servers rather than the real speed of your site. Take the middle value. Keep in mind that the spread is always wider on the desktop version than on mobile.
The timing trap: compare runs inside one window
The second critical mistake is comparing results taken far apart in time. You cannot put "before" and "after" side by side when half an hour or more has passed between the runs. The Google virtual machine that tests your site keeps changing its own computing power.
From our practice: with not a single change in the code, First Contentful Paint was 1.4 seconds in the evening and 1.8 seconds forty minutes later. The overall score dropped from 92 to 89.
Had a developer shipped an update in that gap, they would have wrongly judged their own code and rolled back a useful change.
The right way: always run the old and the new version of the code almost simultaneously, inside one time window. That is the only way to prove an optimisation worked.
Which items in the Google PageSpeed report do not affect the score
The Opportunities and Diagnostics sections hold plenty of items marked "These results do not affect the score". That is not a formality. The overall performance score in PageSpeed is built strictly on five key metrics:
- First Contentful Paint (FCP): when the first content is painted.
- Speed Index: how quickly the page fills in visually.
- Largest Contentful Paint (LCP): when the largest element is painted.
- Total Blocking Time (TBT): how long the main thread is blocked.
- Cumulative Layout Shift (CLS): how much the layout moves.
Everything else in the report, unused JavaScript, legacy code, DOM tree depth or forced reflow, is an indirect hint. Fixing those adds nothing to the score directly. Before spending hours clearing a warning, check whether that parameter enters the scoring formula at all.
How to find the real cause of slow loading rather than the obvious one
The most useful habit here is simple: never fix what measurement has not confirmed. The obvious hypothesis and the real technical problem rarely coincide, and a preliminary test is always cheaper than a large rewrite.
From our practice: on one site the desktop PageSpeed score was stuck at 81. The prime suspect was React and the heavy scripts. The developers spent time rewriting two large blocks in plain JavaScript. The result: a local test showed a 200 ms gain, and the PageSpeed Insights score did not move by a single point.
So the strategy changed. Next to the main page we created several test copies, closed to search robots, each with one element deliberately switched off:
- In the first copy all JavaScript was removed entirely.
- In the second the CSS was switched off.
- In the third only one decorative block was taken out.
The result was unexpected. The test page with no JavaScript scored exactly the same as the original. The copy with a single background element removed jumped straight to 100 instead of 81. The culprit was not complex code but a design element stretched over the full height of the page and covered by a mask made of four heavy gradients.
The fix: the work took one hour. The heavy gradient mask was generated once by a script and saved as an optimised image. Nothing changed visually, and the score rose to 95 immediately. Without the test-copy method this cause would never have been found, because Google PageSpeed did not highlight it in the report at all.
What the search engine actually sees from the PageSpeed Insights report
The main thing to hold on to: the numbers in PageSpeed are lab measurements on a reference Google virtual machine. When ranking sites, the algorithms use field data from the Chrome User Experience Report, collected from real visitors. And there the metrics behave differently.
The official Core Web Vitals ranking factor covers three measurements:
- LCP (Largest Contentful Paint): how fast the largest element is painted.
- CLS (Cumulative Layout Shift): layout stability, meaning nothing jumps.
- INP (Interaction to Next Paint): the delay after a click or an interaction, which replaced the older FID.
Notably, TBT, the metric that most often drags the lab score down, is not part of that search-facing set at all. For SEO, a site scoring 80 in the lab with green field metrics from real users will do better than one scoring 100 whose real sessions struggle.
A step-by-step routine for optimising a site properly
To avoid wasting time on pointless edits, follow a clear plan:
- Build a baseline: take three measurements in a row and work out the average.
- Cut the noise: check against Google's formula whether the flagged items feed into the score at all.
- Localise the problem: create hidden test copies of the page with styles, scripts and graphics switched off one at a time.
- Make one targeted change: fix only the cause that produced the largest gain on the test copy.
This route takes longer than working down the standard list of recommendations, but it reliably removes real technical problems instead of burning resources.