What Is Time to First Byte?
Time to First Byte (TTFB) is the time between the browser starting a request for a page and receiving the first byte of the server's response. It covers redirects, DNS lookup, connection and TLS setup, and the time the server spends producing the response, and Google's web.dev guidance treats 0.8 seconds or less as a good TTFB for most sites.
What Is Time to First Byte?
TTFB measures how responsive a server, and the network path to it, is. Nothing can appear on screen until the first bytes of HTML arrive, so a slow TTFB delays every later milestone, including First Contentful Paint and Largest Contentful Paint. It is not one of the Core Web Vitals itself, but it is a foundational metric that Google recommends monitoring because it sets a floor for them. web.dev's thresholds, measured at the 75th percentile of real page loads, are: good at 0.8 seconds or less, needs improvement between 0.8 and 1.8 seconds, and poor above 1.8 seconds. Lighthouse applies a stricter lab check: its "Reduce initial server response time" audit flags documents whose server response takes longer than 600 milliseconds. TTFB can be measured for any resource, but it is usually quoted for the main HTML document.
How Time to First Byte Works
For a page navigation, TTFB is the sum of several phases. If the URL redirects, each redirect adds a full round trip before the real request starts. If the site uses a service worker, it must start up. The browser then resolves the domain name through DNS, opens a TCP connection (or a QUIC connection for HTTP/3) and negotiates TLS for HTTPS, and each of these steps costs round trips that grow with the physical distance to the server. The request is then sent, and the server has to produce the response: a static file can be returned almost instantly, while a dynamic page may run application code, query a database and render a template first. Finally the first byte travels back over the network. In Chrome DevTools, the Timing tab for a request in the Network panel breaks this down and labels the server's part "Waiting for server response". In JavaScript, performance.getEntriesByType('navigation')[0].responseStart gives the TTFB for the current page, and the web-vitals library reports it with its onTTFB() function. Field data from real users appears in the Chrome UX Report and in PageSpeed Insights, while curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/ gives a quick command-line measurement from one location.
Best Practices for Time to First Byte
Serve as much as possible from cache. Pages that are the same for every visitor can be generated once and served as static HTML, or cached at a CDN edge close to the visitor, which removes both the server work and most of the network distance. For dynamic sites, add full-page caching, object caching for database results and an opcode cache where the language supports one, and profile slow endpoints; the Server-Timing response header can expose how long the database, templating and other steps take, and DevTools displays it. Remove unnecessary redirects, especially chains such as http:// to https:// to https://www., and make sure internal links point straight at the final URL. Use a DNS provider with fast, globally distributed resolution, enable HTTP/2 or HTTP/3 and TLS 1.3 to cut handshake round trips, and host close to your main audience if you are not using a CDN. Where your platform supports it, 103 Early Hints lets the browser start fetching critical CSS and fonts while the server is still preparing the page. Avoid slow work before the response starts, such as waiting on third-party APIs, and stream the HTML when you can so the head reaches the browser early. Finally, measure with field data from real users in different regions, since a fast result from your own office says little about visitors on mobile networks on the other side of the world.
Time to First Byte and Canvas Builder
Canvas Builder exports sites as static HTML, CSS and JavaScript files, which are among the fastest content a server can deliver because no database query or server-side rendering has to happen before the first byte. To keep TTFB low, host the exported files on a fast static host or behind a CDN, and avoid redirect chains when you connect your domain.
Start building freeFrequently asked questions
What is a good TTFB?
Google's web.dev guidance suggests aiming for a TTFB of 0.8 seconds or less at the 75th percentile of real page loads. Between 0.8 and 1.8 seconds needs improvement, and more than 1.8 seconds is poor. Static sites served from a CDN are often much faster than that.
Is TTFB a Core Web Vital?
No. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. TTFB is a supporting metric that Google recommends tracking, because a slow server response delays every other loading milestone, including LCP.
What causes a high TTFB?
Common causes are slow server-side code or database queries, no page caching, an overloaded or underpowered server, a server far from the visitor with no CDN, redirect chains, and slow DNS or TLS setup. Measuring where the time goes, with DevTools or the Server-Timing header, shows which of these to fix first.
How do I measure TTFB?
PageSpeed Insights shows TTFB from real Chrome users when enough data is available, and Chrome DevTools shows it for each request in the Network panel's Timing tab. WebPageTest can test from different locations, and the web-vitals JavaScript library can report it from your own visitors.