Why is my WordPress site slow?
Most "slow WordPress" advice tells you to install a caching plugin and hope. Here is how to find the actual bottleneck first.
Most advice about slow WordPress sites starts with "install a caching plugin". That is a fix for one specific cause, applied blindly to every symptom. Sometimes it works. Often it papers over the real problem, and occasionally it makes things worse by adding another layer that can misbehave.
Speed problems fall into four buckets. Working out which one you have takes about ten minutes and saves you from optimising the wrong thing.
The four causes, in the order worth checking
1. The server takes too long to respond
This shows up as a high TTFB — time to first byte. The browser asks for the page and then just waits. Nothing can render, because nothing has arrived yet.
A high TTFB on an uncached page means PHP and the database are doing too much work, the server is underpowered, or it is contended — you are sharing a machine with neighbours who are using more than their share.
A high TTFB on a cached page is worse news. It usually means caching is not actually working, or the server is genuinely slow at handing over a file that is already sitting there ready.
Measure it with our website speed test, or check what you are actually running on with Who Hosts This Site?.
2. The page is enormous
The single most common cause on real small-business sites is images. A photographer uploads a 6 MB JPEG straight off the camera, WordPress serves a resized version in the layout but the underlying file is still huge on some templates, and every visitor downloads it.
Check the total transferred size of your homepage. As a rough sanity check, a content page that transfers more than about 2 MB is carrying weight it almost certainly does not need.
The usual offenders:
| Culprit | Typical cause | Fix |
|---|---|---|
| Oversized images | Uploaded at full camera resolution | Resize before upload, serve WebP/AVIF |
| Slider plugins | Loading five full-width hero images | Use one image, or remove the slider |
| Icon fonts | Whole font loaded for six icons | Inline SVG instead |
| Multiple font families | Theme loads four weights of three fonts | Two weights, one family |
| Video backgrounds | Autoplaying MP4 in the hero | Poster image, load on interaction |
3. Too much is happening before anything renders
Render-blocking CSS and JavaScript stop the browser painting anything until they are fetched and parsed. A theme that loads jQuery, a page builder runtime, three Google Font requests and an analytics script in the head will feel slow even on excellent hosting.
This is where plugin count starts to matter — not because "plugins are bad", but because each one tends to add its own stylesheet and script to every page, whether that page uses it or not. A contact form plugin loading its CSS on your blog archive is pure waste.
4. Something specific is broken
Occasionally the answer is one thing behaving badly: a plugin making an external API call on every page load, a cron job that has backed up, a database table that has grown to hundreds of thousands of rows of expired transients, or a theme querying every post to build a menu.
These are the ones that make a site intermittently slow, which is the most maddening pattern to debug. If your site is fine at 3am and terrible at 2pm, suspect either contention on shared hosting or a scheduled task.
How to tell hosting from everything else
This is the question that actually matters, because it determines whether you spend a weekend optimising or twenty minutes migrating.
Run a speed test and look at two numbers:
- TTFB — how long until the first byte arrives
- Everything after TTFB — how long until the page is usable
If TTFB is slow and the rest is fine, the problem is server-side: hosting, PHP, or database. Optimising images will not help you.
If TTFB is fast and the rest is slow, the problem is in your site's front end. Changing host will not help you.
If both are slow, fix the front end first — it is cheaper and you will need to do it anyway.
A useful second test: load a page that is definitely not cached, such as a URL with a random query string appended. If that is dramatically slower than the cached version, your server is struggling with dynamic generation, which is a hosting-shaped problem.
When it genuinely is the hosting
Some honest signals that you have outgrown your plan:
- Response times get noticeably worse at predictable times of day
- The host's own status page or support acknowledges resource limits
- You are hitting CPU or entry-process limits in your control panel
- The site is fine with one visitor and falls over with twenty
- You are on the cheapest tier of a budget host and traffic has grown
If several of those are true, no amount of plugin tuning will fix it. Our WordPress hosting recommendations cover what actually changes when you move up, and the Hosting Finder will narrow it down by traffic and budget.
A sensible order of work
- Run the health check and note TTFB
- Fix images — resize, compress, modern formats
- Remove plugins you are not using, rather than optimising around them
- Add page caching, once you know what it is actually caching
- Only then consider changing host
Doing it in that order means that if you do end up migrating, you migrate a fast site onto better hosting instead of moving a slow one and being disappointed.
Common questions
Will a caching plugin fix a slow WordPress site?
Sometimes. Caching fixes slow page generation, which is one of four common causes. If your problem is huge images, a slow server response on cache misses, or render-blocking scripts, caching will barely move the needle.
Is my host or my site to blame?
Compare TTFB against everything else. If TTFB is high but the rest of the load is fast, the server or the PHP that runs before caching is the problem. If TTFB is low but the page still feels slow, the front end is at fault.