--- title: "What Is TTFB? Time to First Byte Explained | Evaluat" description: "What TTFB is, what a good Time to First Byte looks like, how to measure it, why a CDN can hide a slow server, and why TTFB climbs first when a site is busy." url: "https://www.evaluat.com/blog/time-to-first-byte" last_modified: "2026-10-08" --- [Blog](https://www.evaluat.com/blog) [Web Vitals & Metrics](https://www.evaluat.com/blog/category/web-vitals-metrics) # Time to First Byte (TTFB), explained Time to First Byte (TTFB) is how long a browser waits between starting to load a page and receiving the first byte of the reply. Good is 0.8 seconds or less. It is not a Core Web Vital, but it is the first slice of every page load and the number that moves first when your server starts to queue. Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 8 October 2026 [Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 12How a web page loads ![Time to first byte for the same page on a quiet afternoon and on sale day, drawn as stacked bars against Google's thresholds of 0.8 seconds for good and 1.8 seconds for poor. Network travel takes 435 milliseconds both times. Server time is 200 milliseconds when quiet, giving a good TTFB of 635 milliseconds, and 1,400 milliseconds when requests queue, giving a poor TTFB of 1,835 milliseconds.](https://www.evaluat.com/blog/time-to-first-byte-cover.svg) Summary Time to first byte, or TTFB, measures how long a browser waits from the moment it starts loading a page until the first byte of the server's reply arrives. It includes any redirects, the address lookup, setting up a secure connection, and the time your server spends building the page. Google's guidance is that 0.8 seconds or less is good and more than 1.8 seconds is poor. TTFB is not one of the Core Web Vitals, but it comes before all of them, so a slow first byte makes a fast Largest Contentful Paint almost impossible. A content delivery network can hide a slow server on pages it caches, which is why a homepage often looks fine. The basket, checkout, search and account pages are rarely cached, so they show the server's real speed. TTFB is also the number that moves first when a site gets busy. When more requests arrive than a server can handle, they queue, and the time spent waiting in that queue lands inside time to first byte. A page with a good TTFB on a quiet afternoon can cross into poor during a sale without any code changing. To improve it, cache what you can, remove redirects, find the slow work on the server, and measure the uncached pages while the site is under load. Listen to this article · 1:28 [Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/time-to-first-byte.mp3) Key takeaways - TTFB runs from the start of navigation to the first byte of the reply, including redirects and connection setup. - Good TTFB is 0.8 seconds or less; poor is more than 1.8 seconds. - TTFB is not a Core Web Vital, but a slow one makes a good LCP close to impossible. - A CDN hides a slow server on cached pages; basket, checkout and account pages expose it. - TTFB climbs first under load, because time spent queuing for the server lands inside it. - Measure TTFB on uncached pages, with traffic running, before you trust it. ## What is Time to First Byte (TTFB)? Time to First Byte (TTFB) is the time between a browser starting to load a page and the first byte of the response arriving. Google’s definition is [the time between starting navigating to a page and when the first byte of a response begins to arrive](https://web.dev/articles/ttfb). It is measured in milliseconds and reported for the page’s main document. TTFB is not just server time. Google lists the phases it adds together: redirect time, service worker startup if the site uses one, the DNS lookup, connection and TLS negotiation, and the request itself, up to the moment the first byte arrives. [Part 8 of this guide](https://www.evaluat.com/blog/how-a-web-page-loads) walked through those waits in order. A restaurant is a fair picture. TTFB is the time from walking through the door to the first plate landing on your table. It includes being shown to a seat and placing the order, not just the time the kitchen spends cooking. A slow first plate might mean a slow kitchen, or a long walk to the table, or both. That mix is the most important thing to understand about the metric. TTFB combines network travel, which depends on the visitor, with server work, which depends on you. Reading it well means separating the two. ## What is a good TTFB? Google’s guidance is that [a good TTFB is 0.8 seconds or less, and a poor one is greater than 1.8 seconds](https://web.dev/articles/ttfb), measured at the 75th percentile of page loads. Anything in between needs improvement. These are deliberately loose: Google calls them a rough guide, to be weighed against how your site delivers its main content. | TTFB at the 75th percentile | Rating | | -------------------------------- | ----------------- | | 0.8 seconds (800 ms) or less | Good | | 0.8 to 1.8 seconds | Needs improvement | | More than 1.8 seconds (1,800 ms) | Poor | The thresholds are loose because TTFB is not a Core Web Vital. Google says that [because TTFB isn’t a Core Web Vitals metric, it is not absolutely necessary that sites meet the good threshold, provided that it doesn’t stop them scoring well on the metrics that matter](https://web.dev/articles/ttfb). A page rendered on the server can have a higher TTFB and still show content sooner than a page assembled in the browser. You will see other numbers quoted. Chrome’s Lighthouse audit recommends 600 ms, and Chrome explains the difference: [the TTFB guidance (800 ms) is longer than the server response time it recommends (600 ms) because TTFB also includes the DNS lookup and redirects](https://developer.chrome.com/docs/performance/insights/document-latency). Many hosting articles still quote 200 ms, which echoes older PageSpeed advice on server response time rather than Google’s current TTFB thresholds. How common is good? The HTTP Archive’s 2025 Web Almanac found that [44% of mobile websites have good TTFB, 40% need improvement and 17% perform poorly](https://almanac.httparchive.org/en/2025/performance). On desktop, 55% are good. ## Why does TTFB matter if it is not a Core Web Vital? Because it comes first. Nothing on the page can appear before the first byte arrives, so TTFB is the opening slice of every loading metric, including Largest Contentful Paint (LCP), the Core Web Vital that measures when the main content shows. A slow TTFB leaves less of the 2.5-second LCP budget for everything else. Google’s Chrome team measured how much. In an analysis of real-user data, it found that among origins with good LCP, the median 75th-percentile TTFB was 600 ms, while [for at least half of the origins with poor LCP, the p75 TTFB of 2,270 milliseconds alone nearly guarantees that LCP can’t be faster than the 2.5-second good threshold](https://web.dev/blog/common-misconceptions-lcp). A server that slow uses most of the budget before the browser has anything to work with. The reverse is not true. A good TTFB does not promise a good LCP, because the page can still lose time discovering, downloading and rendering its main image or text. [Our guide to Largest Contentful Paint](https://www.evaluat.com/blog/largest-contentful-paint) covers the rest of that journey. But a poor TTFB is close to a guarantee of a poor LCP. There is also a search consequence that is easy to miss. Google’s documentation on crawling large sites says the crawl capacity limit [goes up if the site responds consistently and its response times, including latency and time to first byte, remain stable or improve](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget). A slow, inconsistent server gets crawled less. ## What makes up TTFB? TTFB is a sum of phases, and each has a different owner. The first few depend mostly on the visitor’s network and the distance to your server; the last depends mostly on your server. When TTFB is high, the useful question is which phase grew. | Phase | What happens | Mostly depends on | | ----------------------- | ------------------------------------------------------------------------ | -------------------------------- | | Redirects | The browser follows any redirects before the real page | Your links and site setup | | Service worker startup | A service worker, if the site has one, starts up | Your code | | DNS lookup | The browser finds the server’s address | The visitor’s resolver and cache | | Connection and TLS | A secure connection is opened | Round-trip time to the server | | Request and server time | The request travels, the server builds the reply, the first byte returns | Your server, plus one round trip | Here is a worked example for a new visitor on a phone, using the 145 ms mobile round trip from part 8. The address is already cached. Opening the connection takes one round trip, securing it takes another, and the request and its reply a third: 435 ms of travel. If the server takes 200 ms to build the page, the first byte arrives after about 635 ms. That is good. Add one redirect that sends the visitor to a different host, such as from the bare domain to the www address, and the browser pays for another connection and request, several more round trips. The same page can drift past 0.8 seconds before the server has done anything slower. The network side of this is the subject of [part 10, on latency and round trips](https://www.evaluat.com/blog/latency-vs-bandwidth). The server side is where the rest of this article goes. ## How do you measure TTFB? Measure it in two places: in a lab, where you control the conditions and can see the phases, and in the field, where real visitors tell you what they actually got. Each catches problems the other misses, so check both before deciding where the time goes. **In the browser.** Open Chrome DevTools, go to the Network panel, reload, and select the first request, which is the page itself. The Timing tab breaks the request into phases. Chrome’s documentation describes the waiting phase as one where [the browser is waiting for the first byte of a response, and this timing includes one round trip of latency and the time the server took to prepare the response](https://developer.chrome.com/docs/devtools/network/reference). Note that this phase alone is shorter than full TTFB, which also includes the connection setup listed above it. **From the command line.** curl can print the same number. Its `time_starttransfer` value is [the time from the start until the first byte was received, including the time the server needed to calculate the result](https://github.com/curl/curl/blob/master/docs/cmdline-opts/write-out.md). Run `curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/` against your own page, several times. **From real visitors.** PageSpeed Insights shows field TTFB from the Chrome User Experience Report for sites with enough traffic, at the 75th percentile. Evaluat’s free [website speed test](https://www.evaluat.com/tools/website-speed-test) loads a public URL once in a real browser and reports TTFB alongside LCP, CLS and FCP, which is a quick lab reading. **From the server.** A `Server-Timing` response header lets your server report how long its own work took, as in [Google’s example](https://web.dev/articles/optimize-ttfb) `Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2`. Browsers show it in DevTools, which turns “the server is slow” into “this query is slow”. ## Can a CDN hide a slow TTFB? Yes, on the pages it caches. A content delivery network answers cached pages from a server near the visitor without asking your origin at all, so TTFB looks excellent however slow your server is. Pages that cannot be cached, such as the basket and checkout, still wait on your origin. Google warns about this directly: caching [can mask a slow backend, making long TTFBs harder to diagnose, since testing a cached page often shows no TTFB issues](https://web.dev/articles/optimize-ttfb). It recommends building a way to skip the CDN, such as a URL parameter, so you can measure the origin. The pages that make money are usually the ones a CDN cannot help with: - **HTML is often not cached at all.** Cloudflare, for example, [does not cache HTML or JSON by default](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/), and skips caching when a response sets a cookie. - **Checkout and basket pages are uncacheable by design.** Adobe Commerce documents that [by default all pages are cacheable except the checkout pages](https://developer.adobe.com/commerce/frontend-core/guide/caching), and names compare, cart and checkout pages as ones that should not be cached. - **Tracking parameters can break caching on pages that should be cached.** RUMvision found product pages reached through a Google Merchant Center parameter missed the cache, comparing [a 1,417 ms TTFB with the 302 ms that a proper caching strategy could have achieved](https://www.rumvision.com/blog/srsltid-impacting-core-web-vitals-via-ttfb-caching/). So test the homepage and you may be testing your CDN. Test the basket with an item in it and you are testing your server. ## Why does TTFB rise when a site is busy? Because requests start to queue. A server can only work on so many requests at once; when more arrive, the extras wait for a free worker, and that waiting time lands inside time to first byte. Network phases barely change with your traffic, so the server part of TTFB is where load shows first. Google’s Site Reliability Engineering book gives the arithmetic. If a request takes 100 milliseconds of work and the queue in front of each worker can hold ten requests, then [when the queue is full a request takes 1.1 seconds to handle, most of it spent in the queue](https://sre.google/sre-book/addressing-cascading-failures/). The work did not get slower. The wait got longer. Queues also grow faster than intuition suggests. Marc Brooker, an engineer at Amazon Web Services, shows with a simple queueing model that [at about half utilisation there is on average one request in the system, and at 99% there are 99](https://brooker.co.za/blog/2021/08/05/utilization.html). He describes high-percentile latency as a good leading indicator of pending overload. Put that next to the worked example above. On a quiet afternoon the server takes 200 ms and the visitor’s TTFB is about 635 ms, which is good. On sale day the same server, now queuing, takes 1.4 seconds, and TTFB becomes about 1.84 seconds, past the 1.8-second line into poor. No code changed. That is why TTFB should be measured on uncached pages while the site is under realistic load, not only when it is idle. ## How do you improve TTFB? Work from the phase that grew. Network phases improve with fewer redirects and shorter distances; server time improves with caching and with finding the slow work. Most sites get the biggest gains from caching more pages and from fixing a handful of slow queries on the pages that cannot be cached. - **Cache what is the same for everyone.** Category and product pages can often be served from a full-page cache or a CDN. Make sure tracking parameters are ignored in the cache key so they do not split the cache. - **Remove redirects.** Link to final addresses, especially in ads and emails, and avoid chains. - **Serve from close to your visitors.** A CDN shortens the connection phases even for pages it cannot cache. - **Find the slow work.** Add `Server-Timing` and profile the uncached pages: basket, checkout, search and account. Slow database queries and calls to other services are the usual culprits. - **Plan capacity for the peak.** If TTFB is fine when quiet and poor under load, the fix is capacity or efficiency on the server, and only a test at realistic load shows how much is needed. One caution when you see TTFB fall suddenly. Responses that send 103 Early Hints can make TTFB look faster, and Google notes that [like caching, they can mask the real TTFB of a site](https://web.dev/articles/optimize-ttfb). Check the server time separately before celebrating. ## Common mistakes with TTFB Most TTFB mistakes come from measuring the wrong page or the wrong moment. - **Testing only the homepage.** It is usually the most cached page on the site. Test the basket and checkout too. - **Reading TTFB as server time.** It includes redirects, DNS and connection setup. Split it before blaming the back end. - **Chasing an old threshold.** Use Google’s 0.8 and 1.8 seconds as the guide; 200 ms targets are older advice, not the current guidance. - **Trusting a lab number over field data.** Real visitors arrive through redirects, on slower networks and logged in. - **Measuring only a quiet site.** TTFB is the metric most likely to change when traffic arrives. ## How Evaluat measures TTFB under load Evaluat runs each virtual user in an isolated real browser, so it records TTFB the way a customer’s browser does, split into its Navigation Timing phases: DNS lookup, connection, TLS negotiation and time to first byte, per URL and at any percentile from p50 to p99. Web Vitals captured at load. Per session. Per URL. That lets you see the pattern this article describes. As virtual users ramp up, connection times stay flat on every page, cached product pages stay fast, and TTFB on the basket and checkout pages climbs. You can then open a session from the slow period and see, in its network log, how long the page waited for its first byte, and what it did next. The boundary is worth stating. Evaluat shows what its browsers saw under the test conditions you chose, from the region closest to your customers. It does not replace field data from your real visitors or the server-side profiling that explains why a query is slow. It tells you which pages slow down, at what load, and by how much. TTFB, then, is the first number in every page load and the first to move when your server is under pressure. Know which of your pages are cached, measure the ones that are not, and measure them again with traffic running. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to see your own uncached pages measured under load. [Previous · Part 11What is a code freeze, and should you have one before peak?](https://www.evaluat.com/blog/black-friday-code-freeze) [Next partNew parts every Wednesday and Thursday. See the guide index.](https://www.evaluat.com/blog/beginners-guide) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan) Common questions ## FAQ ### What is TTFB? TTFB, or time to first byte, is the time between a browser starting to navigate to a page and the first byte of the response arriving. It includes redirects, the DNS lookup, connection and TLS setup, and the server's time to start answering. It is measured in milliseconds. ### What is a good TTFB? Google's guidance is that a TTFB of 0.8 seconds or less is good and more than 1.8 seconds is poor, measured at the 75th percentile of page loads. Google calls these thresholds a rough guide, because a server-rendered page can have a higher TTFB and still show its content sooner than a page built in the browser. ### 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 diagnostic metric that sits underneath them, and because it comes first in every page load, a slow TTFB delays Largest Contentful Paint. ### Does TTFB affect SEO? Not as a Core Web Vital, but it does affect how Google crawls a site. Google's crawl documentation says the crawl capacity limit goes up when response times, including latency and time to first byte, stay stable or improve, and goes down when the site slows. It also feeds Largest Contentful Paint, which is a Core Web Vital. ### What is the difference between TTFB and server response time? Server response time is only the time the server takes to start answering. TTFB also includes redirects, the DNS lookup and connection setup. That is why Chrome's Lighthouse recommends 600 ms for server response time while the TTFB guidance is 800 ms. ### Does TTFB include redirects? Yes. Google's definition counts redirect time as the first phase of TTFB, so every redirect before the final page adds its full cost. A link that bounces from one address to another before reaching the page can add hundreds of milliseconds on a mobile connection. ### Why is TTFB different in Lighthouse and in field data? Lab tests usually load one page on a fast connection, often from a warm cache. Real visitors arrive through redirects from ads, on slower networks, logged in, or with tracking parameters that bypass the cache. Compare the two, but trust field data for what customers experience. ### Why is my TTFB high? The usual causes are a page that is not cached, slow work on the server such as database queries, a server far from the visitor, redirects, or a server that is busy and queuing requests. Splitting TTFB into its phases, and adding a Server-Timing header on the server, shows which one it is. Related reading ## More from the blog [![A page load drawn as a waterfall of seven waits in order: DNS lookup, TCP connection, TLS handshake, the server thinking until the first byte, the HTML download, fetching CSS, scripts and images, then layout and paint. The first byte arrives after the fourth wait and the largest paint after the seventh. The server wait is highlighted because it is the one that grows when the site is busy.](https://www.evaluat.com/blog/how-a-web-page-loads-cover.svg)](https://www.evaluat.com/blog/how-a-web-page-loads) ### [What happens when a web page loads: DNS, TLS, TTFB and render](https://www.evaluat.com/blog/how-a-web-page-loads) [Between the tap and the paint there are seven waits, and most speed problems live in exactly one of them. The browser looks up the address, opens a connection, secures it, waits for the server, downloads the page, fetches everything the page asks for, and paints. Learn the order and you can find the slow one.](https://www.evaluat.com/blog/how-a-web-page-loads) [Ahmad Farzan · 24 September 2026](https://www.evaluat.com/blog/how-a-web-page-loads) [![Two comparisons of where a page load's wait goes. Upgrading broadband from 100 Mbps to 1 Gbps cuts the transfer of a 2.6 MB page from 0.21 seconds to 0.02 seconds, saving about 0.19 seconds. Shortening each round trip from 140 milliseconds to 30 milliseconds cuts a page that needs ten round trips in a row from 1.4 seconds of waiting to 0.3 seconds, saving 1.1 seconds.](https://www.evaluat.com/blog/latency-vs-bandwidth-cover.svg)](https://www.evaluat.com/blog/latency-vs-bandwidth) ### [Latency, bandwidth and round trips, explained](https://www.evaluat.com/blog/latency-vs-bandwidth) [Faster broadband does not make a slow website fast. Bandwidth is how much data a connection carries each second; latency is how long one trip takes. A web page needs dozens of small trips, so once a connection passes about 20 Mbps, the number and length of those trips decide the wait, not the size of the pipe.](https://www.evaluat.com/blog/latency-vs-bandwidth) [Ahmad Farzan · 3 October 2026](https://www.evaluat.com/blog/latency-vs-bandwidth) [![The four phases of Largest Contentful Paint shown as a timeline from navigation start to LCP: Time to First Byte about 40 percent, resource load delay under 10 percent, resource load duration about 40 percent, and element render delay under 10 percent, with a good LCP at 2.5 seconds or less.](https://www.evaluat.com/blog/largest-contentful-paint-cover.svg)](https://www.evaluat.com/blog/largest-contentful-paint) ### [Largest Contentful Paint (LCP), explained for engineers](https://www.evaluat.com/blog/largest-contentful-paint) [Your Largest Contentful Paint is the moment the biggest thing on the page, usually the hero image, finishes rendering, and Google treats it as a Core Web Vital. This guide explains what counts as the LCP element, the four phases LCP breaks into, why your lab and field numbers disagree, and how to fix and measure it under real load.](https://www.evaluat.com/blog/largest-contentful-paint) [Ahmad Farzan · 7 May 2026](https://www.evaluat.com/blog/largest-contentful-paint) See it on your site Test in real browsers.\ Debug in real sessions. ## Start with one real-browser page load. Pulse loads a public URL once, returns LCP and CLS plus FCP and TTFB, grades the page, and keeps a video on a shareable link. [Run a free speed test](https://www.evaluat.com/tools/website-speed-test) [Book a demo](https://www.evaluat.com/demo?intent=performance)