DEV Community

NOGUCHILin
NOGUCHILin

Posted on

Is your WordPress host the real bottleneck? How to tell in 10 minutes, with numbers

#wordpress #webperf #hosting #tutorial

Everything below is measured on real sites, not quoted from marketing pages. Affiliate disclosure at the end.

Half the "why is my WordPress slow" advice on the internet says install a cache plugin. The other half says change your host. Both are sometimes right - and you can tell which one applies to you in about 10 minutes of measuring. Here is the exact process I use in client audits.

Step 1: Measure TTFB on three kinds of URLs

TTFB (time to first byte) is the part of load time your front-end can never fix. Run each of these 3-5 times:

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://yoursite.com/
Enter fullscreen mode Exit fullscreen mode
  1. A static file - /readme.html exists on almost every WordPress install and bypasses PHP entirely. This is your server's floor.
  2. A cacheable page - your homepage.
  3. An uncacheable page - cart, checkout, or any logged-in page. This is your PHP + database reality.

Step 2: Read the pattern

  • readme.html fast (<200ms), homepage fast, checkout 1.5s+? Your host serves cached HTML fine, but every dynamic request pays full price: plugin init, database, no object cache. This was exactly the shape of a WooCommerce client I worked with recently - checkout TTFB was 3.3s on shared hosting.
  • Everything slow, even readme.html? The server itself (or its location) is the bottleneck. No plugin will fix this.
  • TTFB fine everywhere but the site still feels slow? Your problem is front-end (images, JS, fonts) - do not migrate, fix the pages. I wrote up how I audit that.

Step 3: Check what your host actually lets you use

Two questions decide whether "optimize in place" is even possible:

  • Is Redis (or any object cache) available? On the client project above, the answer was no - the plan simply did not offer it. Every uncached request rebuilt everything from MySQL.
  • Is OPcache actually on? Verify it - do not assume. (My first hypothesis on that project was "OPcache is off". It was on. Measuring beats guessing in both directions.)

If the answers are "no / can't", you have found a structural ceiling. Cache plugins stacked on top of that ceiling can even make things worse - on that same client, a popular optimization plugin's cache-check overhead was costing 3 seconds per checkout, and removing it cut load time by 60%.

What a healthy baseline looks like (measured)

To have a fair reference point, I spun up a stock WooCommerce store on Cloudways (managed WordPress hosting - affiliate link, disclosure below) and measured it from the other side of the Pacific:

URL type Result
Homepage (cached) TTFB 0.6-0.7s (including ~180ms of trans-Pacific latency)
Cart (uncacheable) TTFB ~0.9s
Lighthouse mobile 99 out of the box

No tuning, no extra plugins - server-side caching, Redis and OPcache just exist by default. That is the point: the shared-host client could not get uncacheable pages under 2.3s even after real optimization work; a managed baseline starts around 0.9s before any work at all.

The honest decision rule

  • Front-end problems (images/JS/fonts) → fix the pages, don't migrate. Cheaper and faster.
  • Dynamic pages structurally slow + no object cache available → migration buys you more than any plugin can. Budget $14-30/month managed vs $3-8 shared.
  • If you do migrate: script-check every old URL for 301 integrity, or your rankings pay for the speed.

Disclosure: the Cloudways link above is an affiliate link. I only recommend it because I measured it myself - the numbers in the table are mine, not theirs.

Top comments (2)

Collapse
 
luis_cruzy profile image
Luis Cruzy •

I really appreciate the step-by-step approach to identifying whether a WordPress host is the bottleneck, especially the use of TTFB measurements to diagnose issues. One thing that caught my attention was the example of a WooCommerce client where removing an optimization plugin actually improved performance by 60% - it highlights the importance of measuring and verifying the impact of any optimization efforts. I'm curious, have you found any other common optimization plugins that can sometimes do more harm than good, and how do you approach evaluating their effectiveness?

Collapse
 
noguchilin profile image
NOGUCHILin •

Thanks! The pattern I keep running into is overlap: two layers doing the same job, each adding its own overhead. The WP-Optimise case was exactly that - the host already had a proxy cache, and the plugin's cache-eligibility check still ran on every request, including checkout, which can never be cached anyway.

Other repeat offenders I've measured:

  • Page-cache plugins stacked on hosting that already caches at the server/proxy level. The cache rarely hits twice, but the PHP overhead runs every time.
  • Asset combine/minify on HTTP/2 - concatenation re-creates the problem HTTP/2 already solved, and one changed byte invalidates the whole bundle.
  • Image optimizers that process on request instead of on upload.
  • "Database optimization" schedulers running heavy cleanup during peak traffic.

How I evaluate: A/B/A on staging, one variable at a time. Measure the specific page that hurts (checkout, not the homepage), 3 runs per state, server response time rather than just the Lighthouse score, then flip it back and confirm the numbers follow the toggle. If the gain doesn't reproduce both ways, it was noise. And after any change, click through the money path (cart, checkout, payment) before calling it a win.

Rule of thumb I've settled on: every optimization plugin is code that runs on every request. It has to earn more than it costs, and the only way to know is measuring it on your specific stack.