Reference guide · performance · Published 2026-08-16 · 3 min read
CDN and Time To First Byte
CDN and TTFB: how the edge's cache and connection decides the TTFB you measure, and how to measure origin TTFB separately.
- ·TTFB in the CDN
- ·Cached vs origin
- ·Measure both
What TTFB means when a CDN is in front
Time To First Byte (TTFB) is the interval from the request to the first byte of the response. Behind a CDN that interval has up to three legs:
- The edge answers. If the CDN has the response cached, the edge can reply without contacting the origin at all, and TTFB is the round trip to the CDN plus the edge's local read time.
- The CDN fetches from origin. On a cache miss, the edge requests the origin and relays the first byte once it arrives, which adds the origin's processing time to the edge round trip.
- Connection setup. TLS and TCP handshakes plus any connection reuse sit in front of the first content byte. A CDN terminates TLS close to the user, which is usually faster than the origin's own handshake from the same location.
So "my TTFB is 300 ms" behind a CDN does not tell you whether the origin is fast or the edge is; the split matters for tuning. The TTFB reduction guide covers the origin-side levers; this article covers the perspective change.
The cache split
| Response | TTFB you measure | What it actually proves |
|---|---|---|
Edge cache hit (cf-cache-status: HIT) | Edge latency + local read | The edge has the copy |
| Edge cache miss | Origin time + edge relay | The origin really answered |
| Dynamic / no-cache page | Origin time + edge relay | Similar to miss |
| Asset (immutable) | Edge round trip | Could be 5 ms to a nearby edge |
The practical tool: measure with and without the CDN. A curl to the origin IP (or a non-CDN URL) gives the pure origin TTFB; a curl to the public domain gives the merged number. The difference is the edge's contribution.
The interaction with cacheability
The CDN changes TTFB mostly by making repeat requests for cacheable content cheap. For dynamic pages that must hit the origin every time, the edge adds a hop unless you enable surrogate-key/stale-while-revalidate caching (the Cloudflare cache TTL article covers the TTL knobs). So:
- High TTFB on a cached asset is a routing or TLS problem at the edge, not the origin.
- High TTFB on an uncached dynamic page is usually a real origin problem, once the edge's own connection is fast (the time to first byte guide starts there).
Measuring both numbers
curl -w "connect: %{time_connect} ttfb: %{time_starttransfer}\n" -o /dev/null https://example.com
curl -s -o /dev/null -H "Host: example.com" -w "origin ttfb: %{time_starttransfer}\n" https://203.0.113.50/ -kThe -w timing with the Host header (and -k for the cert mismatch on the raw IP) gives the origin number; the first line gives the edge number. Compare them, and use cf-cache-status to bucket the sample.
When not to chase it
TTFB behind a CDN is only a meaningful target when:
- the site is served through the CDN (otherwise it is the origin number),
- the page is uncached or you are intentionally measuring a miss,
- there are no obvious larger LCP problems (a 3 MB hero dwarfs a 200 ms TTFB gap, and LCP is what the visitor feels).
The web performance audit places TTFB in the full waterfall so the CDN number is not mistaken for the whole story.