Used by hosting buyers across 10+ countries  ·  Reviews updated October 2026  ·  50+ Hosts Reviewed  · 

How to Test a Host's Real TTFB Before You Buy

Buyer's Guide Last Verified: October 2026

How to Test a Host's Real TTFB Before You Pay

Every host publishes a fast number. This is the five-step check that shows what you would actually get, using free tools and about ten minutes.

800ms
Google's good-TTFB ceiling (web.dev)
17×
Singapore vs New York, same Kinsta demo site (our test)
10 min
to run the full five-step check

Written by Tom George · How we research hosts

Why a Host's Own TTFB Number Isn't Enough

Time to First Byte (TTFB) is how long your visitor waits before the server starts to answer. A lower TTFB means the page starts to appear sooner, which matters most on the pages that earn you money, like a product page or a checkout.

Every host publishes a flattering figure. Rocket.net, for example, reports a 70ms global average, and Kinsta's own materials point to fast cached responses. Those are the hosts' claims, measured under the hosts' conditions, and they are not a promise about your site.

The good news is you can measure it yourself before you commit. Below is the method we use, plus what we found when we ran it on our own Kinsta demo site. Our benchmark data page explains why single-number speed claims mislead; this page shows you how to test them.

FBWH Verdict

Test from where your visitors are, not where the host is. In our own run, the same Kinsta demo site returned its first byte in 177 ms to New York and 3.01 s to Singapore. The host did not change. The distance did.

Always check cached and uncached pages separately. A fast cached homepage tells you little about a cart or checkout page, which usually skips the cache.

Want a benchmark to compare against? Our own 8-location Kinsta result is included below, and the Kinsta review shows how it fits the plan.

Step 1: Get a Test URL That Runs on the Host

You cannot measure a host you have no page on. Start with the cheapest legitimate option: a demo site the host publishes, a trial, or a refund window on a plan you sign up for. Read the refund terms on the host's pricing page first, since they differ by host and by plan.

If you already know someone hosted there, ask for the URL of a live site. The result will include that site's theme and plugins, so treat it as indicative, not exact.

Once you have a URL, the next steps show how to read it properly.

Step 2: Test From More Than One Location

One reading from one city mostly measures how close that city is to the server. Use a tool that tests from several places. KeyCDN's free Performance Test runs a single URL from 10 locations around the world and reports TTFB, DNS, TLS and connection times for each.

Pick the locations closest to your real audience and compare them against the one nearest the data centre. The gap between those two numbers is what your visitors feel.

What we measured on our own Kinsta demo site

We ran our own Kinsta demo site, on Kinsta's default US data centre, through KeyCDN's multi-location test in August 2026. The same site gave very different first-byte times depending on where the test came from.

Test location TTFB to our Kinsta demo site Against Google's 0.8 s line
New York 177 ms Good
San Francisco 262 ms Good
London 364 ms Good
Amsterdam 466 ms Good
Frankfurt 674 ms Good, close to the line
Bangalore 1.05 s Needs improvement
Sydney 1.14 s Needs improvement
Singapore 3.01 s Poor (above 1.8 s)

The last column applies Google's published thresholds: 0.8 seconds or less is good, above 1.8 seconds is poor, and anything between needs improvement. The rating is our reading of those thresholds, not a Google score for this site.

Note: This is one demo site on Kinsta’s default US data centre, tested on one day. It is not a global average and not a test of any other host. Picking a data centre closer to your audience, or putting a CDN in front of cached pages, would change the far-away numbers.

The lesson is not that Kinsta is slow in Asia. The lesson is that a host's headline figure depends on which location you are standing in, so check yours. More ways to bring those far-away numbers down are in our server response time guide.

Step 3: Separate Cached From Uncached

Most managed hosts and CDNs cache full pages, so a repeat visit to your homepage may never reach WordPress at all. Pages that depend on a logged-in user, a cart or a checkout usually skip the cache and wait on PHP and the database.

Test both. Run your homepage, then a page that cannot be cached such as a cart, a search result, or the same URL with a random query string added. Then read the response headers: a header such as x-kinsta-cache shows HIT or BYPASS on Kinsta, and cf-cache-status does the same behind Cloudflare. Header names differ by host, and some caches ignore query strings, so confirm with the header, not the assumption.

We found exactly this pattern when we tested WooCommerce on Kinsta: the shop archive showed a cache BYPASS, while ordinary pages showed HIT. The full evidence is in our WooCommerce and Redis on Kinsta test.

Step 4: Measure It Yourself With One Command

If you are comfortable with a terminal, curl gives you a clean number without any third-party tool. This prints the time until the first byte arrives, in seconds:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://example.com/

Run it five times and use the median, not the best run. The figure includes DNS lookup and connection setup, so it reads slightly higher than a server-only measure, and that is closer to what a visitor experiences. To add the connection breakdown, add %{time_connect} to the format string.

Step 5: Repeat at Different Times and Compare

A single run on a quiet Tuesday morning flatters every host. Repeat the test at a busy hour, and on a second day, before you trust the result. If the median holds, the host is consistent. If it swings widely, that is a signal in itself.

Then line up the hosts you are considering using the same URL type, the same locations and the same time window. Comparing one host's best run to another's worst teaches you nothing.

How to Read Your Results

If your nearest-location number is under 0.8 s

That host clears Google's line for your audience on that page type. Look next at the uncached numbers and at how it behaves under load, which our fastest WordPress hosting guide covers.

If a key audience location is above 1.8 s

Ask whether the host offers a data centre nearer to that audience, and whether a CDN will cache those pages. If the answer is no to both, that host is a poor fit for that audience regardless of its headline number.

For visitors in India, our speed-up guide for Indian visitors walks through the fix.

If cached is fast but uncached is slow

That pattern is normal for caching setups, but it matters for WooCommerce and membership sites. Our WooCommerce hosting guides cover what to look for.

Where to Test First

If you are comparing managed WordPress hosts, these four are worth running through the five steps. Our full write-ups cover their prices and trade-offs, including what each costs when the introductory rate ends.

  • Kinsta review — data-centre choice and the multi-location results above.
  • Rocket.net review — a CDN-first design, so check cached and uncached pages separately.
  • WP Engine review — read the plan limits alongside the speed result.
  • Cloudways review — you choose the server region, so test the region you would pick.

For head-to-head views, see Kinsta vs Rocket.net and Kinsta vs WP Engine. Speed is only half the decision, so check the renewal price too, using our renewal price guide.

Test Kinsta → Read the Rocket.net Review →

Frequently Asked Questions

What is a good TTFB for a WordPress site?

Google's web.dev guidance says a good TTFB is 0.8 seconds or less, and anything above 1.8 seconds is poor. Values in between need improvement.

Treat 0.8 seconds as the ceiling, not the goal. A well-configured managed host should sit well below it for cached pages in the region you target.

Can I test a host's TTFB before I pay?

Sometimes. Some hosts publish a demo site you can test, and others offer a trial or refund window.

If neither exists, test a customer site hosted there that you already know, and treat the result as indicative only because it carries that site's plugins and theme.

Why is my TTFB different in every test?

TTFB changes with the test location, whether the page was served from cache, the time of day and server load. That is why one reading means little.

Run each test several times, from more than one location, and compare the median.

Does a CDN fix a high TTFB?

Only for pages the CDN can cache. A CDN serving a cached page from a nearby edge location removes most of the distance to your origin server.

Uncached pages such as a WooCommerce cart or checkout still go to the origin, so the host and its data centre still matter.

Is TTFB a Core Web Vital?

No. TTFB is not itself a Core Web Vital, but a slow first byte delays everything that follows, including Largest Contentful Paint, which is a Core Web Vital.

That is why it is worth checking before you choose a host.

The Bottom Line

A host's headline TTFB is a starting point, not evidence. Test from where your visitors are, test cached and uncached pages separately, repeat the runs, and compare hosts on equal terms.

Do that for two or three shortlisted hosts and the right choice is usually clear. Then confirm what it will cost after the first term, so a fast host does not turn into a surprise bill.

Sources: TTFB thresholds from Google's web.dev, "Time to First Byte (TTFB)", read October 2026. KeyCDN Performance Test: tools.keycdn.com/performance, read October 2026. Kinsta multi-location data: our own demo site, August 2026. Rocket.net's 70ms figure is the host's own claim.