Every week someone tells us their WordPress site is slow and asks which speed plugin to install. Nine times out of ten, the plugin isn't the problem — the stack underneath the site is. Here's what's usually going on, how to prove it with numbers, and what actually fixes it.
One framing before we start, because it explains almost everything below: hosting has a triangle — fast, good, cheap: pick two. Cheap hosting is slow by design, not by accident. When a server is sold to as many customers as possible at the lowest possible price, performance is what got sacrificed to hit the price. We skip the cheap corner — and this article shows you how to tell which corner you're standing in.
First, learn to read TTFB — the honest metric
Time to first byte (TTFB) is how long the browser waits before the server sends anything at all. It strips out your theme, your images, your fonts — everything you'd be tempted to blame. Rough guide on a cached page:
- Under 200ms — properly tuned hosting. Nothing to fix here.
- 200–600ms — workable, with room to improve.
- Over 600ms — the hosting is the bottleneck. No caching plugin on earth will rescue this; the wait happens before WordPress even finishes thinking.
The usual suspects, in order of likelihood
1. The shared hosting squeeze
Your site shares a server — CPU, memory, disk — with hundreds of others. Hit your account's limits and requests queue. Add a noisy neighbour having a busy moment, and your TTFB triples through no fault of anything you installed. "Unlimited" storage doesn't help; the scarce resource was always compute.
2. No server-level caching
WordPress renders every page in PHP for every visitor. Server-level page caching stores the finished HTML and serves it without running PHP at all. A caching plugin on plain Apache without server support still wakes PHP for every request — you get the plugin's settings screen but not its promise.
3. Missing object cache and opcache
Two different things people confuse. Opcache stops PHP recompiling your code every request — free performance many budget hosts never switch on. An object cache (Redis or Memcached) stores repeated database results in memory. It matters most when the page cache can't be used — logged-in users, WooCommerce checkouts, membership sites.
4. Front-end weight
Once the server's fast, the page itself can still be heavy: full-size images where WebP belongs, five font families where one would do, render-blocking scripts, and third-party widgets each adding their own round trips. One caution from the trenches: don't lazy-load your hero image — it's the first thing visitors see.
5. No CDN, and slow DNS
If your server sits in one city and your customers don't, physics is against you. A CDN caches your assets near your visitors. DNS is the very first lookup before anything happens — anycast DNS answers from the nearest node instead of one fixed location. Both are cheap wins that cheap hosting tends to skip.
The fix, in order of impact
- Move to properly tuned managed WordPress hosting — server-level caching, Redis, modern PHP, CDN and anycast DNS. Ours does all of it; whichever host you choose, ask the questions below.
- Turn on the caches your host provides.
- Cut page weight — modern image formats, fewer plugins, deferred scripts.
- One font family. Maybe two.
Five questions to ask any host before you pay them
- What's your TTFB on a cached page, and will you show me a live test?
- Is page caching server-level or plugin-only?
- Is Redis or Memcached available for object caching?
- How many PHP workers do I actually get?
- Where are backups stored, and how do I restore one myself?
Quick, confident answers: fast-and-good corner. Vague ones about "optimised servers": you've found the cheap corner. Not sure where your site stands? Ask us for a once-over — we'll tell you honestly, even if the answer is "you're fine".
