Why TTFB alone won't tell you what's actually slow

No. A lower time to first byte does not guarantee a faster page, and a higher one does not guarantee a slower one. Cloudflare has published the numbers to prove it: enabling gzip compression on one of their test pages made TTFB increase 8x, from 213 microseconds to 1.7 milliseconds, while the actual page load time improved 5x, from 43ms to 8ms. The metric got worse. The page got faster.

What TTFB actually measures

Time to first byte is the gap between a browser sending a request and receiving the first byte back. Most guides treat it as one number to minimize, but per Cloudflare's own explanation, "the TTFB being reported is not the time of the first data byte of the page, but the first byte of the HTTP response." That is a narrower thing than it sounds. It can be satisfied by response headers arriving quickly, well before the actual content, the HTML, the data, the thing a visitor is waiting to see, has been sent.

That gap between the two is exactly why the gzip example above happened. Compression adds a small amount of processing time before the response starts, which nudges TTFB up. But compression also shrinks how much data has to travel afterward, which is what actually determines how fast the page shows up. Cloudflare's summary of the stakes is direct: "it's the data that will affect the most important metric of all: how fast the user gets to see the page."

Three different things live inside that one number

Before the first response byte arrives at all, a request has to clear three separate stages, and they behave nothing alike:

• DNS lookup: resolving the domain name to an IP address. Fast when cached, adds real delay on a cold lookup, and has nothing to do with your server.
• Connection and TLS setup: the TCP handshake, then a TLS handshake for HTTPS. Round trips that depend on network distance and encryption overhead, not on your application code.
• Server processing: the actual work your backend does before it starts sending a response. Database queries, template rendering, whatever computation the request triggers.

A single TTFB number adds all three together and hands you one figure. For example, two sites could both report a 400ms TTFB and look identical on that metric alone: one losing most of that time to a DNS provider on a cold lookup, resolving in 250ms before the request even reaches the server, the other resolving DNS instantly but spending 300ms waiting on a slow database query. Same headline number, two completely different problems, and the fix for one, switching DNS providers, does nothing for the other.

Treating the combined number as the target means guessing at which of the three is actually the problem.

Diagnose the phase, then check the actual load time

Fixing this needs two things most single-metric tools do not give you together: which phase is actually slow, and whether a change to it moved the number that matters, real page load time, not just TTFB.

WebPixie's Main Page Analyzer times each request phase separately, from DNS lookup through connection setup and TLS handshake to the first byte, on a daily re-scan. Alongside that breakdown, it also records the browser-measured page load time and the rendered HTML size. That second part is what closes the gap Cloudflare's example exposes: instead of chasing a TTFB number down and hoping the page actually got faster, you can see the phase that changed and whether the browser-measured load time moved in the direction you wanted.

This is also how the DNS and TLS phases stop being invisible costs. A DNS provider adding 150ms on every cold lookup, or a TLS handshake taking longer than it should on a given connection path, shows up as its own line rather than getting buried inside a single combined figure.

What to actually check

• Before changing anything for TTFB: look at the phase breakdown first. A slow DNS lookup usually means switching providers or shortening TTLs, a slow handshake means enabling session resumption or OCSP stapling to cut round trips, and slow server processing points at the application itself, not the network, none of which is visible from the combined number alone.
• After making a change aimed at TTFB: confirm the browser-measured page load time actually moved, not just the TTFB figure. The gzip example is the reminder that these two can move in opposite directions.
• If TTFB looks fine but the page still feels slow: the bottleneck is almost certainly after the first byte, in how much data has to load and render, which TTFB was never measuring in the first place.

None of this means TTFB is useless. A consistently high TTFB across every request is still worth investigating. It means treating the number in isolation, the way most guidance frames it, misses the cases where it actively points in the wrong direction.