Why your WordPress site is slow, in the order it is usually true

Most speed advice is a list of twenty tips in no particular order. In practice, four things cause the overwhelming majority of slow WordPress sites, and the other sixteen are rounding errors. Here they are in the order they are usually the culprit.

1. Your hosting

The single biggest factor, and the one nobody wants to hear because changing it is disruptive.

Shared hosting at $3 a month puts hundreds of sites on one server. When one of them gets busy, yours slows down, and no amount of caching fixes a server under load. If your time to first byte is above 600ms, this is your problem and nothing else on this list will rescue it.

What to do: check TTFB in any speed testing tool. If it is consistently high, move. Decent hosting starts around $20 to $30 a month, and the difference is usually larger than everything else here combined.

Typical improvement: 30 to 60 per cent.

2. Images

Almost every slow site is slow partly because someone uploaded a 4MB photograph straight from a phone.

What to do:

• Resize before uploading. A full-width banner needs about 1920px wide, not 6000.
• Serve WebP. It is typically 25 to 35 per cent smaller than JPEG at the same quality.
• Compress everything. A plugin can do this in bulk.
• Lazy-load anything below the fold — WordPress does this by default now, but themes sometimes break it.
• Always set width and height attributes, or the page jumps as it loads and your Core Web Vitals suffer.

Typical improvement: 20 to 40 per cent on image-heavy pages.

3. Too many plugins, or a few bad ones

The count matters less than people think; the quality matters far more. Thirty well-built plugins can be fine. Three badly built ones can be fatal — especially page builders, sliders, "all-in-one" suites, related-post plugins that query on every load, and anything that adds its own jQuery.

What to do: install Query Monitor and look at what is actually slow. Deactivate plugins one at a time on a staging copy and measure. Delete anything you are not using — deactivated is not enough, it is still code on the server.

Typical improvement: highly variable, occasionally enormous.

4. No caching, or caching configured wrongly

Without caching, WordPress rebuilds every page from the database on every visit. With it, most visitors get a pre-built file.

What to do: one caching plugin, not three. Page caching on, browser caching on, GZIP or Brotli on. If your host offers server-level caching, use that instead of a plugin — it is faster and conflicts less. Add a CDN if your visitors are spread geographically.

Typical improvement: 40 to 70 per cent on repeat page loads.

The next tier, worth doing after the above

Database bloat. Autoloaded options above about 1MB slow every single page load, and it is usually junk left behind by plugins that were removed years ago. Post revisions, expired transients and spam comments add up too. This needs care — deleting the wrong row breaks things.

Render-blocking CSS and JavaScript. The browser stops to fetch and parse them before it can paint. Most caching plugins can defer or combine these, but test afterwards, because this is the optimisation most likely to break a layout.

Fonts. Each custom font is a separate request. Self-host them, subset to the characters you actually use, and set font-display: swap.

Third-party scripts. Chat widgets, analytics, ad pixels, embedded videos. Each one is a request to someone else's server on a page you do not control. Audit them: most sites are carrying at least one nobody remembers adding.

How to measure it honestly

• PageSpeed Insights for Core Web Vitals and Google's own view
• GTmetrix for a waterfall showing what is actually slow
• Query Monitor, inside WordPress, for slow database queries and which plugin is responsible

Test the same page three times and take the median. Single measurements vary enough to send you chasing noise.

And measure what matters: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200ms, Cumulative Layout Shift under 0.1. A perfect score with a slow LCP helps nobody.

When it is worth paying someone

Doing the first four yourself is realistic if you are comfortable in WordPress — a weekend, and most of the gain. The database and render-blocking work is where people break things, and it is the part with the smallest margin for error.

If you would rather not, our speed optimisation is a fixed $299 with before-and-after numbers you can verify. And on Standard and Pro care plans a speed pass happens every quarter, which matters more than a single optimisation — sites get slower again, and the second slowdown is the one nobody notices.