Time to first byte

The first byte of the page

Asha opens the Mint tea shop's page. About three quarters of a second later, the shop appears on her screen. For most of that time, the browser had nothing new to draw. It was waiting for the page itself to start arriving.

The page arrives as HTML, a little at a time. The very first piece to come back from the server is the first byte. The wait for it, from the start of the visit, is called Time to First Byte, or TTFB. web.dev is the Chrome team's site for web developers. It calls TTFB "a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive."

A slow TTFB is easy to blame on the server. Was it the server here? The course recorded Asha's visit, with a server that spent 300 ms building the page:

1// Asha's visit to the shop, the middle of 3 visits. Times in ms.2const ttfb = 519.4; // when the first byte of the page arrived3const serverWork = 300; // how long the server spent building the page4 5console.log(`The first byte arrived after ${ttfb} ms.`);6console.log(`The server's work was ${serverWork} ms of that.`);7console.log(`The other ${(ttfb - serverWork).toFixed(1)} ms went on getting there.`);

• Line 1 is a comment. The course timed three visits, and this is the middle one, the median. Times are in milliseconds (ms), thousandths of a second.
• Line 2 is the recorded TTFB. Line 3 is how long the server worked on the page.
• Lines 5 to 7 print The first byte arrived after 519.4 ms., The server's work was 300 ms of that. and The other 219.4 ms went on getting there.

So the server was only part of the wait. More than 200 ms went on something else, and the rest of this lesson finds out what. Here is the whole visit at once, from the start to the first text or image on the screen:

Notice where TTFB stops. It stops at the first byte, not when the page is ready. After it, the browser still had to load the page's stylesheet and a script, and then paint. The first text or image appeared at 764 ms. That moment is called First Contentful Paint, or FCP.

How the course timed it

To see where the time goes, the course built the shop from this story and timed it in Chrome. The set-up:

• The shop is one small page: a heading, a photo of mint tea, and a link. It's served over HTTPS, like a real site.
• Between Chrome and the shop sits a delay proxy: a small go-between program on the same computer. It holds every message for 50 ms on its way, in each direction.
• So each round trip, a message there and its answer back, takes 100 ms, as on a real network. Latency vs bandwidth showed why round trips matter so much.
• The server waits 300 ms before it answers, as if it were building the page.
• Chrome loaded each kind of visit 3 times. Unless the visit says otherwise, each one started with no connection open.

The page measured itself with the attribution build of the web-vitals library, from The web-vitals library. Attribution means the library also reports where the time went, not just how much there was.

What TTFB includes

Back to the question. The server worked for 300 ms, but the first byte took 519.4. Where did the other 219.4 ms go? Picture the takeaway on a busy evening.

web.dev lists the same steps. In its words, TTFB is the sum of:

• "Redirect time"
• "Service worker startup time (if applicable)"
• "DNS lookup"
• "Connection and TLS negotiation"
• "Request, up until the point at which the first byte of the response has arrived"

A service worker is a script a site can install in the browser, to answer some requests itself. "Negotiation" means the handshakes: the hello messages that open a connection before any page data moves.

Five parts, from web-vitals

The web-vitals library splits TTFB into five parts. It works them out from the navigation entry, the page's list of times from The navigation timeline. Each part runs from one of those times to the next:

• waitingDuration: from the start of the visit until the browser begins fetching the page. Redirects land here. The library's README says that even without one, "it's generally not zero."
• cacheDuration: the browser checking its HTTP cache, its store of files saved from earlier visits.
• dnsDuration: looking up the server's address.
• connectionDuration: opening the connection, with its handshakes.
• requestDuration: from the moment the connection is ready until the first byte comes back. The README says it "includes network time as well as server processing time."

Here are the five parts of Asha's visit:

1// web-vitals' five parts of TTFB for the same visit, in ms.2const phases = { waitingDuration: 0.3, cacheDuration: 4.6, dnsDuration: 0, connectionDuration: 110.9, requestDuration: 403.6 };3 4for (const [phase, ms] of Object.entries(phases)) console.log(`${phase}: ${ms} ms`);5const ttfb = Object.values(phases).reduce((sum, ms) => sum + ms, 0);6console.log(`TTFB: ${ttfb.toFixed(1)} ms`);

• Line 2 holds the five parts web-vitals recorded for the visit.
• Line 4 prints each one: waitingDuration: 0.3 ms, cacheDuration: 4.6 ms, dnsDuration: 0 ms, connectionDuration: 110.9 ms and requestDuration: 403.6 ms.
• Line 5 adds them up, and line 6 prints TTFB: 519.4 ms. The five parts make the whole TTFB.

Now read them one at a time. Two parts are big:

• Connection, 110.9 ms. That's the TLS handshake, where the browser and the server agree on a private code (TLS without the wait). TLS 1.3 does it in what its standard, RFC 8446, calls a "1-RTT handshake": one round trip. All 72 connections in the recording used TLS 1.3.
• Request, 403.6 ms. That's the server's 300 ms, plus one round trip: the request travelling there, and the first byte travelling back.

The other three are small:

• DNS was 0 ms. Chrome was told in advance that shop.test lives on this computer, so it didn't look anything up.
• Waiting and cache were a few milliseconds of the browser's own work.

One step is missing: TCP's handshake. This visit used TCP, and a TCP connection opens with its own hello, one round trip, before TLS can start (TCP connections and slow start). Here the proxy sat on the same computer and answered that hello at once. Across a real network, the same visit would pay one more round trip.

Why it matters: on a new connection, the first byte waited for two round trips plus the server's work. The kitchen can't start until the order reaches it, and a faster kitchen can't shorten the trips.

Where the clock starts

Your friend at the takeaway could start the stopwatch at two different moments. The choice changes the number a lot.

TTFB is always the friend at the door. The web-vitals README says the TTFB metric "starts from the page's time origin". The time origin is the start of the visit, 0 ms. So TTFB "includes time spent on DNS lookup, connection negotiation, network latency, and server processing time." The friend at the counter gets the request part. Here are both clocks for Asha's visit:

1// The same visit, in ms from the moment it started.2const connectEnd = 115.8; // the connection was ready, so the request could go3const responseStart = 519.4; // the first byte arrived4 5console.log(`Counted from the start of the visit: ${responseStart} ms`);6console.log(`Counted from the open connection: ${(responseStart - connectEnd).toFixed(1)} ms`);

• Line 2 is when the connection was ready: the waiting, cache, DNS and connection parts added up. The navigation entry calls that moment connectEnd.
• Line 3 is when the first byte arrived. The navigation entry calls it responseStart.
• Line 5 prints Counted from the start of the visit: 519.4 ms. That's TTFB.
• Line 6 prints Counted from the open connection: 403.6 ms. That's the request part.

Read this table across. Each row is one part of a visit, and whether each clock counts it:

Two kinds of visit are timed differently. The web-vitals library recorded both:

• A page restored from the back/forward cache, the copy the browser keeps in memory when you leave a page. Nothing comes from the network, so web-vitals reports a TTFB of 0.
• A prerendered page, loaded out of sight before the visitor asked for it. Its clock starts when the visitor opens it, at the navigation entry's activationStart. web-vitals' source code says TTFB "should be relative to page activation rather than navigation start if the page was prerendered." If the first byte had already arrived by then, it reports 0.

In that lesson, the prerendered shop was opened 2,462.7 ms after its hidden load began, and its TTFB was 0. It's like a friend who ordered for you before you arrived: when you walk in, your food is already on the table.

Why it matters: a TTFB of 0 isn't a broken measurement. It's a visit where the visitor didn't wait for the network at all.

A redirect is a whole extra trip

A redirect is the sign on the shop door from The navigation timeline: "We've moved two doors down." The browser asks for one address, the server answers with another, and the browser asks again. Links from a link shortener work this way.

The course sent Asha through one. Her link pointed at /go on the shop. That answered with the status code 302 and the shop page's address:

1// TTFB in ms, the middle of 3 visits each.2const straight = 519.4; // a link straight to the shop3const throughRedirect = 618.1; // a short link that redirects to the shop4 5console.log(`The redirect added ${(throughRedirect - straight).toFixed(1)} ms.`);

• Lines 2 and 3 are the recorded TTFBs: straight to the shop, and through the short link.
• Line 5 prints The redirect added 98.7 ms.

That's about one round trip. Where did it go? web-vitals' parts show it:

1// web-vitals' parts of TTFB for the visit through the redirect, in ms. Its cache and DNS parts were 0.2const phases = { waitingDuration: 209.9, connectionDuration: 0, requestDuration: 408.2 };3 4console.log(`Waiting, while the redirect happened: ${phases.waitingDuration} ms`);5console.log(`Connecting for the real request: ${phases.connectionDuration} ms`);6console.log(`The real request: ${phases.requestDuration} ms`);

• Line 1 says the cache and DNS parts were 0 on this visit.
• Line 2 holds the other three recorded parts.
• Lines 4 to 6 print Waiting, while the redirect happened: 209.9 ms, Connecting for the real request: 0 ms and The real request: 408.2 ms.

The redirect happened before the real request, so all of its time is in the waiting part. That waiting holds two round trips: one to open the connection, and one to ask /go and read its answer. Then the real request found the connection already open, so its connection part was 0.

So the handshake didn't disappear. It moved, from the connection part to the waiting part. The redirect's own cost was the one extra round trip. This picture puts the two visits side by side:

Why it matters: every redirect costs at least one round trip, before the server has even heard which page you want. The longer the round trip, the more it costs. Redirects shows how to find chains of them and remove them.

Every recorded visit

Here are all the kinds of visit the course recorded. Pick one to see its five parts. The title gives its TTFB, how web-vitals rated it, its FCP, and its LCP, Largest Contentful Paint: the moment the biggest text or image was painted.

The 0.8 second guideline

Asha's TTFB was 519.4 ms. Is that good? web.dev gives three bands:

• Good: 0.8 seconds or less.
• Needs improvement: more than 0.8 seconds, up to 1.8.
• Poor: more than 1.8 seconds.

Why 0.8? The first byte comes before the first paint. So web.dev wants it early enough "that the 75th percentile of users experience an FCP within the 'good' threshold." The 75th percentile is the time that three visits in four stay at or under (Averages lie: reading distributions). The first byte has to leave room for everything after it.

The web-vitals library uses the same two limits: its source sets them at 800 and 1,800 ms. The course tried four amounts of server work, over the same 100 ms round trips:

1// TTFB in ms, the middle of 3 visits, for four amounts of server work.2const ttfb = { 0: 208.3, 300: 512, 900: 1111.6, 1800: 2010.7 };3 4const rating = (ms) => (ms <= 800 ? "good" : ms <= 1800 ? "needs improvement" : "poor");5for (const [server, ms] of Object.entries(ttfb)) console.log(`Server ${server} ms: TTFB ${ms} ms, ${rating(ms)}`);

• Line 2 holds the recorded TTFBs, one for each amount of server work.
• Line 4 rates a value with web.dev's limits.
• Line 5 prints one line for each: Server 0 ms: TTFB 208.3 ms, good, Server 300 ms: TTFB 512 ms, good and Server 900 ms: TTFB 1111.6 ms, needs improvement. The last is Server 1800 ms: TTFB 2010.7 ms, poor.

web-vitals gave every recorded visit the same rating as line 4 does. The 300 ms row says 512 ms, not 519.4. These were separate visits, and separate visits vary a little.

A floor that round trips set

Look at the first row. With no server work at all, the first byte still took 208.3 ms. That's the two round trips: the handshake and the request. It's a floor. No amount of server speed can take TTFB below it on this network.

Why it matters: to get under the floor, you need fewer round trips, or shorter ones. A connection that's already open saves the handshake. A server closer to the visitor makes every trip shorter; CDNs and the edge covers that.

A guide, not a Core Web Vital

TTFB isn't one of the Core Web Vitals, the main measures of a page's experience. web.dev says "it's not absolutely necessary that sites meet the 'good' TTFB threshold, provided that it doesn't impede their ability to score well on the metrics that matter." To impede is to get in the way.

Think of 0.8 seconds like the cooking time printed on a packet: a guide, while the real test is whether the meal is ready. web.dev gives two cases:

• A page that JavaScript builds in the browser, such as a single-page app, needs the lowest TTFB it can get. Its script can only start building once the HTML has arrived.
• A page that the server builds whole "could have a higher TTFB, but better FCP and LCP values" than one built in the browser.

So read TTFB together with the paints that come after it. The last section of this lesson shows how closely they move.

Lab TTFB vs field TTFB

A lab test is one you run yourself, on one computer, with set conditions. Field data comes from real visitors (Lab data vs field data). The two often disagree about TTFB. Usually both are right: they timed different visits. The course recorded two reasons.

A tool that hides the network's wait

Chrome's DevTools can slow the network down for testing. That's called DevTools throttling. The course set it to add 100 ms of latency, the same wait as the delay proxy, and loaded the same page:

1// TTFB in ms, the middle of 3 visits each. Both ways added 100 ms of latency.2const server = 300;3const ttfb = { "Through the delay proxy": 519.4, "With DevTools throttling": 303.9 };4 5for (const [how, ms] of Object.entries(ttfb)) {6  console.log(`${how}: ${ms} ms, of which ${(ms - server).toFixed(1)} ms was not the server`);7}

• Line 2 is the server's work. Line 3 holds the two recorded TTFBs.
• Line 6 takes the server's work away from each one. It prints Through the delay proxy: 519.4 ms, of which 219.4 ms was not the server and With DevTools throttling: 303.9 ms, of which 3.9 ms was not the server.

Under DevTools throttling, TTFB was the server's 300 ms and almost nothing else. The 100 ms of latency never reached it. Lighthouse's docs call this kind "Request-level throttling". They explain: "In real mobile connectivity, latency affects things at the packet level rather than the request level."

Choosing test conditions found where the wait went: DevTools held back the body of the response, not its first bytes. Why it matters: never read the network's share of TTFB from a DevTools-throttled test. Use a real network, or a proxy like this one.

Visitors come by different roads

A lab test often loads one address, straight. Real visitors don't all do that. Some are already on the site, so a connection is open. Some arrive fresh. Some come through a short link in an email. It's like timing the walk to the shop from the house next door, when your customers come from all over town. The course timed the same page all three ways:

1// TTFB in ms, the middle of 3 visits each: the same page, reached three ways.2const server = 300;3const ttfb = { "Already connected": 406.8, "A new connection": 519.4, "Through a redirect": 618.1 };4 5for (const [how, ms] of Object.entries(ttfb)) {6  console.log(`${how}: ${ms} ms, of which ${(ms - server).toFixed(1)} ms was not the server`);7}

• Line 3 holds the three recorded TTFBs. "Already connected" means Chrome loaded the shop, went to another page on the same site, and then opened the shop again. The connection was still open.
• Line 6 prints one line for each. The first is Already connected: 406.8 ms, of which 106.8 ms was not the server.
• The second is A new connection: 519.4 ms, of which 219.4 ms was not the server.
• The third is Through a redirect: 618.1 ms, of which 318.1 ms was not the server.

Now count the round trips. Already connected: one, for the request. A new connection: two, with the handshake. Through a redirect: three. Each one added about 100 ms. Same page, same server, and TTFB went from 406.8 to 618.1 ms.

web.dev warns about exactly this. Lab tools "are often measured using the final URL therefore missing this extra delay." And when field TTFB is much larger than lab TTFB, it "indicates issues that aren't apparent in the lab run, such as use of server-side caching, redirects, or network differences."

Server-side caching means the server keeps ready-made copies of pages, so it doesn't build them every time. web.dev warns that testing a cached page "often shows no TTFB issues". Meanwhile, older or less visited pages may not be cached at all, so their TTFB can be higher.

Why it matters: trust field TTFB for what visitors get, and use the lab to find out why. Make the lab copy the field: test the links visitors really use, on a new connection, over a real network.

TTFB's effect on every later metric

web.dev says TTFB "precedes every other meaningful user experience metric such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP). This means that high TTFB values add time to the metrics that follow it." To precede is to come before. The browser can't paint a page it hasn't received.

The four server times show it:

1// TTFB and FCP in ms, the middle of 3 visits, for four amounts of server work.2const visits = { 0: [208.3, 452], 300: [512, 760], 900: [1111.6, 1348], 1800: [2010.7, 2256] };3 4for (const [server, [ttfb, fcp]] of Object.entries(visits)) {5  console.log(`Server ${server} ms: FCP at ${fcp} ms, ${(fcp - ttfb).toFixed(1)} ms after the first byte`);6}

• Line 2 holds the recorded TTFB and FCP for each amount of server work.
• Line 5 prints when FCP came, and how long after the first byte.
• It prints Server 0 ms: FCP at 452 ms, 243.7 ms after the first byte and Server 300 ms: FCP at 760 ms, 248.0 ms after the first byte.
• Then Server 900 ms: FCP at 1348 ms, 236.4 ms after the first byte and Server 1800 ms: FCP at 2256 ms, 245.3 ms after the first byte.

The gap after the first byte hardly changed: about a quarter of a second every time. So the extra server work went straight into FCP. Going from 0 to 1,800 ms of server work moved FCP by 1,804 ms.

LCP did the same. In every recorded visit, the largest text or image was painted at the same moment as the first one, so LCP equalled FCP. web.dev calls an LCP of 2.5 seconds or less good. It also says LCP "includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays".

So a TTFB above 2.5 seconds rules out a good LCP before the page has even arrived. Here, 1.8 seconds of server work already put LCP at 2,256 ms, close to the limit. Why it matters: TTFB isn't a Core Web Vital, but it uses up the others' time first. The four parts of LCP counts it as the first of LCP's four parts.

When the first byte comes early

TTFB times one byte. So it can look better on paper while the content still comes late.

Some servers do exactly this. web.dev explains that they can send part of the response "before the main body is available". That part can be "just the HTTP headers", or the page's <head>. Sending what's ready so far is called flushing. Either way, the early part carries the first byte, so TTFB stops there. web.dev: "This is another reason why all these are measured as responseStart and so TTFB."

A 103 Early Hints response is another early message. It tells the browser which files to start fetching while the page is built. web.dev says "The 103 Early Hints counts as the 'first bytes'" too. 103 Early Hints covers it.

Sending early is useful. web.dev: "There is real value in sending back data early if the full response is going to take some more time." The browser can start on the files the head names while the server works. But TTFB then says less about when the content arrived.

Why it matters: before you compare two TTFBs, check whether either server sends early. And always read TTFB next to FCP and LCP. Faster server responses times a page that flushes its head early.

Which phase is it?

Each delay below happens in one part of a visit. Ask where it falls: before the real request, while connecting, between the order and the first dish, or after the first byte.

Common mix-ups

• "TTFB is the server's time." No. It counts from the start of the visit. In Asha's visit, the server's work was 300 ms of a 519.4 ms TTFB.
• "A DevTools-throttled test shows the TTFB visitors get." No. With 100 ms of latency, it reported 303.9 ms: the server's work and almost nothing else.
• "Lab TTFB is what visitors get." No. Visitors arrive through redirects, on new or open connections. The same page measured anywhere from 406.8 to 618.1 ms.
• "TTFB is a Core Web Vital." No. web.dev calls its limits a rough guide. What counts is whether it gets in the way of FCP and LCP.
• "A slow TTFB only delays the HTML." No. FCP and LCP moved with it. 1.8 seconds of server work put FCP at 2,256 ms instead of 452.
• "A low TTFB means the page arrived quickly." No. TTFB stops at the first byte. A server that sends its head early can have a low TTFB and still show its content late.
• "A TTFB of 0 means something broke." No. web-vitals reports 0 for a page restored from the back/forward cache, and for a prerendered page whose first byte came before the visitor opened it.

Practice exercises

Answer first, then use the hints.

// web-vitals' five parts of TTFB for a visit on a connection that was already open, in ms.
const phases = { waitingDuration: 0.6, cacheDuration: 0, dnsDuration: 0, connectionDuration: 0, requestDuration: 406.2 };

for (const [phase, ms] of Object.entries(phases)) console.log(`${phase}: ${ms} ms`);
const ttfb = Object.values(phases).reduce((sum, ms) => sum + ms, 0);
console.log(`TTFB: ${ttfb.toFixed(1)} ms`);

// TTFB in ms, the middle of 3 visits, for four amounts of server work.
const ttfb = { 0: 208.3, 300: 512, 900: 1111.6, 1800: 2010.7 };

const rating = (ms) => (ms <= 500 ? "within the 500 ms budget" : "over budget");
for (const [server, ms] of Object.entries(ttfb)) console.log(`Server ${server} ms: TTFB ${ms} ms, ${rating(ms)}`);

Check your understanding

For each question, count the round trips, add the server's work, and ask where the clock started.

Key takeaways

• TTFB is the wait from the start of a visit to the first byte of the page. It stops there, long before the page is ready.
• It adds up redirects, the cache check, DNS, the connection, and the request with the server's work.
• It counts from the start of the visit. A prerendered page counts from when it was opened, and a back/forward cache restore reports 0.
• Good is 0.8 seconds or less, and poor is above 1.8. Round trips alone set a floor that no server can beat.
• Field TTFB includes redirects and real networks. DevTools throttling leaves the network's wait out of TTFB.
• FCP and LCP wait for the first byte. Sending the head early lowers TTFB, even when the content still comes late.

Sources

The facts on this page come from these docs and this code:

• About web.dev, web.dev.
• Time to First Byte (TTFB), web.dev.
• web-vitals 6.2.3 README: TTFBAttribution, Google Chrome.
• web-vitals 6.2.3 source: onTTFB and its attribution, Google Chrome.
• Service Worker API, MDN.
• Navigation Timing Level 2, W3C.
• Back/forward cache, web.dev.
• Prerender pages in Chrome for instant page navigations, Chrome for Developers.
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, IETF.
• RFC 9293: Transmission Control Protocol (TCP), IETF.
• Optimize Time to First Byte, web.dev.
• Network throttling, in the Lighthouse docs, Google Chrome.
• Largest Contentful Paint (LCP), web.dev.
• Faster page loads using server think-time with Early Hints, Chrome for Developers.

Coming next: Faster server responses. The request part held the server's 300 ms. The next lesson opens it up: it times the server's own steps with Server-Timing, caches what it can, and sends the head early.