A few years ago, the conversation was about seconds. Now it is about milliseconds, and about whether a page responds to a tap before the person taps again.
That shift matters because the old advice, mostly about compressing images and enabling caching, addresses only half of it. Response time is a different problem with different causes, and a site can load quickly while still feeling broken.
To improve website load speed properly, you need a diagnostic method rather than a list of tips, and PageSpeed Insights is the free tool that provides one, provided you read it correctly.
How to Improve Website Load Speed with PageSpeed Insights
Read the field data first
This is the mistake almost everyone makes. The big number at the top is a lab score from a simulated load under generous conditions. It is not what your visitors experience.
Scroll to the field data section, which reports real visits from real devices over the preceding period. If it is present, that is your reality. The lab score is a diagnostic aid.
A site scoring well in the lab and badly in the field is telling you that your test conditions are kinder than your customers’ conditions, which is worth knowing before you celebrate anything.
If no field data appears, your site does not receive enough traffic for it. Use the lab data, and test on a real phone to sanity-check it.
Work out which of three problems you have
The diagnostics group naturally around three failures.
- Content appearing slowly. Look at Largest Contentful Paint. Usually the hero image is oversized, or something in the head is blocking rendering.
- Layout moving as it loads. Look at Cumulative Layout Shift. Usually images without explicit dimensions, or fonts swapping late.
- The page ignoring taps. Look at Interaction to Next Paint. Almost always JavaScript occupying the main thread, and frequently a third-party script rather than your own code.
The web.dev guidance covers the current thresholds for each.
Then read the opportunities sceptically
PageSpeed Insights lists suggested improvements with estimated savings. These are useful, and they are not a work plan.
The estimates assume the change is made in isolation and are frequently optimistic. Several items commonly describe the same underlying problem from different angles, so fixing one resolves three.
Sort by estimated savings, ignore anything worth a few milliseconds, and start with whatever addresses the metric actually failing in field data.
The fixes that usually matter
- Serve images properly. Display dimensions, modern formats, lazy-load below the fold but never the hero. Largest single win on most sites.
- Set explicit width and height on images. Fixes most layout shift for almost no effort.
- Audit third-party scripts. List every external domain and find an owner. The unclaimed ones cost nothing to remove and frequently cause the responsiveness problem.
- Reduce JavaScript. Hardest and slowest, so leave it until the cheap wins are done.
- Check server response time. If it is high after everything else, hosting is the constraint rather than the code.
What the tool cannot tell you
PageSpeed Insights measures delivery. It has no view of whether the page is worth delivering.
A page can pass every threshold while burying the phone number, asking for information nobody has, or answering a question the visitor did not ask. The tool will report that favourably, because none of it is a performance problem.
It also cannot tell you which pages matter. A perfect score on a page nobody visits is effort spent where it returns nothing, which is why starting from analytics rather than from the homepage is worth the extra minute.
And it cannot judge trade-offs. Removing a feature would improve the score; whether that feature was earning its place is a judgement about your business that no diagnostic makes for you.
Measure again properly
Re-test under the same conditions you used before, and give field data time to update, since it reflects a trailing period rather than the current moment.
Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Then set a page weight budget enforced in your build process, because sites regain weight through ordinary content work and manual vigilance stops within months.
Our website sustainability audits start from field data rather than lab scores, since lab scores flatter most sites.