Reducing TTFB: where time is lost before the first byte

Time to First Byte is the time between the start of navigation and the arrival of the first byte of the HTML response. It is not a Core Web Vital, but it is the starting point for all the others: if the HTML arrives after two seconds, no image or JavaScript optimization can bring LCP under 2.5 seconds. As a rough guide, a TTFB of around 800 milliseconds or less is generally considered reasonable; the ideal value depends on the type of site.

What is inside TTFB

As measured by the browser, TTFB includes more than people think:

1. any redirects before the final page;
2. the start-up of a service worker, if any;
3. the DNS lookup for the domain;
4. the TCP connection (or QUIC with HTTP/3) and TLS negotiation;
5. sending the request and server processing;
6. the trip of the first byte back.

Someone who only looks at server logs sees item 5 and concludes everything is fine: «the page is generated in 120 milliseconds». But the user may wait a whole second because of the earlier items.

Redirects: the hidden cost

Each redirect is an extra full round trip, possibly with a new connection if the domain changes. A frequent chain:

http, no www  →  https, no www  →  https, with www  →  https, with www and /en/

Three redirects before the real page. On a mobile network with 100 milliseconds of latency, this chain alone can cost several hundred milliseconds. The fixes:

• make sure internal links, sitemaps and campaigns point directly to the final address;
• condense the rules into a single direct redirect to the correct destination;
• enable HSTS, so that after the first visit the browser switches to https without asking the server.

Distance and connection

Network latency also depends on physical distance. A server in a single data centre serves nearby users well and distant ones worse, because DNS, the TCP handshake and TLS each require at least one round trip. The countermeasures:

• serve pages from a delivery network with nodes close to the audience, including the HTML when it is cacheable;
• use TLS 1.3, which needs fewer round trips for negotiation than earlier versions;
• enable HTTP/3 where possible, because over QUIC connection and encryption are established together;
• choose a fast DNS provider and TTLs that are not too short.

Server processing

When the actual waiting time is high, the problem lies in the application. The causes I come across most often:

• no page cache: every visit regenerates the page from scratch by querying the database, even if the content changes once a day;
• slow or repeated queries: a list of articles running one query per item instead of a single one for all;
• synchronous external calls: the page waits for a third-party service (weather, reviews, currency rates) before it starts;
• insufficient server resources: an overloaded shared hosting plan, exhausted memory, PHP or Node processes queuing;
• cold starts: serverless platforms that, after a period of inactivity, take time to wake the instance up.

Measuring on the server side

The Server-Timing header lets you expose the application's internal timings to the browser, which then show up in DevTools next to the request:

Server-Timing: db;dur=85, tpl;dur=30, cache;desc="miss"

This shows at once whether the time goes into the database, template rendering, or whether the cache missed.

Caching the HTML

The most effective fix for sites where the content is the same for everyone is to store the already generated HTML. The options range from the application's page cache to the web server's cache, up to caching on the delivery network. For pages that change often you can use stale-while-revalidate: the user immediately receives the cached version while a new one is prepared in the background.

The tricky part is personalization. Pages with a cart, the user's name or region-specific content cannot be cached as a whole; you then separate the common, cacheable part from the personal part, loaded afterwards.

Streaming the response

Another useful technique is to send the first part of the HTML, that is the head with CSS and critical resources, before the server has finished generating the rest. The browser starts downloading styles and fonts while the server completes the body. Many modern frameworks support this natively; even a simple early flush in a traditional application can help.

In short

• TTFB includes redirects, DNS, connection, TLS and processing, not just server time.
• Remove redirect chains and enable HSTS.
• Bring content closer to the audience and use TLS 1.3 and, where possible, HTTP/3.
• With Server-Timing you find out where time is lost inside the application.
• Caching the HTML and streaming the response are the most effective fixes.