When people talk about server response time, they usually think of the application’s work: PHP running WordPress, database queries, HTML generation. But before the server even receives the request, the browser has to go through a series of steps: discover the server’s address, open a connection, negotiate encryption. Each one takes one or more round trips over the network, and on a mobile connection each trip can be worth 50, 80, sometimes 150 milliseconds.
These milliseconds are part of the TTFB that users experience and that the Chrome UX Report measures: field Time to First Byte starts at the beginning of the navigation and includes redirects, DNS resolution, connection and TLS negotiation, not just the server’s processing time. On a site with an efficient page cache, they can account for the main part of the TTFB. In this article we look at what happens before the first byte, how much each phase costs and what can be done to reduce it.
The phases, in order
When a user opens an address, the browser runs in sequence: any redirects, each with its own complete cycle; DNS resolution of the domain name; opening the TCP connection, with one round trip; TLS negotiation, with one or two trips depending on the protocol version; sending the request and waiting for the response, with another trip plus the server’s processing time. With HTTP/3, TCP and TLS merge into a single phase, as we saw in the article on HTTP/3 and QUIC.
Redirects: the most avoidable cost
The worst case, and it is still common, is the one where the user arrives at an address that gets redirected. A link published as http://example.com produces a plain-text request, a redirect to https://example.com, then perhaps a second one to https://www.example.com, and a third to add the trailing slash to the address. Each redirect is a complete request and response cycle, sometimes with a new connection, and the time adds up before the page is even requested.
The solutions are simple. Internal links, campaigns, social shares and profiles must always point to the final address, with the correct protocol, domain and format. Server-side redirect rules must lead directly to the final destination in a single step, with no chains. And the HSTS header, optionally with inclusion in the browsers’ preload list, makes the browser go straight to HTTPS without even attempting the plain-text request.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadA special case concerns advertising campaigns and link-tracking services, which often pass through one or more intermediate domains before reaching the site. These redirects are not under the site’s control, but their cost shows up in the field data of the destination pages, and it is worth knowing about when analyzing the TTFB of paid traffic.
DNS
DNS resolution translates the domain name into the server’s address. The browser asks its own cache first, then the operating system, then the configured resolver, usually the one from the connection provider or a public service, which in turn, if it doesn’t know the answer, queries the chain of servers down to the one authoritative for the domain. The answer stops at the first level that still knows it, and each level keeps it for the time indicated by the TTL, the record’s time to live.
For the site, there are four levers. The first is the DNS provider: a service with an anycast network, meaning servers distributed across many locations that answer to the same address, responds faster than a single server in one data center, especially for distant users. Many CDNs and registrars offer DNS of this kind at no extra cost. The second is the TTL: values that are too low, a few seconds, force resolvers to query the authoritative server often; values of a few minutes or a few hours let caches answer in most cases. Very low TTLs only make sense when you expect to change addresses often, for example during a migration.
The third is CNAME chains: a domain that is an alias of another domain, which in turn is an alias of a third, requires several resolutions in sequence. Setups with CDNs and external services produce them easily; many DNS providers offer direct alias resolution at the domain apex to avoid them. The fourth is the HTTPS record, a newer record type that lets you tell the browser, already in the DNS response, which protocols the server supports, such as HTTP/3, and other connection parameters, saving later attempts.
For the third-party domains the page uses, such as those for fonts, analytics or external CDNs, DNS resolution can be brought forward with dns-prefetch or, for critical domains, with preconnect, as explained in the article on preload, preconnect and fetchpriority. The most effective solution, however, remains reducing the number of different domains the page depends on.
TCP and distance
Opening a TCP connection requires one round trip between the device and the server, and the duration of that trip depends mainly on physical distance and network quality. A user in Milan connecting to a server in Milan may have a few milliseconds of latency; the same user going to a server in the United States will have more than a hundred, and every phase that requires a trip will pay them again.
That is why server location matters: a site with an audience in Italy should have its server, or at least its points of contact with users, in Italy or nearby Europe. A CDN solves the problem for sites with a distributed audience: the connection is opened with the node closest to the user, and the leg to the origin server runs over already-open connections on quality networks. It is one of the concrete advantages of CDNs, to be distinguished from page caching, as we saw when discussing Cloudflare.
TLS: version, certificates and resumption
TLS negotiation establishes the encryption of the connection. With TLS 1.2 it requires two round trips; with TLS 1.3, standard since 2018 and supported by all modern browsers, one is enough. Enabling TLS 1.3 on the server, or checking that it is enabled, is therefore one of the simplest changes with the best cost-benefit ratio. Almost all web servers and modern CDNs support it; it is worth disabling the obsolete versions, TLS 1.0 and 1.1, for security reasons as well.
With TLS 1.3 there is also session resumption: a browser that has connected to the same server recently can reuse the keys negotiated earlier, and in 0-RTT mode send the request along with the first message of the negotiation. As with HTTP/3, 0-RTT mode is used only for requests without side effects, because the data in the first message could be replayed by an attacker.
The certificate itself has a weight. During negotiation, the server sends its own certificate and the intermediate ones in the chain: a long chain, or certificates with large RSA keys, increase the data to transmit, and on slow networks can require additional packets. Certificates with ECDSA keys are smaller and faster to verify, and are by now supported everywhere; many setups serve both types, leaving the choice to the client. You should also check that the server sends the complete chain: if an intermediate certificate is missing, some clients have to fetch it separately, with a further delay.
One last item concerns certificate revocation checking. For years the OCSP mechanism let clients ask the certificate authority whether a certificate was still valid, with an extra request that the OCSP stapling technique avoided by including the response in the negotiation. In recent years several certificate authorities have started to abandon OCSP in favor of other mechanisms, and browsers no longer perform this check in a blocking way: today it is a less critical aspect for performance than it used to be, but it is still useful to check the configuration recommended by your certificate authority.
# nginx: modern protocols and session resumption
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 1d;
ssl_early_data on; # 0-RTT: evaluate carefully
http2 on;Reusing connections
The most effective way to reduce the cost of connections is to open fewer of them. With HTTP/2 and HTTP/3, all the resources of a domain travel over a single connection, and the opening cost is paid only once. Every additional domain, on the other hand, requires its own chain of DNS, TCP and TLS. A page that loads fonts from an external service, libraries from a public CDN, images from a subdomain and scripts from five different vendors opens seven or eight connections, each with its own cost, and often right at the critical moment of loading.
Hosting the resources needed for the first paint on your own domain, such as fonts, CSS and main scripts, eliminates these connections. Practices from the past, such as spreading resources across several subdomains to increase the number of parallel downloads, were useful with HTTP/1.1 and are counterproductive today. Keeping connections open between one request and the next, with suitable idle times, also avoids reopening them while navigating between pages.
How to measure
From the command line, curl lets you measure the time of each phase precisely:
curl -so /dev/null https://example.com/ -w '
redirects: %{time_redirect}s
DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
first byte: %{time_starttransfer}s
total: %{time_total}s
'The values are cumulative: the TLS time includes those of DNS and TCP, and so on. Running the command from different locations, or from a server close to users, gives a realistic idea of connection times. In the browser, the DevTools Network panel shows the same phases in the Timing tab of each request, and the waterfall makes them visible at a glance with the colored segments at the start of the bars.
On real users, the Navigation Timing API exposes the start and end of each phase: domainLookupStart and domainLookupEnd for DNS, connectStart and connectEnd for the connection, secureConnectionStart for TLS, redirectStart and redirectEnd for redirects. A Real User Monitoring system that records these phases separately lets you understand which part of the TTFB depends on the network and which on the server, and see how it varies by country, connection type or traffic source.
const n = performance.getEntriesByType( 'navigation' )[ 0 ];
const phases = {
redirect: n.redirectEnd - n.redirectStart,
dns: n.domainLookupEnd - n.domainLookupStart,
connection: n.connectEnd - n.connectStart,
tls: n.secureConnectionStart > 0 ? n.connectEnd - n.secureConnectionStart : 0,
server: n.responseStart - n.requestStart,
};A checklist
- No redirects for the most-used addresses; chains reduced to a single step; HSTS enabled.
- DNS provider with an anycast network, TTLs of minutes or hours, few CNAME chains, HTTPS records where supported.
- Server or CDN close to users.
- TLS 1.3 enabled, obsolete versions disabled, session resumption configured, complete certificate chain, preferably with ECDSA certificates.
- HTTP/2 or HTTP/3, few connections to different domains, critical resources on your own domain, preconnect only for essential domains.
In short
Before the first byte come redirects, DNS, connection and encryption: phases that depend on the site’s configuration more than on the server’s power, and that on a mobile network can be worth several hundred milliseconds. They are included in the TTFB measured in the field and therefore, by cascade, in the LCP. On a site with a good page cache, they are often the largest part of the response time.
The fixes are almost all configuration and rarely expensive: eliminate redirects, choose a fast DNS provider with reasonable TTLs, bring servers closer to users, enable TLS 1.3 and session resumption, reduce the domains to contact. None of these changes is spectacular on its own, but together they can halve the time before the first byte, for all pages and all users.
