What does TTFB mean?

What Does TTFB Mean?

TTFB, or Time to First Byte, measures how long it takes from the browser starting a request to receiving the first byte of the response. For a website team, it is most useful on the main HTML document because that first document controls when the browser can discover the rest of the page.

A high TTFB does not automatically mean the server is badly sized. It can come from DNS lookup, TCP connection setup, TLS negotiation, geographic distance, edge cache handling, origin processing, database work, or the return trip back to the browser. The point of the metric is to show that the visitor is waiting before the page has any useful HTML to work with.

Follow the Request Path

When someone in Sydney opens a page, the browser first needs to find the site in DNS, open a TCP connection, complete TLS, and send the HTTP request. If the request can be answered from an edge cache near the visitor, the first byte can come back quickly. If the cache misses, the request continues to the origin, where the application may route it through a CMS, run plugins, query a database, call other services, and assemble the HTML.

Distance matters because these steps are not one round trip. Peakhour's performance material uses realistic one-way latency examples: Sydney to Melbourne is about 5 ms, Sydney to Perth about 25 ms, and Sydney to San Francisco about 75 ms. A Sydney user hitting a San Francisco origin can spend hundreds of milliseconds just establishing the connection and moving the first request and response around the network before the application does any work.

That is why TTFB often exposes origin-first delivery. A CMS page that takes 1.3 seconds to return the main document has already used more than half of the 2.5 second Largest Contentful Paint target before the browser has rendered the largest content. Some uncached pages take 2 to 5 seconds to return the main document. By contrast, Peakhour's WebPageTest example showed a fast main document at 149 ms, and full-page caching cut one Magento main-document load from 2.07 seconds to 82 ms.

What Changes for the Site Team?

The useful question is not "how do we lower TTFB everywhere?" It is "which request paths should avoid origin work?"

Static assets, public article pages, catalogue pages, campaign pages, and many anonymous CMS pages are usually strong candidates for edge caching. When those responses are served from cache, the browser avoids the long trip to origin and the origin avoids rebuilding the same HTML. Dynamic routes need more care. Login, checkout, account, admin, and private API responses should not be reused as if every visitor is the same.

Origin Shield and request collapsing help when cache misses are unavoidable. Instead of every edge location asking origin for the same expired object at once, misses can be routed through a shield POP and duplicate requests can be collapsed into one origin fetch. That does not make slow application code disappear, but it reduces the amount of repeated work the origin has to perform during traffic spikes, purges, and busy publishing periods.

Origin tuning still matters. Slow database queries, heavy plugins, overloaded PHP workers, cold application caches, blocking upstream APIs, and under-sized infrastructure can all show up as TTFB. The difference is that cache and shield controls reduce how often normal visitors pay that cost.

How to Measure TTFB

Use one page type at a time and keep the test close to the users you care about:

• Test the main document in WebPageTest from relevant locations, not only from the default overseas region.
• Read the waterfall: DNS, connect, TLS, request, waiting, and download timing show where the first byte is being delayed.
• Compare cache hit, cache miss, and logged-in or bypassed paths separately.
• Check response headers such as Cache-Status when available, including hit, miss, ttl, key, and collapsed details.
• Pair lab tests with field data so you can see whether real users in Australia, mobile users, or specific regions are seeing the same delay.

TTFB and Core Web Vitals

TTFB is not a Core Web Vital by itself, but it feeds the metrics people notice. If the first byte is late, First Contentful Paint and Largest Contentful Paint usually start late as well. A fast first byte will not fix oversized images, render-blocking CSS, or heavy JavaScript, but a slow one leaves less room for every other part of the page load.

Good TTFB work is therefore evidence-led. Measure the request, identify whether the delay is network, cache, or origin processing, change the path, then compare the same page type again. The win is not a prettier score; it is less waiting for visitors and less avoidable work on the origin.