Your site is slow: the 5 causes, in the order you should look for them

"My site is slow" describes a nuisance, not a fault. Underneath that sentence sit five different problems, with different symptoms, different fixes and different costs. And most of the advice you will find starts by assuming you already know which one you have.

That is what wastes the most time. A caching plugin gets installed for a database problem, images get compressed although the waiting happens before they even arrive, an hosting provider gets replaced although the slowness comes from an advertising script installed for a campaign that ended months ago.

This article gives no fixes. It sorts: for each of the five causes, the symptom that identifies it, the check that confirms it, and where to go next. The order is not decorative — it is explained at the end, and it has a practical consequence: as long as an upstream cause is present, every measurement below it means nothing.

Contents

• The question that cuts the problem in two
• Cause 1. The server takes time before it answers
• Cause 2. Your site rebuilds every page on every visit
• Cause 3. The database works while the visitor waits
• Cause 4. Display is blocked by what loads before it
• Cause 5. The code you did not write
• Why this order and not another
• The four mistakes that cost the most
• Frequently asked questions
• What is left to do

The question that cuts the problem in two

Before the five causes, a single question does half the work:

Does the waiting happen before anything appears at all, or while the page is being assembled in front of you?

Look at your own site on an ordinary connection, and describe what you see:

• the screen stays blank, then everything arrives almost at once → the waiting is before the first byte. Look at causes 1, 2 and 3;
• something appears quickly, then the rest falls into place slowly, in pieces → the waiting is after. Look at causes 4 and 5.

This observation costs nothing and it rules out half the possibilities. You then confirm it with a number: the server response time, which every measurement tool displays separately from the rest. It is the delay between the browser's request and the first byte received — before any display, any image, any script.

One reflex before touching anything: back up the current state. A diagnosis breaks nothing, but the fixes that follow can.

Cause 1. The server takes time before it answers

The symptom. Everything is slow, including pages that contain almost nothing — a legal notice, a contact form, the page of a short article. The slowdown depends neither on the content of the page, nor on the time of day, nor on the visitor.

What confirms it. Server response time is high on a deliberately thin page. That is the important part: measuring the home page proves nothing, since a home page is almost always the busiest on the site. Take the emptiest page you have.

What it means if it is not that. A server that answers quickly on a thin page but slowly on a rich one does not point at hosting: it points at whatever that page does on top — either cause 2 or cause 3.

Why it is the first to rule out. If the answer is slow before the build even starts, no display optimisation will show. You will gain tenths of a second on a cost centre that is not the one that hurts, and conclude that "nothing works".

The common causes are dull: a saturated shared plan at peak hours, an old PHP version, no server-side execution cache. These are hosting subjects, not WordPress subjects — and that is exactly why they are found late, while looking at the site.

Cause 2. Your site rebuilds every page on every visit

The symptom. The slowness is steady, identical for every visitor, and it gets markedly worse when several people arrive at once. The site holds when it is quiet and collapses when it is not.

What confirms it. Without a page cache, WordPress redoes the same work on every visit: query the database, assemble the content, apply the theme, produce the page. Two visitors asking for the same article trigger the same build twice, for an identical result.

What it means if it is not that. A site that already has a cache and is still slow for an anonymous visitor points back to cause 1. If it is slow only for logged-in people, it is cause 3 — and that is the most badly diagnosed case of all, because the cache makes it look as though the problem is solved.

Where to go. This is the cheapest cause to treat and the most rewarding, and it has its own article: the page cache solution. On the tooling side, a free plugin does the job: our cache module.

Cause 3. The database works while the visitor waits

The symptom, and it is very recognisable. The site is fast in a private window and slow once you are logged in. Or: fast on content pages, slow on the cart, the account page, the internal search, the dashboard. On a shop, those are exactly the pages that make money.

What confirms it. Open the same page logged out, then logged in. If the gap is clear, the page cache is hiding the problem from anonymous visitors and leaving it whole for everyone else — because a personalised page cannot be served from a copy.

What is usually behind it. Options loaded automatically on every request, including those left behind by plugins uninstalled long ago. Queries that scan a whole table — painless while the table is small, tiresome once it has grown. Scheduled tasks that WordPress triggers on a page load, which amounts to making the visitor who happened to pass by pay for the site's housekeeping.

The ageing sign. This cause does not appear overnight: it settles in. A site that slows down gradually over months, with no visible change, almost always points here. It gets blamed on hosting, the plan gets upgraded, and nothing moves.

Where to go. The treatment is detailed in the advanced techniques, and the number of installed plugins plays a direct part: audit your plugins.

Cause 4. Display is blocked by what loads before it

The symptom. The server answers quickly — you have checked — and yet the screen stays blank for a while, then the page appears in one block. The waiting is no longer in the answer, it is in what the browser has to process before it can draw.

What confirms it. A correct server response time combined with a late first paint. The browser has received the page and still cannot show it: it is waiting for stylesheets, scripts, sometimes a remote font, before it hands back control.

The most common forms. A single stylesheet holding the styling of every page on the site, including the ones the visitor will never see. A library loaded across the whole site for a form that exists on one page. A font called from a third-party domain, which adds a name lookup and a connection before the first readable word.

The case of images, which belongs to this family. The largest element of the first screen is often an image; until it arrives, the page looks empty even when everything else is ready. An image served at dimensions far above the ones it is displayed at transfers bytes nobody will see. The subject has its own article: lighten your site's photos, and the matching free tool: image optimisation.

Where to go. The metrics that describe this precise moment, and how to read them without fooling yourself, are in optimising Core Web Vitals. On a shop: WooCommerce Core Web Vitals.

Cause 5. The code you did not write

The symptom, and it is the sharpest test in this article. The site is slow in production and fast on a staging copy — although it is the same site, the same theme, the same plugins. The difference is not in the site: it is in what was added in production and never installed anywhere else.

What makes up this cost centre. Audience measurement, consent banner, live chat, advertising pixels, remote fonts, maps, testing tools, conversion tracking. Each was asked for one day by someone, for a reason that was good at the time.

What makes it peculiar. It is the only cost centre nobody in the company wrote a line of, and therefore the only one nobody feels entitled to remove. It grows by accumulation and never shrinks on its own — a pixel installed for a campaign that ended keeps loading on every visit, indefinitely.

What it means if it is not that. A staging copy as slow as production clears the third parties and sends you back to causes 1 to 4.

The consent banner case. It is mandatory, it arrives early in the load, and it often shifts the page as it inserts itself. The answer is not to remove it: it is to place it without pushing the content. Covered in our approach to consent and cookies.

Why this order and not another

The order does not rank the causes by frequency or by severity. It follows a single rule:

An upstream cause makes every downstream measurement false.

If the server is slow to answer (cause 1), everything you measure about display will be polluted by that wait. If the site rebuilds every page (cause 2), your measurements will vary with the traffic of the moment and you will conclude anything at all from a before/after comparison. If the database works on every visit (cause 3), the cache will hand you good numbers on anonymous pages and you will hide the problem instead of seeing it.

Hence the practical consequence, which is the whole point of the list: each cause ruled out makes the next one measurable. This is not an order of priority, it is an order of validity.

A second reason, less theoretical: cost. The first three causes are checked without touching the site, and the first two are fixed without touching any code. The last two require judgement calls — removing a script means talking to whoever asked for it.

The four mistakes that cost the most

Measuring the home page. It is almost always the most worked-on and the least representative. Measure a content page, a product page and a checkout page: three profiles, three different bottlenecks. The full reasoning for shops is in checkout funnel optimisation.

Not writing down the numbers from before. Without a starting point on paper, no fix can be judged, and the discussion always ends with "I think it feels better". Write the numbers down, and keep one page untouched as a control.

Changing several things at once. It is the surest way never to know what worked — and to keep three useless settings forever because they were in the batch that did.

Optimising what the tool displays instead of what the visitor lives through. A score that goes up because a script was pushed back three seconds has improved nothing: the wait left the measurement, not the page. Field data describes your visitors; a synthetic test from a nearby data centre describes nobody.

Frequently asked questions

Is a slow site really penalised in search results? Speed is one criterion among others, and rarely the one that decides a ranking. Its most measurable effect is not in the ranking but in what happens after the click: a visitor who waits leaves. It is a conversion subject before it is a search subject.

Should I change hosting provider? Only after ruling out causes 2 to 5. Moving host is expensive, risky, and it only fixes cause 1. Many migrations are done for a problem that would have followed the site.

Does removing plugins speed a site up? Often, but not for the reason people think. It is not their number as such: it is that each one adds option reads, scripts and hooks executed on every page. The subject is covered in the plugin hell.

My site was fast a year ago. What happened? A gradual slowdown with no visible change almost always points to cause 3: the database grows, unindexed queries cost more and more, accumulated options keep loading. Nothing is broken — the accumulation is finally showing.

What is left to do

The sorting is done in order, and it stops as soon as a cause is confirmed:

• Describe what you see — blank screen then everything at once, or progressive display
• Measure server response time on a thin page, not on the home page
• Compare logged out and logged in on the same page
• Compare production and staging, if you have one
• Write down every number you take, with the date, before changing anything
• Treat one cause only, measure again, then move to the next

To keep an eye on the whole thing without thinking about it daily, the periodic health check is described here: knowing whether your site is doing well.

And the sentence to keep, if only one: open the slowest page on your site, not your home page. That is the one your unhappy customers saw.

On tooling, the free versions are enough for the diagnosis and for the first two causes: page cache, page performance and image optimisation. The matching premium versions come with a full refund within 14 days.