Fixing a website with poor test results
The order of fixes by return on effort. From images, through third-party scripts, to the database.
You start with the cheapest thing, not the most interesting one
Fixing a site has this property: the first twenty percent of the work delivers eighty percent of the gain, and the last twenty percent can cost more than everything before it. That's why order matters more than which tools you pick.
Below is that order. It holds up reliably enough that when a client arrives with a site that's "barely breathing", we always start the same way — and usually the first two points alone mean no further work is needed.
The order
-
1
Images
The most common cause and the cheapest fix. The right format (WebP or AVIF instead of a JPEG straight from a camera), a size matching where it's displayed, dimensions given in the markup, lazy loading below the fold. This alone often delivers half the gain and takes a few hours.
-
2
Third-party scripts
Count them. Chat, two analytics tools, an ad pixel, a map, a reviews widget, a consent banner. Each is a separate connection and code to execute. Remove the ones nobody uses — usually half of them. Usually nobody remembers who added them.
-
3
Fonts
Serve them from your own server, not someone else's. Load early. Limit to the characters you actually use — the Latin alphabet plus punctuation is a fraction of a full typeface. Set sensible loading behaviour so text doesn't vanish or jump.
-
4
Cache
Server-side headers, so a returning visitor doesn't download the same thing twice. Half a day of work, a benefit on every following visit. Careful: without filenames that carry a content hash, don't set long cache lifetimes — you'll strand people on an old version.
-
5
The database and its queries
Last, because it's the most expensive. Worth doing once the server itself takes longer than half a second to respond. Usually it's a missing index or a query running in a loop — one fix, not a rewrite of the system.
Three typical cases and what fixed them
-
Shop, product page 6 seconds
Photos uploaded straight from a camera, 3–5 MB each, displayed in a 400-pixel container. Processing and serving the right sizes: 6 s → 1.8 s. One day of work.
-
Company site, score 34
Four analytics scripts from three different implementations over the years, a five-image carousel at the top, and eight typefaces. Removing the unnecessary ones: score 34 → 91. Half a day.
-
Portal, server responds in 2.4 s
A query on custom fields with no index, run once for each of 40 entries on a list. One index and one batched query: 2.4 s → 180 ms.
What not to do
- Don't buy a bigger hosting plan as the first step. If a page loads 6 MB of images, the server has nothing to do with it.
- Don't install an "optimisation" plugin on top of the problem. It usually adds its own code to a page that's already overloaded.
- Don't minify and bundle files before removing the ones you don't need. That's optimising dead weight.
- Don't chase a score of 100. The last points cost many times more than the first, and no user will notice them.
- Don't quietly disable things that are needed — the chat support uses, or the analytics decisions are based on. Move it, delay it, but don't remove it silently.
Questions
- How long does this usually take?
- For a typically neglected site, going from 5–6 seconds to under 2 is two to three days of work. The first day usually delivers most of the gain.
- Does the site need to be rebuilt?
- Almost never. Optimisation is work on what already exists. A rebuild only makes sense once a site is made of dozens of plugins that can't be untangled without risk.
- Will faster speed improve Google rankings?
- It can help, since Core Web Vitals are one ranking factor. But the bigger, more certain gain is elsewhere: in how many people actually stay long enough for the page to load.
Send the address — we'll tell you what gives the most.
Measurement and a priority list are free. We quote the fixes after that.
Write to us