Why TTFB Matters and How to Test It Before You Buy Hosting

TTFB, or Time To First Byte, is the interval between your browser sending a request and receiving the first byte of the response from the server. It is the single most direct measure of server performance you can get before you buy hosting, because it isolates the server's ability to process a request, run any application code, and start sending data back, ignoring network latency to the client. When you are comparing hosts, a low TTFB means the server is not the bottleneck; a high TTFB means no amount of front-end optimization will fix a slow origin.

What TTFB Actually Measures and Why It Matters When Choosing Hosting

TTFB is not a single thing. It is the sum of several steps that happen on the server side after the TCP connection is established. The server must accept the connection, parse the HTTP request headers, run any routing logic, execute the application (PHP, Python, Node, or a static file handler), and then write the first byte of the response headers back to the socket. For a dynamic site, the application execution time dominates. For a static site, TTFB is mostly the web server's file system access and kernel socket buffering. Why TTFB matters when choosing hosting is that it tells you how fast the server can think, not how fast the network can carry the data. A host with a great CDN but a slow origin will still show a high TTFB on a direct test, revealing the weakness.

The protocol details matter here. HTTP/1.1 and HTTP/2 both measure TTFB the same way: the time from request start to the first byte of the response. But HTTP/2 multiplexes streams, so a single connection can have multiple requests in flight. If you test TTFB over HTTP/2, you are measuring the server's ability to prioritize and serve a stream under concurrency, which is a different stress. For a simple comparison, use HTTP/1.1 with curl and force the protocol, because it gives a clean single-request measurement. You also want to test from a server close to the hosting data center, not from your local laptop, so you are measuring the server, not your last mile.

How to Test TTFB on a Candidate Host Before You Commit

You do not need a paid tool. The command line utility curl gives you a precise timing breakdown. Run this against a test URL on the host you are evaluating, ideally a small dynamic page that exercises the application stack, not just a static file. The key is to use the -w flag to print the timing variables, and -o /dev/null to discard the body so you only see the timing data.

curl -o /dev/null -s -w "connect: %{time_connect}\nTTFB: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/test.php

The output will look like this, with times in seconds. The time_starttransfer value is your TTFB. Run it at least ten times over a few minutes, because a single sample can be skewed by a cold cache or a transient load spike. Look at the median and the worst case, not the best. A host with a median TTFB under 200 milliseconds for a simple dynamic page is doing well. Above 500 milliseconds, you will feel the lag on every page load, and you should ask the provider why.

connect: 0.023
TTFB: 0.187
total: 0.412

For a deeper look, use curl -v to see the raw response headers. The Server header tells you the web server software, and X-Powered-By often reveals the application runtime. More importantly, look for a Cache-Control header on the response. If the host is serving a cached copy of a dynamic page, your TTFB will be artificially low, which is fine for real users but does not tell you about the raw server performance. To test the uncached path, add a query string with a random value, like ?test=12345, to force a miss, or test a URL that you know is not cached.

What to Do With the Numbers You Collect

Do not just test one URL. Test a few different types of pages: a static file, a simple database query, and a page with a login session or a heavy computation. The static file TTFB tells you about the web server and kernel. The database-driven page tells you about the database connection pool and query performance. The session page tells you about how the host handles state, which often involves Redis or a shared file system. Compare the TTFB across these. If the static file is fast but the database page is slow, the problem is the application or the database, not the network. If everything is slow, the host's CPU or disk I/O is the bottleneck.

Another useful test is to run the same request twice in a row. The second request should be faster because of opcode caching or a warm database connection. The difference between the first and second TTFB is a measure of how well the host's stack is tuned. A large gap means the first request pays a heavy cold-start cost, which will punish your users on every uncached visit. A small gap means the host has preloaded the application and connections, which is a good sign.

Finally, test at different times of day. A host that is fast at 3 a.m. but slow at 8 p.m. is oversubscribed, with too many tenants sharing the same CPU or disk. Run your test script every hour for a day, if you have the patience, and plot the TTFB. The variance is as important as the average. A host with a stable TTFB of 300 milliseconds is better than one that swings between 100 and 900 milliseconds, because the latter will cause erratic page load times for your visitors.

Configuring Your Own Server to Get a Low TTFB

If you are testing your own site before moving hosts, or you want to know what to look for in a host's control panel, the server configuration matters. The two biggest levers are the web server's keep-alive settings and the application's opcode cache. For nginx, the keepalive_timeout directive controls how long a connection stays open, and a value of 30 seconds is a reasonable default. For Apache, look at KeepAliveTimeout. If these are set too low, every request pays a new TCP handshake and TLS negotiation, which adds tens of milliseconds to TTFB.

# nginx snippet
keepalive_timeout 30s;
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MYAPP:100m inactive=60m;
server {
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_cache MYAPP;
        fastcgi_cache_valid 200 60m;
    }
}

The other major factor is the PHP-FPM pool configuration. The pm.max_children setting controls how many PHP processes can run concurrently. If it is too low, requests queue up and TTFB spikes. If it is too high, the server runs out of memory and swaps. A host that lets you tune these values, or that has already tuned them for you, is worth more than one that hides the settings. When you test a candidate host, ask for a read-only view of the PHP-FPM config or the nginx config. If they refuse, that is a signal that they do not want you to see how the stack is tuned.

What to Do Next

Run the curl test on your current hosting and on the top three candidate hosts you are considering. Do it from a cloud VM in the same region as each host, not from your office. Collect at least twenty samples per host, and write down the median and the standard deviation. If a host has a median TTFB above 400 milliseconds for a simple dynamic page, cross it off your list. If two hosts are close, pick the one with the lower variance and the more transparent server configuration. Then, before you sign up, send the host a support ticket asking for their recommended PHP-FPM and nginx settings for a site like yours. The speed of their answer, and whether it is specific, is a final test of how much they care about server performance.