Why Is My Site Slow? TTFB, Explained Without the Jargon

You've run your site through a speed test, stared at the waterfall chart, and come away with one clear feeling: it's slow, and you're not sure why. Before you start compressing images or stripping out JavaScript, look at one number first - because if this one is bad, nothing else you optimize will matter much.

That number is TTFB: time to first byte.

What TTFB actually measures

TTFB is the time between the browser asking for your page and the first byte of the response arriving. It's the "please wait" portion of your load time - before anything renders, before a single image downloads, the visitor is just... waiting.

That wait is really several smaller waits stacked up:

1. DNS lookup - turning yourdomain.com into an IP address.
2. Connection setup - the TCP handshake, plus the TLS handshake for HTTPS.
3. Server think time - your server actually building the response. For dynamic sites this means running code, hitting the database, and rendering a page.
4. The trip back - the first byte traveling across the network to the visitor.

Most of the time, when TTFB is bad, it's number 3. But not always, and the fix depends entirely on which one it is - which is why measuring comes first.

What counts as slow?

Rough bands that hold up well in practice:

TTFB	Verdict
Under 200 ms	Great - typical for cached pages on a CDN
200-500 ms	Fine for dynamic pages, not worth losing sleep over
500-800 ms	Noticeable - worth investigating
Over 800 ms	Slow - visitors feel this, and Google's own guidance flags it

One caveat: a single measurement from your own laptop is barely evidence. You're probably close to your server, on good wifi, with a warm cache. Your visitor on a phone two continents away is having a very different experience - more on that at the end.

Measure it in ten seconds

The quickest way is our free PageSpeed checker, which reports TTFB alongside the other Core Web Vitals from a neutral location.

If you like the terminal, curl will break the wait down into its parts:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s\n" https://yourdomain.com

Reading it is straightforward: if TTFB is high but the earlier numbers are small, your server is doing the waiting. If DNS or TLS are eating hundreds of milliseconds on their own, the connection itself is the problem.

The usual suspects, in order of likelihood

1. No page caching. The classic case: a CMS like WordPress rebuilding the same page from scratch, with a dozen database queries, for every single visitor. A page cache serves the already-built HTML instead, and routinely takes TTFB from over a second to double-digit milliseconds. If you fix only one thing on this list, make it this one.

2. No CDN, faraway visitors. Light travels fast, but round trips add up: a visitor in Sydney talking to a server in Virginia pays roughly 200 ms of latency before your server even starts thinking. A CDN answers from a location near the visitor, which shrinks both the connection setup and the delivery. If your audience is global and your server isn't, this is your biggest lever.

3. Slow backend work. Unindexed database queries, heavy plugins, external API calls made while building the page - all of it shows up as server think time. This is the "it got slower as we grew" category: queries that were instant with a thousand rows crawl with a million.

4. Underpowered or cold hosting. Cheap shared hosting under a noisy neighbor, or serverless functions that go to sleep and take a second to wake up (the infamous cold start). If your first hit of the morning is slow and the second is fast, this is a familiar signature.

5. Redirect chains. Every hop - http to https, bare domain to www, old URL to new - is a full extra round trip before the real request even begins. Two redirects can quietly double your effective TTFB. Our redirect checker shows the whole chain so you can collapse it to one hop or none.

Fixing it: the priority order

Work down this list and stop when your numbers look good:

1. Turn on page caching for anything that doesn't have to be generated per-visitor. This is the biggest win per hour of effort by a wide margin.
2. Put a CDN in front of the site and let it cache what it can. Even for uncachable pages, a CDN shortens the connection setup.
3. Collapse redirect chains so the browser lands on the final URL in one hop.
4. Profile the backend and fix the slowest queries - most frameworks have a debug bar or slow-query log that makes the culprits obvious.
5. Upgrade hosting if the server is simply out of breath. Sometimes the answer really is a bigger box, but it's cheaper to do it after the caching work, not instead of it.

The lab-vs-reality trap

Here's the part most people miss: every number so far came from a test machine. Real visitors bring their own geography, networks, and devices, and their TTFB is usually worse than yours - sometimes dramatically so, in exactly the regions or on exactly the pages you don't think to test.

That gap is what real user monitoring (RUM) exists to close. SiteTrak's RUM measures TTFB and the rest of the Core Web Vitals from your actual visitors' browsers, broken down by country and by page - so instead of guessing that "the site feels slow in Australia," you can see it, fix it, and watch the number come down.