Guide
Website speed optimisation: what to fix, and in which order
Updated:
Speed is not a plugin. Most slowness concentrates in three line items, and starting to fix things before measuring which one is hurting you is the most expensive route.
Calling a site “slow” is easy; saying what is slow is hard. This guide walks through the real sources of slowness in the order you should investigate them: what to measure first, what to fix next, and which work looks productive but changes nothing.
Measure the right thing first
The most common mistake is measuring from your own machine on your own connection. You have already opened the site once; everything is cached. Your visitor arrives for the first time, on a phone, often over a mobile network.
A meaningful measurement meets three conditions: no cache (like a first visit), a mobile device profile and a throttled connection. The same page can look fine on a desktop measurement and poor under those three — and the second is what your visitor experiences.
There is no single number to watch. When meaningful content first appears, when the largest element settles and whether the layout shifts are separate problems; one can be good while another is bad. Looking at a single composite score does not tell you which job to do.
The three main sources of slowness
Across the sites we review, most slowness concentrates in three line items — usually in this order:
What these three share: none of them is “the server is slow”. Upgrading the server is the most expensive and least effective intervention on most sites, because the bottleneck is not response time — it is the payload the browser must download and process.
Which job, in which order?
| Job | Typical impact | Difficulty | Note |
|---|---|---|---|
| Resize and compress images | High | Low | Usually the biggest single win; no content changes needed |
| Remove unused third-party scripts | High | Low | Inventory first: which of these is actually used? |
Add width/height to images | Medium | Low | Directly removes layout shift |
| Reduce the number of font files | Medium | Low | Using system fonts removes the cost entirely |
| Lazy-load off-screen images | Medium | Low | Applied to a visible element it makes things worse |
| Cache headers + version stamps | Medium | Medium | Caching without stamps stops fixes from reaching visitors |
| Upgrade the server | Low | High | Wasted money if response time is already fine |
The order is not arbitrary: low difficulty plus high impact comes first. On most sites the first two rows deliver more than everything below them combined.
Three mistakes we see repeatedly
Lazy-loading a visible element. A blanket “make all images lazy” setting also defers the image at the very top of the page; the largest element settles later and the score drops. Lazy loading is for off-screen elements only.
Long cache lifetimes without version stamps. Set a week-long cache and keep filenames fixed, and a fix you deploy will never reach anyone who visited before. A stamp (?v=…) is the only fix for this.
Chasing a single score. The composite score these tools give is a summary, not a target. Deleting content to raise it produces a fast site that does not work. The correct target is reducing how long the visitor waits.
A concrete example: this site
Measured on our own site: total resource weight on the home page is 85 KB, the document itself is 7.2 KB compressed, there are 4 requests, zero third-party domains and zero web fonts.
These numbers are not a boast but a benchmark: most of the page weight is the logo image, because everything else has been removed. No analytics, no chat widget, no embedded map, fonts come from the system. Speed is not a feature you add; it is the result of what you leave out.
There is a cost to that, and we do not hide it: with no analytics, we cannot measure visitor behaviour. Every decision has a trade-off; what matters is making it knowingly.
Frequently asked
My site is slow — will a bigger server fix it?
Usually not. Upgrading only helps if the server’s response time is genuinely high. On the sites we review the bottleneck is almost always on the browser side: large images, third-party scripts and fonts. If response time is already reasonable, a more powerful server produces no measurable difference — only a higher monthly bill. Measure first.
What score should we aim for?
A score is a summary, not a target. Very different experiences can share the same score. The better questions are: how many seconds until the visitor sees meaningful content, when does the largest element settle, and does the layout jump while loading? Get those three right and the score follows; chase the score and you end up deleting content to produce a fast site that does not work.
Which image format should we use?
Modern formats (WebP/AVIF) give a clear gain for photographs; PNG or SVG is right for drawings, logos and flat-colour graphics. But two things matter more than format: saving the image at the size it will actually be displayed, and giving it width and height attributes. A photo saved at 3000 pixels wide and displayed at 400 is waste in any format.
How much do analytics and chat widgets slow a site down?
More than you would expect. Every third-party script connects to a separate domain: DNS resolution, TLS handshake, then download and execution. Add three or four tools and the page spends more time waiting on other people’s servers than on your own files. You do not have to remove them all — but each one should be justified by evidence that it is used and produces a result. An unused tracking script is pure cost.
Is it cheaper to speed up our site or rebuild it?
Usually to speed it up. Image optimisation, removing unnecessary scripts and fixing cache settings can all be applied without rewriting, and they typically deliver most of the available gain. Rebuilding makes sense only when the platform is genuinely unsustainable — an unpatchable system, or accumulated plugin debt. Measurement tells you which case you are in, and we will say plainly when rebuilding really is the cheaper path.
Let us measure your site
We will measure your current site uncached, on a mobile profile, and rank the three jobs that would gain the most. The measurement is free.