Is your site slow because of your host, or because of your site?

Almost every “my site is slow” thread follows the same shape. Someone posts a speed test, half the replies say switch hosts, the other half say it’s your plugins, and the original poster is no better off than before they asked.

Both camps are guessing. The question is answerable in about twenty minutes, with tools you already have, and the answer determines whether you should be spending money or spending an afternoon.

A page load has two halves, and they have different owners.

The server half ends the moment the first byte of HTML arrives in the browser. That window belongs to your host and your application — DNS, connection setup, PHP execution, database queries. It is measured as Time to First Byte.

The browser half is everything after: downloading images, fonts, CSS and JavaScript, running scripts, painting the page. That belongs to how your site is built.

So: measure the server half first, because it is the half you can attribute cleanly.

Speed-test websites give you one reading from one location on one day. That is not enough to conclude anything. Run this from a terminal instead:

for i in {1..5}; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s  total: %{time_total}s\n" \
    https://yourdomain.com/
done

Five readings, because a single one tells you nothing about consistency. On Windows, use the same command in WSL or Git Bash.

Read the results like this:

For context, every provider in our speed rankings sits under 220ms on US origin TTFB, and the fastest is 118ms. Those figures are for a well-configured site on a healthy plan. If you are seeing 1,500ms, the gap is not explained by which company you chose.

This is the single most revealing measurement, and almost nobody runs it.

Request the same page twice: once so it serves from cache, once bypassing cache entirely. Most caching plugins bypass on a query string, so ?nocache=1 usually works. Failing that, log in — logged-in requests almost always skip the page cache.

# Cached
curl -o /dev/null -s -w "cached:   %{time_starttransfer}s\n" https://yourdomain.com/

# Uncached
curl -o /dev/null -s -w "uncached: %{time_starttransfer}s\n" "https://yourdomain.com/?nocache=1"

Now read the pair together:

If you run Cloudflare or any CDN, your speed test may be reporting how fast an edge cache answered — which says nothing about your actual server.

Check the response headers:

curl -sI https://yourdomain.com/ | grep -i "cf-cache-status\|x-cache\|age"

HIT means you measured the CDN. To measure the origin, request the server’s IP directly with the Host header set:

curl -o /dev/null -s -w "origin TTFB: %{time_starttransfer}s\n" \
  --resolve yourdomain.com:443:YOUR.SERVER.IP https://yourdomain.com/

This distinction is why our rankings report two separate TTFB columns rather than blending them into one score. A CDN can make a mediocre server look excellent in a speed test while every uncacheable page — checkout, account, admin — stays slow.

If that trade-off is your actual question, CDN or a faster server? covers it directly.

Run Test 1 again at three different times: early morning, mid-afternoon, and evening in your server’s timezone.

Consistent numbers — even mediocre ones — mean a stable environment. Numbers that swing from 200ms to 1,400ms mean resource contention: either your plan is undersized for what you are running, or you are sharing a machine with a site that is having a busy day.

That second case is the “noisy neighbour” problem, and it is the classic argument for leaving shared hosting. You cannot optimise your way out of somebody else’s traffic. It is also increasingly caused by automated traffic rather than human visitors — see AI crawlers and your hosting.

If Tests 2 and 4 point at your host and your host disagrees, this settles it.

Install a clean WordPress site on the same plan, in a subdirectory or subdomain. Default theme. No plugins. No content. Measure its TTFB.

A bare WordPress install should respond in well under 300ms on any competent host. If your empty install is slow, the conversation is over — it is not your plugins, your theme, or your images, because you no longer have any.

For most sites, the answer is the first row: the server is fine and the front end is heavy. That is not what people want to hear, because moving host feels like a decisive action and image compression feels like homework.

But the reverse case is real, and when it is real no amount of optimisation helps. If your uncached TTFB is above 600ms consistently, you are paying an unavoidable tax on every single page view, and the fix is a better server.

If you get there, the speed rankings compare eight managed cloud hosts on exactly the number you have just measured — US origin TTFB, no CDN assistance. Then switch hosts without losing rankings covers doing it without breaking anything, and what hosting actually costs covers not getting caught by renewal pricing on the way in.