What Is TTFB? Time to First Byte Explained and Measured

TTFB, Time to First Byte, is the time from the start of a page load to the response's first byte, and Google rates 800 ms or less as good and over 1800 ms as poor. 5 phases fill it: redirects, DNS lookup, connection and TLS setup, request, and server wait. UpMonitor's performance probe records TTFB from up to 12 regions and grades it at 500 and 1000 ms. A fast TTFB does not make a fast page, if the HTML is heavy or the largest image loads late.

What Is TTFB?

TTFB is a loading metric that measures the elapsed time from the start of a navigation to the arrival of the first byte of the HTML response, so it captures every network and server delay that happens before the browser has anything to render. The browser reports it as responseStart minus startTime on the Navigation Timing entry. The value is in milliseconds. MDN's shorter definition (DNS lookup, TCP handshake, TLS handshake and the request) and web.dev's phase list (redirects, service worker startup, DNS lookup, connection and TLS negotiation, and the request up to the first byte) describe the same interval. This page splits that interval into 5 phases and counts service worker startup inside the request phase. In a monitoring workflow, TTFB is the first number that moves when an origin, a database or a CDN degrades. Each of those sits in front of the first byte, so a probe records TTFB before page weight or render time.

How Is TTFB Measured? The 5 Phases Before the First Byte

TTFB is measured by the browser's Navigation Timing API as the gap between startTime and responseStart, and the 5 phases that fill that gap run in a fixed order: redirect, DNS lookup, connection and TLS handshake, request, and server wait. The W3C navigation entry orders its timestamps from startTime through redirectStart, redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart and responseStart. The first 3 phases are subtractions between 2 of those attributes; the request and the server wait share the span from requestStart to responseStart. The 5 phases, in the order the browser runs them:

1. Redirect (redirectStart to redirectEnd): each hop is a full round trip, plus a new DNS lookup, connection and TLS handshake when the hop changes host. A chain of 2 redirects adds 2 round trips before the real request leaves.
2. DNS lookup (domainLookupStart to domainLookupEnd): a cold resolver walks the root, the TLD and the authoritative nameserver. A cached answer costs close to 0 ms.
3. Connection and TLS handshake (connectStart to connectEnd, TLS from secureConnectionStart): the TCP handshake and the TLS negotiation each need round trips. Distance between visitor and server sets the price of each one.
4. Request (from requestStart): the browser writes the request line and headers onto the open connection. The phase is short, but it waits on the 3 phases before it.
5. Server wait (up to responseStart): the origin or the edge cache runs its logic and starts the response. This phase is the server response time, and the origin's code and database control it.

UpMonitor's performance probe measures the same interval from outside the browser. It dispatches a GET request with a product-named User-Agent and records the millisecond the response headers arrive. The probe's TTFB is that millisecond minus the millisecond the request started. The probe follows redirects, so redirect time lands inside the number. It then reads the body to the end and reports total response time as a 2nd value. Run the free website performance test to see TTFB and total response time for one URL from the regions you pick.

Is TTFB a Core Web Vital, and Does It Affect SEO?

No, TTFB is not a Core Web Vital; the 3 Core Web Vitals are LCP, INP and CLS, but TTFB is the first sub-part of LCP, so a slow TTFB pushes LCP past its 2.5-second good threshold before a single pixel paints. The 3 Core Web Vitals and their good thresholds are LCP at 2.5 s or less, INP at 200 ms or less, and CLS at 0.1 or less. LCP breaks into 4 sub-parts that run in order: TTFB, resource load delay, resource load duration and element render delay. web.dev gives TTFB about 40% of a well-tuned LCP budget. Google's page experience signals read the Core Web Vitals, so TTFB reaches rankings only through LCP. web.dev states the same limit from the other side: a site does not have to meet the good TTFB threshold, as long as it still scores well on the Core Web Vitals. Cut TTFB first when LCP is over 2.5 s, because it runs before every other sub-part.

What Is a Good TTFB? The 3 Thresholds

A good TTFB is 800 ms or less at the 75th percentile of page loads, needs improvement between 800 ms and 1800 ms, and is poor above 1800 ms, and a synthetic probe from a fixed region grades tighter because it carries no slow-device or slow-network noise. The 3 bands across the 3 scales you meet in practice:

The 3 scales differ because each one measures a different population. Field data is the 75th percentile of real visitors on real devices and real networks. Lighthouse loads the main document in a lab, and its Document request latency insight excludes DNS lookup and redirect time. A monitoring probe runs from a datacenter with a warm network and no device cost. UpMonitor grades a probe at 500 ms because a warm datacenter path removes the device and network cost the 800 ms field threshold allows for. Grade a probe reading against the probe column and a Search Console reading against the field column.

TTFB vs Server Response Time vs Total Response Time vs LCP

TTFB contains server response time, stops before the response body, and is the first sub-part of LCP, so the 4 metrics nest inside each other rather than compete. The 4 metrics, from narrowest to widest:

Server response time is the server-wait phase alone: the time the origin spends building the response. Lighthouse flags it above 600 ms on the main document. It is the only one of the 4 that application code controls end to end.

TTFB adds redirects, DNS lookup, connection and the request on top of the server wait. A page with a 100 ms server wait and 3 slow phases in front of it still reports a poor TTFB.

Total response time adds body transfer after the first byte. TTFB stops at the first byte, so a 2 MB uncompressed HTML document has the same TTFB as a 20 KB one. Confirm the body is gzip or brotli encoded with the free compression checker, and weigh the whole document with the free page weight checker, because neither problem shows up in TTFB.

LCP adds resource load delay, resource load duration and element render delay after TTFB. It is the only Core Web Vital among the 4.

UpMonitor's probe reports TTFB and total response time as 2 separate numbers, ttfb and totalTime, for this reason. A rising totalTime with a flat ttfb is a body problem, not a server problem.

How to Reduce TTFB: 6 Fixes in Order

Reduce TTFB by removing time from the slowest of the 5 phases first, and the 6 fixes below run from the cheapest network change to the deepest origin change. The 6 fixes, in order:

1. Remove redirect hops. Point every link, canonical tag and sitemap entry at the final URL. Add an HSTS header so returning browsers skip the http-to-https hop. Trace each hop with the free http status checker and cut the chain to 0 redirects.
2. Put a CDN in front of the origin. Edge nodes sit close to the visitor, so the DNS, TCP and TLS round trips cross a short distance instead of an ocean. The edge also negotiates HTTP/2, HTTP/3 and TLS 1.3 for the visitor, whatever the origin speaks. Cloudflare and Fastly are 2 examples.
3. Cache the HTML at the edge or in a reverse proxy. A Cache-Control header with even a short max-age turns the server wait into a cache read. web.dev notes that even a short caching time gives a noticeable gain. A minimal header is Cache-Control: public, max-age=60, stale-while-revalidate=300: the edge serves the copy for 60 seconds, then refreshes it in the background for 300 more.
4. Cache expensive queries and rendered fragments. Put Redis or Memcached in front of the database for the queries that run on every request. Cache rendered fragments such as navigation and footers, so the template engine builds them once per TTL instead of once per visitor.
5. Audit slow database queries. Run EXPLAIN on the queries behind the slowest routes and add the indexes the plan shows as missing. A query that scans a growing table takes longer every month, which is how a TTFB that passed at launch drifts past 1000 ms later.
6. Right-size the hosting. Memory or CPU starvation on the origin shows up as server wait, and web.dev lists the host itself as its first recommendation. Move to a plan with headroom. Then stream the markup, so the first byte leaves the server before the template finishes rendering.

Re-measure after each fix from the same region, so the before and after numbers compare like for like.

How to Monitor TTFB Over Time

Monitor TTFB by probing the same URL on a fixed interval from fixed regions, because a single test is one sample from one place and TTFB regressions arrive with a deploy, a database growing, or a CDN cache rule changing. UpMonitor's performance probe records ttfb, totalTime and the HTTP status on every run. It grades each run: success at 500 ms or less, warning up to 1000 ms, failure above. It runs every 300 seconds from 1 region on Free, every 60 seconds from up to 6 regions on PRO, and every 60 seconds from all 12 regions on Agency. The 12 regions span North America, Europe, Asia, Australia, South America and the Middle East. The shape of a change tells you where to look. A regional spread in TTFB with a flat server wait points at distance and the CDN. A rise in every region at once points at the origin. A probe that grades TTFB every 60 seconds reports a regression within 1 interval, before the 75th-percentile field number moves.

Frequently Asked Questions

How do I measure TTFB in the browser?

Read performance.getEntriesByType("navigation")[0].responseStart in the browser console; MDN gives that value as the TTFB of the current page load in milliseconds. It counts from the start of the navigation, so redirects, DNS lookup and connection setup sit inside it. Run it on a repeat visit as well, because a cached DNS answer and a reused connection shrink phases 2 and 3.

What causes a high TTFB?

1 of the 5 phases running long, and each phase has a top cause. Phase 1: a redirect chain. Phase 2: a cold or slow resolver. Phase 3: a distant server that makes each round trip expensive. Phase 4: a large request with heavy cookies. Phase 5: slow application code or an unindexed database query. Phase 5 is the one the origin's own code controls, so start there on a dynamic page.

Does a CDN reduce TTFB?

Yes for distant visitors and for cached HTML, and only by the connection savings for uncached dynamic pages. An edge node close to the visitor shortens the DNS, TCP and TLS round trips. A cached copy of the HTML answers without the origin, which removes the server wait. A dynamic page the edge cannot cache still travels to the origin, so the server-wait phase stays the same size.

Why is my TTFB different in every region?

Because distance sets the round-trip cost of DNS, TCP and TLS. A visitor on another continent pays that cost on every round trip; a visitor in the same city pays almost nothing. A CDN flattens the spread by answering from the nearest edge. UpMonitor probes from 12 regions for this reason, so the spread itself becomes a reading: wide means distance, flat and high means the origin.

Does TTFB include DNS lookup time?

Yes under the web.dev and MDN definitions, where DNS lookup is the 2nd of the 5 phases. Its time sits between domainLookupStart and domainLookupEnd. Lighthouse's Document request latency insight excludes DNS lookup and redirect time, so it reports a smaller number for the same page load. That gap is why a Lighthouse report and a Navigation Timing reading disagree by the length of those 2 phases.