Time to First Byte (TTFB) is the time between a browser starting to load a page and the first byte of the server's response arriving. If someone taps a link to your pricing page and the first piece of the page reaches their phone 1.2 seconds later, that page's TTFB for that visit is 1.2 seconds. Nothing can appear on screen before that first byte.
For a business, TTFB is a measure of how quickly your server and network setup respond. A slow TTFB delays everything that comes after it, from the first text a visitor sees to the main image or headline. It's often the first place to look when a site feels sluggish even though the pages themselves aren't heavy.
What is Time to First Byte (TTFB)?
TTFB measures how long it takes for a server to start responding to a request. According to web.dev, Google's web performance resource, it covers several phases that happen before the first byte arrives:
- Redirect time, if the URL redirects
- Service worker startup time, if the site uses one
- DNS lookup, which turns your domain name into a server address
- Connection and TLS negotiation, which sets up the secure HTTPS connection
- The request itself, up until the first byte of the response arrives
web.dev offers these thresholds as a rough guide: a TTFB of 0.8 seconds or less is good, between 0.8 and 1.8 seconds needs improvement, and more than 1.8 seconds is poor.
TTFB is not one of the Core Web Vitals. web.dev says that because of this, meeting the "good" threshold isn't strictly required, as long as a high TTFB doesn't make it harder to perform well on the metrics that matter.
Why TTFB matters
It comes before everything else. web.dev notes that TTFB precedes every other meaningful user experience metric, such as First Contentful Paint and Largest Contentful Paint (LCP). A high TTFB adds time to the metrics that follow it, which makes their "good" thresholds harder to reach.
It affects how much Google crawls. Google's crawl budget documentation says that when response times, including latency and Time to First Byte, stay stable or improve, Google's crawl capacity limit goes up. When a site slows down, Google crawls less. For larger sites, a slow server can delay how quickly new or updated pages are discovered. See crawl budget.
It's a clue to server and hosting problems. A consistently slow TTFB usually points to slow hosting, heavy backend processing, missing caching or extra redirects, rather than large images or scripts.
Fast responses help crawlers in AI search, too. AI search tools rely on crawlers and search indexes to retrieve web pages. A server that responds quickly and reliably is one less obstacle between your content and the systems that use it.
How TTFB works
What happens before the first byte
When someone requests a page, their browser may first follow any redirects, then look up your domain's address, open a secure connection and send the request. Your server then has to build or fetch the page before sending the first byte back. Each step adds time. Distance matters too: a visitor far from your server waits longer for every round trip.
Field and lab measurement
web.dev lists several ways to measure TTFB. Field tools capture real visits, including the Chrome User Experience Report (CrUX) and the web-vitals JavaScript library. Lab tools test under controlled conditions, including the Network panel in Chrome DevTools and WebPageTest. Field data shows what real visitors experience, while lab tests help you find and debug the cause.
What TTFB can hide
Caching can make a slow backend look fast, because a cached response skips the server work. web.dev recommends testing with a way to bypass caches so you can see the true server time. It also notes that sites sending 103 Early Hints, an early response a server can send while it prepares the page, may see TTFB measured from that early response rather than from the final page.
Why rendering approach matters
web.dev notes that a low TTFB matters more for single-page apps that rely on JavaScript to render content. Sites using server-side rendering may have a higher TTFB, because the server builds the full page first, but can still deliver better First Contentful Paint and LCP.
How to improve TTFB
- Check your hosting. web.dev advises making sure your host can handle the traffic you send to it. Shared hosting is often slower, and dynamic sites need enough memory and an up-to-date backend.
- Use a CDN. A content delivery network serves content from servers closer to your visitors, which cuts the distance each request travels.
- Cache what you can. Set Cache-Control headers so a CDN can serve cached pages instead of rebuilding them on every request.
- Remove extra redirects. Each redirect adds time before the first byte. Fix any redirect chain, starting with same-origin redirects you control.
- Enable HSTS. The Strict-Transport-Security header lets browsers go straight to HTTPS on later visits, which removes the HTTP to HTTPS redirect.
- Stream your HTML. web.dev notes that browsers process markup efficiently when it's streamed, so sending the page in chunks lets the browser start sooner.
- Consider 103 Early Hints. If your backend is slow, Early Hints let the browser start downloading critical files while the server finishes the page.
Common mistakes and misconceptions
- "TTFB is a Core Web Vital." It isn't. It's a diagnostic metric that helps explain slow LCP and other user-facing metrics.
- "A fast TTFB means a fast page." TTFB only covers the start of the load. Large images, render-blocking resources and heavy JavaScript can still slow what visitors see.
- "One lab test tells the whole story." TTFB varies by visitor location, device, network and cache state. Check field data alongside lab tests.
- "Every site must hit 0.8 seconds." web.dev calls the thresholds a rough guide. The goal is good loading performance overall, not a perfect TTFB number at any cost.
TTFB vs. Largest Contentful Paint (LCP)
TTFB measures when the first byte of the server's response arrives. LCP measures when the largest image or text block in view finishes rendering, and it's one of the Core Web Vitals. TTFB is the first slice of LCP: if the server is slow to respond, LCP can't be fast. But a page can have a quick TTFB and still a slow LCP because of large images or blocking scripts. Use TTFB to diagnose server-side delays and LCP to judge what visitors actually experience.
How Butter approaches TTFB
At Butter, we look at TTFB as part of a broader review of page speed and crawlability. We compare field data with lab tests to see whether slow responses come from hosting, caching, redirects or backend processing, and then share specific recommendations with the client's developer or host.
We focus on the pages that matter most for leads and sales, and we treat TTFB as one signal among many rather than a score to chase. A faster first byte is useful when it helps real visitors see content sooner.
Frequently asked questions
What is a good TTFB?
web.dev suggests 0.8 seconds or less as a rough guide for good TTFB. Between 0.8 and 1.8 seconds needs improvement, and more than 1.8 seconds is considered poor.
Is TTFB a Google ranking factor?
TTFB isn't one of the Core Web Vitals. It still matters indirectly, because a slow TTFB delays metrics like LCP and can reduce how much Google crawls a site.
How do I measure TTFB?
Use field data from the Chrome User Experience Report or the web-vitals JavaScript library to see real visits. For testing, use the Network panel in Chrome DevTools or WebPageTest.
Why is my TTFB slow?
Common causes include slow or overloaded hosting, heavy backend processing, missing caching, distance from the server and extra redirects. Testing with and without a cache helps narrow down which one applies.