Performance Reference
TTFB is four separate waits added together
A speed tool told you your TTFB is bad and gave you no idea which part of it to fix.
The short answer
Time to first byte is everything that happens between the request leaving the browser and the first byte of the response arriving — and it is four distinct waits stacked on top of each other, not one.
Those four are the DNS lookup, the TCP connection, the TLS handshake and the server's own thinking time. Optimising TTFB without splitting them is guesswork, because three of them are usually fine and one of them is your entire problem.
By the HostingFast team · Reviewed 12 August 2026
100+
Definitions on file
2 min
Typical time on one
Plain
English, no marketing
24/7
Engineers on the desk
curl will report all four for you in a single request: name lookup, connect, TLS complete, start of transfer. Subtract each from the next and you have the four waits separately. That takes about thirty seconds and replaces every generic recommendation you were about to follow.
Cache state dominates all of it. Serve the page from cache and the server's thinking time collapses to near nothing, leaving distance and handshake as the whole number. That is why the first question about any TTFB figure is not how big it is but whether the response was cached.
Four waits, one number
DNS lookup happens once per hostname and is usually cached at the resolver. Connection setup is a round trip, so it is distance. The TLS handshake is another round trip, less on a resumed session. Server thinking time is everything else: PHP, the database, external calls, and whatever your slowest plugin is doing.
Only the last of those is really about your hosting and your code. The first three are physics and configuration, and they set a floor you cannot get under from wherever you are testing.
The command that splits them
Ask curl for its timing variables on a single request and read them in order. The gap from connect to TLS complete is your handshake. The gap from TLS complete to start of transfer is the server thinking. If that last gap is the large one, the problem is on the server and nothing you do to DNS or certificates will help.
Run it twice: once against a page you expect to be cached, once against something that cannot be, such as a logged-in view. The difference between those two runs is the most useful number on this page.
Targets worth holding
A cached page delivered to a nearby visitor should come in comfortably under about 200 ms. An uncached dynamic page on healthy hosting belongs somewhere in the 200 to 500 ms range. A figure approaching a full second is telling you something specific: a caching gap, a slow plugin or an external call the page is waiting on.
Distance sets the floor. From the UK and Ireland the round trip to our London origin is indicatively 5 to 15 ms; from Australia and New Zealand it is 250 to 290 ms, and no amount of server tuning will remove that from your measurement.
Fix in order of payoff
Page caching first, because it removes the computation instead of speeding it up. Then PHP 8.x with OPcache, which makes the remaining computation cheaper. Then Redis and NVMe, which shorten the reach for data. Then the slow plugins and the external HTTP calls. Note what is not on that list: your image sizes, which matter enormously for the rest of the page and not at all for this number.
Neighbouring entries: Cache, Core Web Vitals, NVMe and LiteSpeed.
One command, four answers
The measurement culture in this reference is simple: name the tool, name the number, and name what counts as good before you change anything.
LiteSpeed caching in the server and NVMe storage on every tier, so the floor under your own measurements is already low.
- Tool and command in the text
- Targets given as ranges, not adjectives
- Distance separated from server time
- Written by the engineers on support
Why HostingFast
Standard on every plan
Four waits, separated
DNS, connect, handshake and server thinking are four different problems wearing one number.
One curl request
Thirty seconds of timing output replaces a page of generic recommendations.
Cache state first
Whether the response was cached matters more than the figure itself, every time.
Ranges you can aim at
Under about 200 ms cached and nearby, 200 to 500 ms uncached on healthy hosting.
Distance quantified
Indicative round trips to the London origin, so you know what your test location is adding.
Fixes ranked by payoff
Caching, then OPcache and PHP 8.x, then Redis and NVMe, then the slow plugin. In that order.
Quick Start
From order to online
- 1
Split the number
Take curl's timing breakdown on one request and separate the four waits. The large gap names your problem in seconds.
- 2
Test cached and uncached
Run it once on a page that should hit the cache and once on something logged in. The gap between them is the most useful figure you will collect.
- 3
Subtract the distance
Note the round trip from your test location before judging the server. From the far side of the world, a quarter of a second of it is not yours to fix.
Built In
Loaded onto every plan
- LiteSpeed caching built into the server rather than patched in by plugin
- Staging environments for testing changes before they ship
- DDoS filtering absorbed out at the network edge
- Free SSL on every plan, renewed automatically before it can expire
- cPanel — the control panel most of the industry already runs
- WordPress Toolkit, with updates handled for you
- Softaculous on board for one-click application installs
- 99.9% uptime as the target, monitored around the clock
- In-place account upgrades — no migration when you change plan
- Year one of your domain free when you order annually
Frequently Asked
What people ask us most often
Which part of TTFB does hosting actually own?
The server thinking time, plus whatever the origin's location contributes to the two round trips. DNS resolution belongs to your DNS provider and is usually cached anyway. The handshake is largely protocol and certificate configuration. If you split the four waits and the server gap is small, your host is not your problem however unimpressive the total looks.
Why does my TTFB change every time I test it?
Cache state, mostly. A first request after a purge builds the page; the next one is served from cache and can be several times quicker. Then add resolver caching on DNS, session resumption on TLS, and the varying route from wherever the testing tool ran. Test the same page from the same place in a known cache state, or you are comparing four things at once.
Does a lower TTFB always mean a faster page?
No. It is the floor, not the finish. Rendering cannot start before the first byte arrives, so a slow TTFB caps everything downstream — but a fast first byte followed by three megabytes of unoptimised images still gives a visitor a slow page. Fix the first byte to remove the ceiling, then go and look at what the page weighs.
Where is the origin, and how much does distance add?
London, with redundant power, cooling and multiple upstream carriers. Indicative round trips run 5 to 15 ms from the UK and Ireland, 10 to 35 ms from Western and Northern Europe, 130 to 150 ms from the US West Coast, and 250 to 290 ms from Australia and New Zealand. Those figures are the floor under any measurement you take from those places.
Keep reading
Cache
Five layers between database and visitor, and the header that says which one answered.
NVMe
Flash over PCIe with deep parallel queues, and why sequential throughput is the wrong number.
Best Ecommerce Hosting for First Stores
The buyer's version for a first store: what to verify and what to ignore entirely.
WordPress Hosting
Managed WordPress on LiteSpeed, with staging copies and daily backups included.
Web Hosting
cPanel hosting on NVMe with SSL, migration and a first-year domain included.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Lower the floor under every page.
LiteSpeed caching in the server, NVMe on every tier, a London origin and support that reads a trace with you.
View WordPress Hosting plans