Slow website: the five causes found in every audit

A slow site is rarely fixed by optimising everything. In almost every case one thing is the brake, and the four other possible causes have nothing to do with it. The useful work is therefore identifying which — and that takes ten minutes, with the browser you already have.

The symptom is almost always enough. Each of the five causes below has a distinct signature: when the slowness appears, which pages are affected, and what happens on a second visit.

Measure before believing

Two tools are enough, and both are free.

Your browser's Network tab (press F12, choose “Network”, then reload). You get the list of everything the page downloads, the size of each item and how long it took. Sort by size: the culprit is often in the first three rows.

A public test — Google's PageSpeed Insights, or WebPageTest — measuring from outside, on a deliberately average connection. This matters: your site feels fast to you because your browser has everything cached and you are probably on fibre.

One caution: do not confuse the score with the experience. A score of 62 out of 100 is not actionable. The time before the main text appears is — that is what the visitor lives through.

Cause 1: unprepared images

Signature: the page appears in pieces, blocks jump around while loading, and the Network tab shows two or three files heavier than everything else combined.

This is by far the most frequent cause, and the easiest to fix. A photograph straight from a camera or a stock library routinely weighs several megabytes to be displayed in a frame a few hundred pixels wide. The browser downloads the whole file, then shrinks it.

Think in bytes, not in scores: a page downloading eight megabytes of images takes, on an ordinary mobile connection, a time nothing else will compensate for. Three fixes, in this order:

• Resize to the dimensions actually displayed, before uploading.
• Convert to a modern format — WebP or AVIF — which cuts the weight with no visible loss.
• Defer the loading of images further down the page, so the top appears immediately.

Cause 2: saturated hosting

Signature: slowness varies by hour and never by page. The site is fine in the morning, painful late afternoon. Every page is equally slow, including the simplest.

That is the mark of shared hosting where hundreds of sites share one machine. You are not paying for capacity, you are paying for a share of what is left — and that share shrinks when the others are busy.

The decisive test: in the Network tab, look at the time of the first server response, before any download. If it regularly exceeds half a second on a page with no database behind it, the problem is neither your images nor your code.

Cause 3: third-party scripts

Signature: the page appears quickly, then freezes — you cannot click or scroll for a moment. The content is there, it does not respond.

Every tool added to the site — analytics, consent banner, live chat, share buttons, advertising, interactive map — loads code from a server that is not yours. You inherit its speed, its availability and its outages.

In the Network tab, filter by domain: anything not coming from your address is third-party. The question for each is not “is this useful?” but “who still looks at this data?”. It is common to find two analytics tools installed two years apart, whose reports nobody opens any more.

Cause 4: no caching

Signature: the second visit is as slow as the first. You reload a page you have already seen, and everything downloads again.

A properly configured site tells the browser what it may keep and for how long. Without that instruction the visitor re-downloads the logo, the fonts and the stylesheets on every page — that is, most of the weight, for nothing.

The check: in the Network tab, reload twice. If the size column does not show entries like “cache” or “disk” on the second visit, the instruction is missing. This is a configuration fix, not a development one, and it takes effect immediately.

Cause 5: an unindexed database

Signature: only certain pages drag — search, a filtered catalogue, a long list — while the home page responds normally.

This is the typical case of a catalogue that has grown. A query that once walked through two hundred products effortlessly now walks through forty thousand on every view, because the database never received the index that would let it go straight to the point. Nothing changed in the code; the volume changed.

This diagnosis needs technical access, but it can be recognised without: if the slowness follows a specific function rather than the whole site, look here before touching the images.

Where to start

Rank by effort against gain, not by the order of appearance in this article:

Fix	Effort	Who can do it
Resize and convert images	Low	Whoever publishes the content
Remove unused third-party scripts	Low	Whoever manages the site
Enable browser caching	Low	The host or a developer
Change hosting	Medium	A vendor, with migration
Index the database	Variable	A developer, after measuring

You will notice no quantified gain is announced here. That is deliberate: it depends entirely on the starting point. Cutting image weight by four is barely visible on an already light site, and transforms one carrying ten megabytes.

Fix one cause, measure again, then decide whether to continue. Three fixes made together do not tell you which one helped — and one of them may have made things worse.

What speed actually changes

Two effects, both indirect. A slow site loses visitors before the content appears, and those leave no trace in your statistics — they never arrived. And speed is one of the signals search engines use, among many others: it will not lift a page with nothing to say, but it can separate two equivalent ones.

Our Web & Mobile Development and DevOps & Cloud pages cover the code and the infrastructure respectively — the two halves of the problem.