Time to First Byte — the time between a browser requesting a page and receiving the first byte of the response — sets a hard floor under every other performance metric. If TTFB is 800ms, no amount of image compression or script deferral gets your Largest Contentful Paint under a couple of seconds, because the browser hasn't even started rendering yet.
TTFB gets ignored because it doesn't live in the front-end toolkit most teams reach for first. It's a server-side, infrastructure, and data-layer problem, and it requires profiling the backend rather than the browser.
What actually drives TTFB
- Server location relative to the visitor — a request crossing continents adds real, physical latency before anything else happens
- Uncached database queries running on every request, especially N+1 query patterns hiding in an ORM
- Server-side rendering that blocks on slow external API calls before returning any HTML
- Cold starts on serverless functions that aren't kept warm
A page that renders instantly in local development can still have a terrible TTFB in production, because local dev skips the network hop, the cold start, and the real database load that production traffic creates.
The fixes, roughly in order of leverage
Start with caching — a page or API response that doesn't need to be regenerated on every request shouldn't be. Then look at query patterns, since a single unoptimized query can dominate TTFB on an otherwise fast server. Then consider edge deployment or a CDN with server-side rendering support, which moves the response physically closer to the visitor.
If you've optimized every image and deferred every script and your LCP still won't move, TTFB is almost always the reason. Profile the server before spending another cycle on the front end.