Transloadit

What is Time to First Byte?

Time to First Byte (TTFB) is the elapsed time from starting a request or navigation until the first byte of the response arrives. Depending on where the timer starts, it can include redirect, DNS, connection, and TLS setup in addition to server processing.

How Time to First Byte works

TTFB marks the moment a response starts arriving, so everything before that moment counts toward it and nothing after it does. For a page navigation measured in the browser, web.dev lists the phases it sums: redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request up to the first response byte. Browsers expose that moment as responseStart in the Navigation Timing and Resource Timing APIs. A CDN cache hit removes the trip to the origin from the total, which is why the same URL can show very different values on a cache miss and a cache hit. When a CDN is in the path, a Server-Timing response header can split the number further: Amazon CloudFront, for example, can report whether a response was a cache hit or a miss and, on a miss, the origin’s first-byte latency separately from its own. Servers and intermediaries choose which Server-Timing metrics to send, so the header shows only what they report. In media delivery, TTFB locates the delay before a playlist, segment, image, or API response begins to transfer; it says nothing about how long the body then takes to download.

Key facts

  1. Why do two tools report different TTFB for the same request? They start the clock at different points. The web-vitals library measures a navigation from its start, or from activation for a prerendered page, to responseStart, which includes redirects, DNS, connection, and TLS. Chrome DevTools labels a narrower phase “Waiting (TTFB)”: it follows the separate DNS lookup, connection, and request-sent phases and covers one round trip of latency plus the time the server took to prepare the response. curl’s time_starttransfer runs from the start of the transfer and includes name lookup, connection setup, and the TLS handshake. A CDN log is narrower again: CloudFront’s time-to-first-byte field is measured on the server, from receiving the request to writing the first byte of the response, so it contains no client network time. Match the definitions before comparing numbers or setting a target.
  2. Is there a target value? For page navigations, web.dev gives a rough guide: 0.8 seconds or less is good, and more than 1.8 seconds is poor. TTFB is not a Core Web Vital, and web.dev calls the thresholds a rough guide because a server-rendered page can have a higher TTFB and still show its content sooner than a page that renders in the browser. The guide is stated for navigation requests, meaning HTML documents; web.dev gives no threshold for images, video segments, or API calls.
  3. Can TTFB be measured in the field for media served from a CDN hostname? Only if the CDN allows it by sending a Timing-Allow-Origin response header that lists the page’s origin or the wildcard *. For a cross-origin resource sent without that header, the Resource Timing API reports responseStart as 0, along with the DNS, connection, and request timestamps. responseStart is also 0 for a resource retrieved instantly from a cache, so filter zeros out instead of averaging them. The same header controls whether a page can read Server-Timing metrics from another origin.
  4. Does a 103 Early Hints response count as the first byte? In the browser APIs, yes: responseStart returns the time of the first interim response when there is one, and web.dev states that the 103 counts as the first bytes. finalResponseHeadersStart gives the start of the final response instead. Chrome reported the final response as responseStart from version 115 and reverted that in version 133, so TTFB data from Chrome can shift across those versions for sites that send Early Hints. Flushing response headers early has a similar effect, so a lower TTFB after enabling either is not, by itself, evidence that the main content arrives sooner.

When Time to First Byte matters

Compare TTFB for a CDN cache miss and a cache hit of the same URL, under otherwise similar conditions, to see how much latency the miss path adds on top of the delivery path. A low TTFB does not guarantee a fast complete response because download and rendering time remain separate.

How Transloadit helps with Time to First Byte

On Transloadit’s Smart CDN, a cache miss does processing work that a cache hit skips. On a miss, the request imports the original from your storage and runs your Template to produce the result; on a hit, the cached result is delivered from the edge without running anything. The Smart CDN product page reports cold and warm request timings separately and advises allowing for source fetching and transformation time when the cache is cold.

The product page does not say whether its timings are time to first byte or full response time, or whether any response bytes are sent before processing finishes on a miss, and it labels the timings as dated measurements that vary by workload. Measure your own Template by comparing a cache miss with a cache hit for the same URL. A first and a repeat request are not automatically that pair: the URL may already be cached at the edge, and the /file/serve Robot tells browsers to cache results by default, so a repeat request from a browser may be answered locally. The product page advises checking cache response headers when debugging.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free