When Your Host Says Everything Is Fine, But Your Site Is Slow

When Your Host Says Everything Is Fine, But Your Site Is Slow

A client emailed me at 11:47pm on a Tuesday: "the site is taking forever to load." I opened it on my phone — 4.6 seconds to first byte, 7.1 seconds to fully rendered. I opened a support ticket with the host. Forty minutes later: "We've checked your server and everything is operating normally. Load average is 0.4. CPU is 12%. MySQL is healthy. We don't see any issues on our end."

Both statements were true. The host's monitoring saw a healthy server. The visitor's browser saw a site that was unusable. The gap between those two truths is where this entire post lives.

If you're running on shared, managed, or even cheap VPS hosting, this is the conversation you'll have over and over until you stop trusting "everything is fine on our end" and start measuring what actually matters: the experience of the user loading your page.

Why "the host says it's fine" is not a lie (but is not the answer)

Your hosting provider's monitoring is server-centric. It checks:

• Is the server pingable?
• Is CPU saturated?
• Is memory exhausted?
• Is MySQL accepting connections?

That's the host's contract. They sold you a working machine, the machine is working, contract fulfilled.

What the host's monitoring does not check:

• How long does your specific PHP code take to run?
• Is your MySQL query the one taking 3 seconds while the rest of the database is fine?
• Are your page assets fighting each other for render-blocking?
• Is the slowness happening from your visitor's geography and not from the host's data center?

Their dashboard says "the kitchen is functional." Your visitor is asking "where's my food?" Both are valid. Neither answers the other.

The four real culprits, in order of frequency

After diagnosing this exact pattern across hundreds of sites, here's the realistic frequency distribution:

1. TTFB on the server (PHP + MySQL slowness) — about 50% of cases
2. Render-blocking CSS/JS in the browser — about 25%
3. Slow MySQL queries from a specific plugin — about 15%
4. DNS, TLS handshake, or CDN misconfiguration — about 10%

You diagnose them in roughly that order, because TTFB is the easiest to measure and the most commonly responsible.

Step 1: Measure where the time is actually going

Before you change anything, you need a number. Open Chrome DevTools, Network tab, reload the page. Look at the first row (the document request itself) and check:

• Queueing + Stalled — usually under 50ms. If it's 500ms+, suspect DNS or TCP issues.
• DNS lookup — should be under 100ms. If it's 1s+, your DNS is the problem.
• Initial connection / SSL — should be under 300ms. If it's 1s+, TLS or CDN issues.
• Waiting (TTFB) — this is the server thinking. Should be under 800ms for a healthy WP site. If this is 2s+, the bottleneck is server-side.
• Content download — should be under 200ms for a typical HTML page. If big, the page is bloated.

Then look at the rest of the waterfall. If TTFB is fine but the page still takes 6 seconds to render, you're looking at a frontend problem (render-blocking CSS, sync JS, fonts).

Step 2: When TTFB is the problem

TTFB above 1 second on a WordPress site means the server is taking too long to generate the page. Three things to check, in order:

2a: PHP execution time

If you have agent-level visibility, pull up the process metrics. You're looking for:

• php-fpm workers consistently using 90%+ CPU during the slow request
• php-fpm worker count saturated (all workers busy, queue forming)
• Memory usage on php-fpm workers climbing into the 400MB+ range each (a sign of leaky plugin code)

Without an agent, you can SSH in and run:

# How many php-fpm workers are running, and what are they doing?
ps aux | grep php-fpm | head -20

# Is the PHP-FPM pool saturated?
# Look for "max_children reached" in the slow log
tail -100 /var/log/php-fpm/error.log

# Quick CPU breakdown
top -b -n 1 | head -20

If php-fpm is the bottleneck, the realistic fixes are: enable a page cache (WP Super Cache, W3 Total Cache, or a built-in one if you're on managed hosting), bump the worker pool size if you have headroom, and find the specific plugin that's eating CPU.

2b: MySQL slow queries

This is the silent killer on WP sites with 50+ plugins or large wp_options tables. SSH in and:

# Enable the slow query log temporarily (if you have access)
mysql -e "SET GLOBAL slow_query_log = 'ON';
          SET GLOBAL long_query_time = 1;
          SET GLOBAL slow_query_log_file = '/tmp/slow.log';"

# Reproduce the slow page load a few times.

# Then look at what got logged:
tail -50 /tmp/slow.log

The killer queries are almost always one of:

• SELECT * FROM wp_options WHERE autoload = 'yes' — autoloaded options table is bloated. Dump it: wp option list --autoload=yes --format=count. If it's over 1000, you have a plugin leaving junk behind.
• A plugin doing a SELECT ... ORDER BY meta_value on wp_postmeta without an index.
• wp_postmeta joins that don't have proper indexing for the query pattern.

If you've installed the Netwarden agent on the host, the MySQL collector surfaces query stats automatically. The "average query time" metric will jump from 5ms to 300ms in real time when this happens. That's how you connect "site felt slow at 11:47pm" to "this specific plugin started doing 3-second queries at 11:43pm."

2c: Disk I/O wait

If CPU is fine but the server still feels sluggish, check I/O wait:

# `wa` column in top is the I/O wait percentage
top -b -n 1 | head -5

# Or more direct:
iostat -x 1 5

# %iowait above 20% sustained = your disk is the bottleneck.

On shared and cheap VPS hosting, disk I/O wait is often the actual problem and it's invisible to the host's "load average" check. Load average is 0.4 because your CPU is waiting on disk, not running. The host sees idle CPU and concludes everything is fine. Your visitor sees a dead site.

The Netwarden agent reports disk_io_wait and memory pressure as first-class metrics for exactly this reason.

Step 3: When TTFB is fine but the page is slow

If TTFB is under 800ms and the page still feels broken, you're looking at frontend issues. The realistic checks:

• Render-blocking CSS or JS in the <head>. Anything <script> without defer or async blocks rendering.
• Web fonts loaded synchronously without font-display: swap. A slow font CDN can hold the entire page hostage for 3 seconds.
• Heavy hero images without lazy loading or srcset.
• A plugin injecting 200KB of inline CSS into the head (looking at you, every page builder).

Lighthouse in Chrome DevTools is the right tool here. It'll tell you in 30 seconds whether the problem is in the HTML/CSS/JS pipeline. A passing TTFB score with a failing LCP score is the signature of a frontend-rendering bottleneck.

Step 4: When DNS or TLS is the problem

This one's rare but spectacular when it happens. If users in one geography report slowness and users in another don't, suspect DNS or CDN.

# Check DNS resolution time from the visitor's region
dig +stats yoursite.com

# Or from multiple regions:
curl -w "@curl-format.txt" -o /dev/null -s https://yoursite.com

Where curl-format.txt is:

    namelookup:  %{time_namelookup}s\n
       connect:  %{time_connect}s\n
   appconnect:  %{time_appconnect}s\n
  pretransfer:  %{time_pretransfer}s\n
     redirect:  %{time_redirect}s\n
starttransfer:  %{time_starttransfer}s\n
        total:  %{time_total}s\n

namelookup over 200ms = DNS is slow. appconnect over 500ms = TLS handshake is slow. Both usually point to a misconfigured CDN, an expired DNS cache, or a Cloudflare / Bunny / KeyCDN config you forgot you had.

The decision tree

Here's the flowchart in text form. Print it, tape it next to your monitor.

Site is slow.
│
├─ Check Chrome DevTools Network tab on the document request.
│
├─ Is TTFB > 1.5s?
│   │
│   ├─ Yes ──> Server is slow.
│   │         │
│   │         ├─ Is %iowait > 20% in `top`?
│   │         │   ├─ Yes ──> Disk bottleneck. Check disk health, swap usage,
│   │         │   │           noisy neighbor on shared hosting.
│   │         │   └─ No  ──> Continue.
│   │         │
│   │         ├─ Are php-fpm workers all busy?
│   │         │   ├─ Yes ──> Page cache, more workers, find leaky plugin.
│   │         │   └─ No  ──> Continue.
│   │         │
│   │         └─ Is MySQL slow query log showing > 1s queries?
│   │             ├─ Yes ──> Find the plugin. Optimize wp_options.
│   │             │           Add indexes if you can.
│   │             └─ No  ──> Network egress from host? Outbound API call
│   │                         from a plugin? Check process-level stats.
│   │
│   └─ No  ──> Server is fine. Frontend is the problem.
│              │
│              ├─ Run Lighthouse. LCP > 2.5s?
│              │   ├─ Render-blocking resources ──> defer/async JS,
│              │   │                                  inline critical CSS.
│              │   ├─ Large images ──> srcset, lazy loading.
│              │   └─ Font issues ──> font-display: swap.
│              │
│              └─ DNS / TLS slow?
│                  ├─ Slow `namelookup` ──> Check DNS provider, TTLs.
│                  └─ Slow `appconnect` ──> CDN/TLS misconfig, cert issues.

What an agent on the host shows you that the host's status page doesn't

This is the part where I'll stop being neutral and tell you why we built Netwarden's agent. The host's status page is server-level and outside-in. The agent is your-application-level and inside-out. The numbers it surfaces, that the host's status page does not:

• Process-level CPU and memory. Not just "the box is at 12%," but "this specific php-fpm worker has been pinned at 100% for 14 seconds." That's the difference between "fine" and "your contact form plugin has gone rogue."
• I/O wait per process. Whether your code is the one waiting on disk.
• Memory pressure (not just usage). A box at "60% memory" might be swapping constantly because the working set is wrong.
• MySQL query patterns. Average query time, slow query count, connection saturation — visible in real time, not as a once-a-day report.
• System updates pending. Including the security ones, separately. (When was the last time your host emailed you about a kernel CVE before applying it?)
• WordPress-specific: plugin error counts, autoloaded options size, slow PHP requests by URL pattern.

You install the agent with one command:

curl -sSL get.netwarden.com | bash

It auto-discovers what's running. If MySQL is on the box, you get MySQL collectors. If Docker is running, you get container metrics. If WordPress is detected and the plugin is installed, you get WP-level stats. You don't configure 12 separate collectors by hand.

For a deeper dive on why monitoring needs to be inside-out for SMB-sized sites, see WordPress Monitoring: The Practical Cornerstone and Why I Built Netwarden.

What to do with what you find

Two paths, depending on your access:

Shared / managed hosting (you don't have root). Take the data to support. "Your monitoring shows everything green, but my Netwarden agent shows %iowait at 35% sustained for 20 minutes during the slowness. Can you confirm the disk subsystem on the node hosting my account is healthy?" Watch how fast the conversation moves when you arrive with metrics.

VPS / dedicated (you have root). Now you can actually fix it. The diagnosis above is also the fix list — page cache, more PHP workers, fix the slow query, swap CDN configs.

The honest summary

"Everything is fine on our end" is true. It's also useless. Your site is the only end that matters to your visitors. You need monitoring that watches your end.

If your host's monitoring caught the kind of problems described in this post, you wouldn't be reading it. They don't, because their incentives stop at the server boundary. Yours don't.

---

Get started

• Install the agent on your host: curl -sSL get.netwarden.com | bash. Free tier covers 1 host.
• Sign up free at app.netwarden.com — no card required.
• Self-host if you'd rather run it yourself: same single binary.

Keep reading

• WordPress Uptime Monitoring on a Budget — when uptime pings aren't enough.
• Monitor 50 client WordPress sites for under $30/month — agency playbook.
• Alerts That Actually Page You — turning the diagnosis above into alerts that catch the next incident before the client emails you.
• Database Monitoring — what the MySQL/PostgreSQL collectors actually report.
• Service Discovery — what gets auto-detected when you install the agent.