TTFB and the server response.
TTFB is the time between the browser sending a request and receiving the first byte from the server — the floor every other metric stands on.
Time to first byte is not a Core Web Vitals metric, but it directly affects all three. The reason is simple: until the server responds, the browser can do nothing. A one-second first byte cannot be won back by even the best-optimized page. This is why performance work starts at this floor.
Google points to under 800 milliseconds as a good target. This site’s value measured from the live server is 0.302 seconds; the three managed projects also measure under 300 milliseconds. The numbers are the result of a hosting decision, not of an optimization effort.
Where the time goes
Time to first byte is not one operation but a chain. Splitting the chain shows which link is long, and each link has its own treatment.
- Redirects — if the request was sent to another address, the chain starts over. Every hop is a full round trip.
- DNS resolution — a first-time lookup costs a query.
- Connection setup — the TCP handshake and the secure connection negotiation.
- Request transmission — the physical distance from user to server. The speed of light sets a lower bound.
- Server work — is the page being generated, a database queried, or served from cache?
- Response transmission — the first byte reaching the user.
The fourth and sixth items are physical: the distance between user and server cannot be shortened, but the server can be brought closer to the user. That is the entire job of content delivery networks, and for static content the effect is dramatic.
The fifth item is the software side, and the greatest variance lives there. Between a system that queries a database and generates the page on every request and one that sends a pre-generated file, there is an order-of-magnitude difference.
The redirect chain: the silent cost
The first item is the most overlooked. When a user types the address incompletely or clicks an old link, the request is redirected and the chain starts over. A two-hop chain easily doubles the first byte time.
The typical chain: the user arrives over the insecure protocol and without the subdomain, is first redirected to the secure protocol, then to the preferred subdomain. Two hops, two full round trips.
The fix is doing the redirect at the earliest possible layer and in a single hop. A rule defined at the edge server level is both faster than a redirect done in the application layer and free of server cost.
On this site that rule was measured and recorded: the apex-to-www redirect works but not in the ideal layer — it lives in the application layer. The measured cost stayed inside network noise (twenty requests, uncached, live: baseline ~186 milliseconds, redirected ~195), so it is not urgent. But the right layer is known and on record.
If the measured difference sits inside network noise, it is not an urgent problem — but it is a debt worth knowing.
Serving static files
The surest way to drive server work to zero is not generating the page at request time. Sending a pre-generated file is an order of magnitude cheaper than a database query and template rendering — and because the result is the same for every user, it can be cached without limit on edge servers.
On this site all pages are created at build time and served as static files. Fifty-eight pages, 1,059 kilobytes in total. The only piece of code running at request time is the contact form’s server-side proxy — everything else is a file.
The decision is as much about reliability as performance: where no code runs, no code crashes. There is no application layer that needs scaling when traffic grows.
The limit of this approach is clear too: systems needing genuinely personalized content, session management and fast-changing data cannot be static. But the great majority of brochure sites, documentation, blogs and portfolios can be — and usually are not.
The cache layers
The most powerful tool for lowering first byte time is the cache, and it works in several layers. The outermost layer is the user’s own browser: a previously downloaded resource is never requested at all, and the time becomes zero. The next layer is the edge servers: the resource comes from a server geographically near the user, and the distance shrinks.
The innermost layer is the server’s own cache: a generated page is stored and not regenerated on later requests. On static sites this layer is unnecessary, because the page already sits generated.
For the layers to work, the cache headers must be written correctly, and the basic tension is: a long cache is fast, but updates do not propagate. The solution is a version stamp derived from content — when the file changes, its address changes; when it does not, it stays the same. On this site the style and script links carry that stamp, and the cache lifetime is set to one year.
Protocol and connection
Connection setup is the fixed cost of first byte time, and the protocol version affects it directly. Modern protocols reduce the handshake rounds and allow multiple requests over a single connection; the cost of opening a new connection per resource disappears.
This invalidated part of the classic optimization advice. Bundling files into one package mattered on old protocols because every request was expensive; on modern protocols, several small files can beat one big file — because the unchanged parts stay in the cache.
On the three projects this site manages, the newest protocol version was verified by measurement, and the first byte times are under 300 milliseconds. The protocol choice is usually the hosting provider’s decision, and the only thing to do is make sure it is supported — but its effect exceeds most code optimizations.
One last measurement note: first byte time is not a single number but a distribution, and it varies dramatically by geography. A measurement from a location near your server does not show what distant users experience. A meaningful picture needs measurements from several regions — and knowing where your audience really is determines which regions matter. For a site serving Türkiye, measuring through Europe can mislead; a local measurement point gives a more honest number.