Time to First Byte is the time from the browser starting a page request until the first byte of the response arrives. Google’s web.dev guide defines it as the sum of redirects, service worker start-up, DNS lookup, connection and TLS negotiation, and the request up to the first byte. Nothing on the page can render before that byte arrives.

Google’s web.dev guidance says a good TTFB is 0.8 seconds or less and a poor one is more than 1.8 seconds, with anything in between needing improvement, measured at the 75th percentile of visits. In HTTP Archive’s 2025 Web Almanac, 55% of desktop websites and 44% of mobile websites had a good TTFB.

TTFB is not one of the Core Web Vitals, and web.dev says it doesn’t strictly have to be in the good range. But TTFB is the first part of Largest Contentful Paint (LCP), which is a Core Web Vital, so a slow TTFB makes a good LCP harder to reach. Google says Core Web Vitals are used by its ranking systems.

Light travels through optical fiber at roughly 200,000 km a second, about 200 km per millisecond, so every 1,000 km of cable adds about 10 ms to a round trip. Real cable routes are longer than a straight line, and a new HTTPS connection needs several round trips before the first byte arrives. That is why New York to London can add over 300 ms even before the server does any work. The table above shows the numbers.

Yes, on new connections. A full TLS 1.2 handshake takes two round trips after the TCP handshake; TLS 1.3 takes one; HTTP/3 runs over QUIC, which combines the transport and TLS handshakes into a single round trip. Fewer round trips matter most when the visitor is far from the server.

On a cache hit, the CDN edge near the visitor already has the page and answers immediately, so both the long-distance round trips and the server processing disappear from TTFB. On a miss, the edge has to fetch the page from your origin server, so you still pay for the trip to the origin and the server’s processing time. Logged-in, cart and other personalized pages are usually misses.

From Deloitte’s “Milliseconds Make Millions” study for Google, which tracked 37 retail, travel, luxury and lead-generation brand sites and over 30 million user sessions over 30 days at the end of 2019. A 0.1-second improvement in mobile site speed, measured across four metrics including Time to First Byte, was linked to 8.4% higher conversion rates for retail sites and 10.1% for travel sites. The study looked at 0.1-second changes, so the simulator shows a low estimate (first 100 ms only) and a high one (every 100 ms counted equally). Your own A/B test data will always be more accurate.

In Chrome DevTools, open the Network tab, select the page request and look at the Timing tab’s “Waiting for server response” value, adding the connection steps above it for a first visit. WebPageTest shows the full breakdown from different locations. PageSpeed Insights shows TTFB from real Chrome users (field data) when your site has enough traffic.