Time to First Byte (TTFB)
Time to First Byte measures how long it takes for the browser to receive the first byte of the response after requesting a page. It is the foundation of loading speed, because nothing else on the page can start until that first byte arrives.
Time to First Byte, or TTFB, measures the gap between the browser asking for your page and the server starting to answer. It covers the network trip out, the server doing its work, and the first byte coming back. TTFB is not a Core Web Vital itself, but it is the foundation underneath all of them. A slow TTFB poisons everything downstream, because the browser cannot render a single pixel until that first byte shows up. Everything you do to speed up a page sits on top of this number, and if it is high, the rest of your effort is capped before it starts. That is the part people miss when they jump straight to optimizing images and scripts.
Why TTFB matters even though it is not a ranking metric
Your LCP can never be faster than your TTFB plus the time it takes to render the largest element. If the server takes a second and a half to respond, you have already lost the LCP race before the browser has done anything. Fixing TTFB is the prerequisite for fixing loading performance, not an optional extra. I have seen teams spend weeks optimizing images and trimming scripts while a slow server quietly held the whole page hostage, and none of that downstream work could ever pay off until the server got out of the way first. So when a page is slow, the very first thing I check is whether the server is responding quickly. If it is not, nothing else is worth doing yet.
TTFB is the floor for every speed metric you care about. You cannot render fast on top of a slow server response.
A slow TTFB usually comes from one of a few places: a slow or overloaded host, heavy server-side work like a database-hungry CMS rebuilding every page on the fly, no caching so the server regenerates the same page for every visitor, or a visitor physically far from your server with no CDN to shorten the trip. The good news is that the two most common causes have the two easiest fixes. Caching turns an expensive page build into serving a ready-made file, and a CDN shortens the physical distance between your server and the visitor. The table below pairs each cause with the fix I reach for first.
| Cause | Fix |
|---|---|
| No page caching | Add full-page caching so the server serves a ready file |
| Distant users, single origin | Put a CDN in front to serve from edge locations |
| Slow shared hosting | Move to a faster host or a managed platform |
| Expensive dynamic rendering | Cache database queries or pre-render static pages |
warningWATCH OUT
Do not pour effort into front-end tweaks while your server responds slowly. If TTFB is bad, fix the server first. Everything else is rearranging furniture in a house with no foundation.
- 1Measure TTFB in PageSpeed Insights, WebPageTest, or your browser's network tab on a cold load.
- 2Add or verify full-page caching so repeat requests skip the heavy server work.
- 3Put a CDN in front of the site, then re-measure from a few different locations.
Cache, then CDN
The two highest-leverage TTFB fixes are full-page caching and a CDN. Get those right and most sites see TTFB drop dramatically without touching application code.
targetThe honest take
On WordPress and other database-driven CMS platforms, TTFB problems are usually a hosting and caching problem dressed up as a code problem. Before you blame a plugin, confirm caching is on and the host is not the bottleneck. TTFB is where loading speed begins, so fix it before chasing LCP. See how server response feeds into the bigger picture in my Core Web Vitals playbook.
Want this handled by someone who has measured search for 20 years?
Work with me