Time to first byte on 26 homepages, and why one reading is not a number

FIELD TEST · 2026-08-20 · 30 sites · 3 passes each

Sample and method: the same 30 sites used since 2026-08-15, each homepage requested three times in a row with a browser user agent on 2026-08-20, from one client in Japan whose traffic leaves through a local proxy. Timings are curl's own write-out values; the figure reported per site is the median of the three passes.

Time to first byte across 26 homepages had a median of 1,118 ms, a floor of 554 ms and a ceiling of 2,723 ms. The number that matters is a different one: on the median site, 77% of that wait had already elapsed before the request was sent, and re-measuring the same site seconds later moved the result by 542 ms.

How we measured it

Fixed before the run, unchanged after.

1. Request https://<domain>/ three times back to back, follow redirects, browser user agent, no retries on failure.
2. Record curl's time_namelookup, time_connect, time_appconnect, time_starttransfer and time_total for every pass.
3. Report the median of the three passes per site, and keep all three so the spread stays visible.

Two sites answered 403 (stackoverflow.com, medium.com) and two returned 200 with a challenge or shell page (www.canva.com, www.reddit.com). Those four are excluded from the medians below, which leaves 26. All 30 negotiated HTTP/2.

Time to first byte, fastest to slowest

The spread across the panel is about five-fold. Nothing here is broken, and nothing here is fast by the threshold Google's own guidance uses.

Eleven of 26 came in under one second, seven were over 1.5 seconds. Median total transfer time was 2,048 ms; the longest was www.nytimes.com at 5,121 ms for 1,432,105 bytes, where the wait was not the server but the download.

The reference points, from web.dev's TTFB article read 2026-08-20: "Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds." The same page adds that TTFB "isn't a Core Web Vitals metric", so the threshold is guidance rather than a grade.

Three quarters of the wait happened before the request was sent

This is the finding that changes what the rest of the table means. Splitting each median TTFB into connection setup and everything after it, the setup portion is 77% on the median site, and it never drops below 45%.

Setup here is DNS plus TCP plus TLS — the tunnel to the origin, negotiated before a single byte of the request goes out. On railway.com the server had 73 ms of the 1,599. Calling that a server response time would be wrong by an order of magnitude.

A single TTFB reading tells you more about where you measured from than about the server you measured.

The same site, three seconds apart, moved by 542 ms

Every site was measured three times back to back. The median gap between a site's own fastest and slowest pass was 542 ms — roughly half its own median TTFB.

Vercel is the extreme case and the clearest one. Its first pass took 3,764 ms and its second took 488 ms, eight times faster, with nothing changed in between except that a connection had just been opened to that host. Had we run one pass instead of three, Vercel would sit at the bottom of the table on one run and near the top on the next.

Why a crawler cares about this at all

Google documents server response time as an input to how much it crawls, not just to how users feel. From the crawl budget guide, read 2026-08-20 at developers.google.com: "If the site responds consistently and its response times (including latency and Time-to-First-Byte) remain stable or improve, the limit goes up, meaning more connections can be used to crawl."

The same page lists the reverse: slower responses, 5xx errors or HTTP 429 push the limit down. Two words in that sentence do the work — consistently and stable. What Google describes reacting to is a pattern over time, which is precisely what a single reading cannot show.

What this crawl cannot tell you

It cannot separate your server from our network. Every number above includes DNS resolution, a proxy hop, a TLS handshake and a path from Osaka to wherever the origin sits, and we have no way from one client to say which part belongs to whom. Treat the absolute values as a property of this measurement, not of those sites.

We also did not measure from a crawler's own network, at a different hour, or with a cold cache. Three passes in a row share whatever warm state the first one created, which is the likeliest explanation for the Vercel result — but it is an explanation, not something we tested.

How to get a number you can act on

Three habits, and one thing to stop doing.

• Compare a site against itself over time, not against other sites once. Same client, same hour, same path, repeated.
• Take the median of at least three passes and keep the spread. On this panel the spread was half the median; a reading without it is not a measurement.
• Split setup from server time before drawing conclusions. If 90% of the wait is handshake, tuning the application will not move it.
• Do not benchmark your server from your laptop and file the result as your server's response time. That is the number this whole crawl is a warning about.

Recording a starting value before you change anything is the same discipline applied to search data, which is how to record a baseline before you change anything. Two other things that cost a crawler time before it ever reaches your content: every redirect in the redirect chain survey, and the missing freshness headers in the last modified header survey that would have let it skip the download entirely. Watching all three across a whole site is what QueryWin is being built to do.

Common questions

How did you measure this?

Three sequential curl requests per homepage on 2026-08-20, browser user agent, redirects followed, from one client in Japan behind a local proxy. Per-site figures are medians of three; all three passes are kept in the raw data.

What is a good time to first byte?

Google's web.dev guidance, read 2026-08-20, puts good at 0.8 seconds or less and poor above 1.8 seconds, while noting TTFB is not itself a Core Web Vitals metric. Our panel's median of 1,118 ms sits between those two, but our path is inside that number, so it is not a verdict on those 26 sites.

Does time to first byte affect crawling?

Google says response times, including TTFB, feed the crawl capacity limit, and names consistency as the thing it reacts to. We did not measure crawl rates against response times ourselves, so we are repeating documentation here, not confirming it.

Why measure three times instead of once?

Because once gave the wrong answer. The median spread between a site's own fastest and slowest pass was 542 ms, and on one site it was 3,276 ms.