Time to first byte (TTFB) is the duration from the moment a browser sends a request until it receives the first byte of the server's response. It captures network and server work before any content arrives. TTFB is the floor under every downstream speed metric, so a slow first byte caps how fast your page can ever render.
Key Takeaways
- TTFB measures request start to first response byte, covering DNS, TCP, TLS, server wait and first byte.
- It is not a Core Web Vital, but it sets the ceiling on your Largest Contentful Paint.
- A commonly used working target is under 800ms, treated as guidance rather than a hard rule.
- Diagnose from a waterfall, then fix the specific sub-part that is slow, not the whole stack.
- Slow first byte on ad landing pages inflates bounce and hurts Google Ads landing page experience.
- Monitor field TTFB with RUM so regressions surface before rankings or conversions move.
What Exactly Is Time to First Byte?
Time to first byte is the clock that starts when the browser begins a navigation request and stops when the first byte of the response headers reaches the client. Everything that happens in that window is invisible to the user yet determines whether the rest of the page can even begin to paint.
TTFB is not a single operation. It is a sum of distinct phases chained together. If any one phase stalls, the total climbs, and no amount of front-end optimization can recover the lost time after the fact.
What Sub-Parts Does TTFB Contain?
Breaking TTFB into its components is the only way to know where the time goes. A typical request passes through the following sequence before the first byte lands:
- Redirect time: the browser follows one or more HTTP redirects before reaching the final URL.
- DNS lookup: the domain name is resolved to an IP address.
- TCP connect: a connection is established with the server.
- TLS negotiation: the encrypted session handshake completes.
- Request send: the full request, including cookies and headers, is sent.
- Server processing wait: the origin builds the response, runs code, queries databases and calls dependencies.
- First byte received: the opening bytes of the response arrive at the browser.
Each of these is independently measurable in a request waterfall, which is why TTFB diagnosis is a matter of reading the chart rather than guessing.
What Is a Good TTFB Target?
A widely repeated working target is to keep TTFB under 800 milliseconds. This figure comes from Google guidance that treats good server response as roughly 200ms of network plus room for server work, and it is presented as a practical threshold rather than a measured industry average.
Treat the number as guidance, not a promise. The right target depends on your architecture: a static edge-served page can sit well under 200ms, while a personalized server-rendered page may legitimately land higher. The point is to have a threshold that flags regressions, not to chase a magic constant.
Is TTFB a Core Web Vital?
No. TTFB is not one of Google's Core Web Vitals, which are Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint. It is instead a diagnostic metric in the web vitals hierarchy, sitting upstream of the metrics that Google does score.
The catch is that TTFB is the floor under LCP. If your server takes 1.2 seconds before any byte moves, your Largest Contentful Paint cannot possibly start until that time has elapsed. A slow TTFB makes an LCP fix mathematically impossible until the server side is addressed.
How Do Lab and Field TTFB Measurements Differ?
Lab measurement comes from synthetic tools run from a fixed location and device profile. Lighthouse and WebPageTest produce a waterfall you can read phase by phase, which makes them ideal for diagnosis.
Field measurement comes from real users through CrUX and your own RUM Navigation Timing data. Field numbers include the full spread of devices, networks and geographic distances your actual visitors experience. A synthetic test from one location in Virginia will mislead you if half your traffic sits in Singapore on mobile connections.
How Do You Read a Waterfall to Diagnose TTFB?
A request waterfall colors each phase so you can see which bar is long. The red or orange stretch before the response is your TTFB budget being spent. Follow this workflow to isolate the cause:
- Open the request waterfall for the main document in WebPageTest or your RUM trace.
- Check the redirect row first; each redirect adds a full connection round trip before real work starts.
- Inspect DNS, TCP and TLS bars; long bars here point to distance, cold connections or missing session reuse.
- Look at the server wait bar, the gap after the request is sent and before the first byte returns.
- Compare the same URL from multiple geographic locations to separate network distance from origin slowness.
- Map the longest bar to its sub-part, then apply the matching fix from the table below.
Which Fix Maps to Which TTFB Sub-Part?
The fastest way to act is to match the slow sub-part to its likely cause and the concrete fix. Use the table as a decision aid rather than a checklist to run blindly.
| TTFB sub-part | Likely cause | Fix |
|---|---|---|
| Redirect time | Chained or unnecessary redirects, http to https hops | Resolve the canonical URL at the CDN edge; collapse redirect chains to a single hop |
| DNS lookup | Uncached lookups, too many distinct hostnames | Use a fast DNS provider; reuse one connection; preconnect to critical hosts |
| TCP connect | Cold connections, no keep-alive | Enable connection keep-alive and HTTP/2 multiplexing |
| TLS negotiation | Full handshake on every visit, no resumption | Enable TLS session resumption and OCSP stapling; terminate TLS at the CDN |
| Server processing wait | Slow database queries, N+1 queries, heavy rendering | Add caching, fix N+1 queries, move work off the request path |
| Server processing wait | Slow third-party API calls inside server rendering | Cache upstream responses, set timeouts, render without blocking on the API |
| Server processing wait | Cold starts on serverless, shared hosting contention | Warm functions, size instances, move off oversold shared hosting |
| First byte received | Geographic distance to origin | Place origin or a full-page cache behind a CDN edge close to users |
How Do Cdns, Caching and Protocol Choices Reduce TTFB?
A CDN shortens the network portion by terminating TLS and serving cached responses from edge locations near the user. For cacheable pages, the request may never reach your origin, which removes server processing wait entirely. Full-page caching at the edge is the single largest TTFB lever for content that does not change per user.
Every redirect forces the browser to repeat DNS, TCP and TLS for a new host before any useful byte arrives, so set the final canonical URL at the CDN edge in a single hop. TLS handshakes are expensive on mobile networks; enable session resumption and OCSP stapling, and terminate TLS at the CDN so the haul to origin uses a warm connection.
HTTP/2 multiplexes requests over one connection, and HTTP/3 over QUIC cuts handshake latency further on lossy networks. Enable both at the CDN and let the client negotiate. Together these remove the connection and handshake cost that sits inside TTFB without touching origin code.
What Server-Side Problems Inflate TTFB?
On the origin, the usual suspects are database queries run in a loop, an N+1 query pattern, and slow third-party API calls embedded in server-side rendering. Each blocks the response until it finishes.
Cache rendered output, batch database access, and never let a downstream API call block the first byte unless the content is strictly required. Move personalization and analytics to after the initial paint where possible. Serverless cold starts and shared hosting contention add unpredictable wait; keep functions warm and move off oversold plans if TTFB varies by time of day.
Geographic distance is a hard ceiling. If your origin sits in one region and users are far away, the speed of light adds latency to every phase. Cache at edges near users or run origin replicas where traffic concentrates.
How Does TTFB Differ Across Platforms?
On Webflow and similar hosted CMS platforms you do not control the origin, so your levers are limited to built-in caching, clean DNS and TLS, and keeping third-party scripts off the critical path. You cannot rewrite origin queries, so accept the platform floor and optimize the parts you can reach.
WordPress TTFB is frequently dragged down by plugin bloat, where each plugin adds database queries and PHP work per request. Add full-page caching, audit plugins for redundant queries, and leave shared hosting. Headless and SSR frameworks move rendering onto the server, which raises the server wait phase; mitigate with edge rendering, caching, and streaming so the first byte leaves before the document is fully built.
What Does TTFB Mean for Paid Media?
Slow first byte on ad landing pages directly hurts paid performance. A visitor who clicks an ad and waits on a blank screen is far more likely to bounce before anything renders, which raises your bounce rate and wastes spend.
Google Ads uses landing page experience as a quality signal, and a slow server response contributes to a poor experience and higher cost per click. For paid traffic, TTFB is a media efficiency issue, not just a SEO one.
How Should You Monitor TTFB for Regressions?
Set up field monitoring with RUM Navigation Timing so you see real-user TTFB by region and device, not just a synthetic single-location number. Alert when the p75 or p90 crosses your threshold.
Combine that with scheduled synthetic checks from multiple locations to catch origin slowness early. The goal is to surface a regression the day it ships, before rankings or conversion rates move enough to notice in a monthly report.
Frequently Asked Questions
What Is the Difference Between TTFB and Server Response Time?
Server response time usually refers only to the time the origin spends building the response, while TTFB includes the full chain from request start to first byte. That means TTFB also counts redirect, DNS, TCP and TLS time before the server is even reached. For diagnosis, TTFB is the more complete number because it captures every phase the user waits through. Server response time is a subset that sits inside it.
Is TTFB the Same as Largest Contentful Paint?
No. TTFB measures the time to the first response byte, while LCP measures when the largest visible content element finishes rendering. TTFB happens entirely before LCP can begin, so it is a prerequisite rather than a substitute. A fast TTFB does not guarantee a fast LCP, but a slow TTFB guarantees a slow LCP is unavoidable. Fix TTFB first, then optimize rendering.
Why Does My Lighthouse TTFB Look Fine but Real Users Are Slow?
Lighthouse runs from one fixed location and device profile, so it misses the geographic distance and device variety your real visitors experience. A test from a data center near your origin will understate latency for users far away or on mobile networks. Field RUM data captures that spread and usually shows a higher p75 than lab tests. Trust field numbers for user impact and lab numbers for diagnosis.
Can a CDN Fix a Slow TTFB on Its Own?
A CDN fixes the network and caching portions of TTFB by terminating TLS at the edge and serving cached pages close to users. It cannot fix slow origin processing if the page is uncacheable and must hit origin on every request. For cacheable marketing pages, a CDN often collapses server wait to near zero. For personalized or dynamic pages, you still need to address origin query and rendering cost.
How Often Should I Measure TTFB?
Measure TTFB continuously with field RUM rather than only during occasional audits, because regressions ship silently with code and content changes. Review the p75 and p90 by region daily through alerts, and run synthetic multi-location checks on each deploy. Continuous measurement turns TTFB from a quarterly surprise into a tracked metric you control. The cost of monitoring is far lower than the cost of a slow quarter.