Your WordPress site is slow: a diagnostic checklist

When a site is slow, the instinct is to buy more server. Sometimes that's right. Usually it isn't — you'll pay more every month to run inefficient code slightly faster.

Work through this list in order. Stop when it's fast.

1. Find out what's actually slow

"The site is slow" isn't diagnosable. Get a number and a location.

Run the page through a waterfall tool and look at time to first byte separately from total load time. They point at completely different problems:

• High TTFB (over ~600ms) means the server is spending a long time building the page. That's PHP, the database, or a plugin. Keep reading.
• Low TTFB, slow overall means the server is fine and the problem is what you're sending — images, fonts, scripts. Skip to step 4.

Getting this distinction right saves you from optimising the wrong half of the problem.

2. Turn on caching at the server, not in a plugin

If your host offers server-level page caching, use it and remove your caching plugin. Two caching layers fighting each other is a genuinely common cause of both slowness and bizarre intermittent bugs.

A cached page skips PHP and the database entirely. For a content site this alone often takes TTFB from 800ms to under 100ms.

If your host doesn't offer server-level caching, that's worth more than any plan upgrade they'll sell you.

3. Find the plugin that's costing you

Almost every genuinely slow WordPress site has one plugin responsible for most of it. Common offenders: heavyweight page builders, "related posts" plugins that run unindexed queries on every load, statistics plugins writing to the database on every request, and anything doing an external API call during page render.

To find it, install a query monitoring plugin on staging, load a slow page, and sort by time. The answer is usually obvious and usually one line in the report.

Then decide honestly whether the feature is worth the cost. Sometimes it is. Often it's a plugin someone installed in 2021 for a feature nobody uses.

4. Fix your images

Images are the single largest payload on most sites, and the fix is mechanical:

• Serve WebP or AVIF instead of JPEG and PNG.
• Resize to the largest size actually displayed. A 4000px-wide photo in a 800px column is 25× the bytes for no benefit.
• Add loading="lazy" to anything below the fold.
• Set explicit width and height so the browser doesn't reflow the page as they arrive.

Modern WordPress does some of this automatically. Verify rather than assume — check the actual bytes going over the wire.

5. Deal with the database

Two things accumulate quietly and cost you on every uncached page load:

Post revisions. WordPress keeps every draft forever by default. A site with a few thousand posts can carry hundreds of thousands of revision rows. Cap them in wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

Autoloaded options. Every page load reads every option marked autoload = yes. Plugins — especially uninstalled ones that left data behind — dump large blobs in there. If your autoloaded options total more than a megabyte, find out what's in there and clear out what's orphaned.

6. Now consider a bigger plan

If you've done all of the above and TTFB is still high under real traffic, you've genuinely outgrown the plan. Upgrade — but you now know you're paying for capacity you actually need, rather than paying to host a badly-behaved plugin.

One caveat on measurement: test with the cache warm and the cache cold, and test while logged out. Logged-in requests bypass most caching, which is why site owners routinely think their site is slower than visitors experience it.