Site Speed Optimisation: A Practical Order of Work
Site speed work has a strong Pareto shape: a handful of fixes account for most of the improvement on most sites, and they are almost always images, server response and third-party scripts.
This guide covers the order to work in, how to measure whether a change helped, and the optimisations that are usually not worth the effort.
Measure before you change anything#
Optimising without measurement means fixing whatever is easiest rather than whatever is slow. Two measurements, then work.
- Get field data for real visitors — the Core Web Vitals report in Search Console, or your own monitoring.
- Run a lab test on the three most important templates, throttled to a mid-range phone on 4G.
- Record the numbers before you start. Without a baseline you cannot tell whether a change helped.
- Identify the largest single asset and the largest single blocking request on each template.
- Note the Time to First Byte separately: if it is above 800ms, no front-end work will save you.
The order that pays#
Roughly by improvement per hour of effort, for a typical content or brochure site.
| Work | Typical gain | Effort |
|---|---|---|
| Optimise and correctly size images | Large | Low |
| Remove unused third-party scripts | Large | Low — mostly a political task |
| Enable caching and a CDN | Large | Low |
| Fix render-blocking CSS and JS | Medium to large | Medium |
| Reduce the JavaScript bundle | Medium to large | Medium to high |
| Fix slow database queries | Large where it applies | Medium |
| Optimise font loading | Medium | Low |
| Minify and compress text assets | Small | Low — usually already on |
| Micro-optimise CSS selectors | Negligible | Not worth doing |
Images: usually the biggest win#
On most sites images are the majority of page weight, and most are served at several times the size they are displayed. This is the cheapest large improvement available.
- Serve WebP or AVIF; both are widely supported and typically 25–50% smaller than JPEG at equivalent quality.
- Generate multiple sizes and use srcset with sizes so phones download phone-sized files.
- Never serve a 2000px image into a 400px slot — this single mistake is extremely common.
- Lazy-load everything below the fold, and nothing above it.
- Automate it in the build or the CMS. Hand-optimised images stop being optimised the first time someone else uploads one.
- Strip metadata; camera EXIF can be tens of kilobytes per file.
Automation is the point. A one-off optimisation pass degrades within months as new content is added, and nobody notices until page weight has doubled.
Third-party scripts and the server#
These are the two areas where the problem is usually organisational rather than technical: nobody owns the tag manager, and nobody owns the hosting decision.
| Problem | What to do |
|---|---|
| Tag manager with unknown tags | Audit every tag; delete anything nobody can justify |
| Chat widget loading on every page | Load on interaction, or only where support is needed |
| Multiple analytics tools | Keep one; each is a full script and a connection |
| A/B testing script blocking render | Move server-side, or accept a flash and load async |
| Slow TTFB on shared hosting | Add full-page caching; upgrade the plan if it persists |
| Uncached database queries | Cache the expensive ones; add indexes for the common ones |
| No CDN | Add one — it is the cheapest global latency fix available |
Third-party scripts are the most reliable source of unexplained slowdowns, because they change without telling you and are outside your deployment process.
Frequently asked questions
What is a good page load time?
The useful targets are the Core Web Vitals thresholds rather than a single load number: LCP under 2.5 seconds, and Time to First Byte under 800ms. Total load time is a poor measure because a page can be usable long before every asset finishes, and unusable well before that on a slow device.
Will a faster site increase conversions?
Generally yes, and the effect is largest where pages are currently slow and visitors are on mobile networks. The gain from three seconds to two is far larger than from one and a half to one. If your site is already fast, spend the effort on content and clarity instead — the return is better.
Do caching plugins solve everything?
They solve one real thing well — repeated server work for the same page — and they can create new problems, particularly with logged-in users, carts and forms. They also do nothing about oversized images or third-party scripts, which are usually the larger issues. Useful, not sufficient.
Is server-side rendering worth it for speed?
If your pages currently render only in the browser, yes: server-rendering or static generation removes an entire round trip before content appears, and it helps indexing at the same time. If your pages are already server-rendered HTML, the question does not apply — you already have the benefit.
site speed optimizationpage speedwebsite performanceimage optimizationcachingcdn
