TTFB: the number that determines whether Google can rank your site

Most teams treat TTFB like a backend detail and start with images, fonts, or JavaScript. That is backwards because TTFB, short for Time to First Byte, is the wait before the first byte of the HTML response arrives, and nothing on the page can start rendering before that according to web.dev.

That same guidance is also where Google's rough thresholds come from: good is 800 ms or less, poor is above 1,800 ms. If your first byte is already late, every other optimization starts from behind.

TTFB is not a Core Web Vital by itself, but it sits directly inside LCP. The 2024 Web Almanac found that sites with poor LCP spend 2.27 seconds on TTFB alone, which nearly burns the entire 2.5 second LCP budget before the browser has even started rendering the main content.

That matters for search because LCP is one of the page experience signals Google uses, and TTFB sits directly in front of it. If your first byte is slow enough to push LCP out of range for real users, the rest of your front-end work never gets a fair chance to help.

TTFB is partly code and partly distance. A fast server in one city still has to wait for the network round trip to users somewhere else, so the same page can feel quick nearby and noticeably slower across an ocean.

LatencyRadar's March 2026 Cloudflare benchmark shows that clearly: TTFB was 355 ms from Amsterdam, 412 ms from San Francisco, 473 ms from Montreal, and 571 ms from Singapore. Same site, same test, different geography. That is why checking TTFB from your own laptop tells you almost nothing about what users in other regions are experiencing.

If your TTFB is over 800 ms for any important audience, start with hosting and delivery before you start rewriting application code. A single-region origin that is far from users is usually a bigger problem than a slightly inefficient route handler.

The opportunity is large because the web is still bad at this. The 2025 Web Almanac says only 44% of mobile pages have good TTFB, up only slightly from the previous year. That matters because real users on slower networks are still what decides whether your page feels fast enough in practice.

In practice, the fix is usually moving content closer to users with an edge platform or a CDN in front of your origin, then measuring again from a few cities. TTFB is often an infrastructure problem long before it is a code problem.