A page can have beautifully optimised images and lean JavaScript and still feel slow to start — because the very first step, getting any response at all from the server, is sluggish. That first step has a name: TTFB, and it's often the most overlooked number in web performance.
If your site "takes a moment before anything happens," TTFB is where to look. Here's what it is and how to fix it.
What TTFB measures
Time to First Byte (TTFB) is the time from when a browser makes a request to when it receives the first byte of the response. It captures everything that has to happen before your content can even start arriving.
A request's early life looks like this:
DNS lookup → Connect → TLS handshake → [server thinks] → first byte → download
└────────────────── TTFB ──────────────────────────┘
TTFB covers the network setup and — crucially — how long your server took to start responding. That last part is why TTFB is such a good proxy for backend health: a high TTFB usually means a slow server, not a slow network.
What's a good TTFB?
As a rough guide:
| TTFB | Verdict |
|---|---|
| Under 200ms | Excellent |
| 200–500ms | Good |
| 500ms–1s | Needs work |
| Over 1s | Slow — users feel it |
Google considers around 800ms a reasonable upper target for good experiences, with under 200ms being the goal for the server-think portion.
What makes TTFB bad
| Cause | What's slow |
|---|---|
| Slow server / app code | The backend takes too long to generate the response |
| Slow database queries | The page waits on the DB before it can reply |
| No caching | Every request is rebuilt from scratch |
| Distance to the server | Far-away users pay extra network time |
| Cold starts | Serverless/containers spinning up on demand |
| Overload | Requests queueing under heavy traffic |
How to improve it
The fixes fall into two buckets — make the server faster, and put it closer:
- Cache aggressively. Serving a cached page skips the expensive "server thinks" step entirely. This is usually the biggest single win.
- Use a CDN. It both shortens the network distance and serves cached content from the edge — slashing TTFB for far-away users.
- Speed up the backend. Optimise slow database queries (the usual culprit), reduce work done per request, profile the hot paths.
- Keep things warm. Avoid cold starts where they hurt; keep connections and instances ready.
- Move closer to users. Edge rendering or regional deployments cut the distance.
TTFB vs LCP — don't confuse them
TTFB is part of the bigger picture, not the whole thing:
- TTFB = when the first byte arrives (server responsiveness).
- LCP = when the largest content is visible (the whole load experience).
A bad TTFB drags down LCP and everything after it — you can't render fast if the server hasn't even started replying. So TTFB is the foundation: fix it first, and the rest of your performance work has something solid to build on.
The bottom line
| In one line | |
|---|---|
| What | Time until the first byte of the response arrives. |
| Why it matters | A great proxy for backend speed; the base of LCP. |
| Good | Under ~200ms for the server portion; under 800ms overall. |
| Improve | Cache, use a CDN, speed up the backend, stay warm. |
TTFB is the unglamorous number that quietly gates everything else. Get it low — mostly through caching and a CDN — and your whole site feels faster to start, which is the moment users decide whether to stay.
Measure it as part of Core Web Vitals, check any page with the free Core Web Vitals checker, and track it over time with performance monitoring.