Connection setup: what happens before the first byte

The steps before the first request

When a visitor opens your page, the browser works through these steps. Only then does the real request start.

1. Find the address (DNS). The browser asks its own memory, then the computer's, whether it already knows which address belongs to your domain name. If not, the computer asks a DNS server, whose job is to tell it which IP address matches each domain. MDN's description ends there: once the address is known, the browser can talk to the server.
2. Open a connection (TCP). TCP uses a three-message handshake: the browser sends a request to synchronize, the server answers, and the browser acknowledges. That takes one round trip.
3. Secure it (TLS). For an HTTPS address the browser and server then agree on encryption and check the server's certificate. This takes two round trips with TLS 1.2 and one with TLS 1.3.
4. Send the request and wait. Only now does the page request go out. The wait for the first byte includes one more round trip plus the time the server needs to prepare the answer.

MDN's guide to latency makes the point that the first request is the expensive one because it pays for the lookup, the TCP handshake and the TLS negotiation. Later requests are cheaper because the connection is already set up.

Counting round trips

The number of round trips is fixed by the protocols. How long each takes depends on the distance between the visitor and the server. For example, imagine a visitor whose round trip to your server takes 100 milliseconds, as it might for someone on another continent:

The address lookup comes before all of these. The counts are the best case, because lost packets and retries add more. web.dev explains the middle two rows: TLS 1.3 shortens the TLS handshake from two round trips to one, which cuts connection setup time by a third for HTTP/1 and HTTP/2. HTTP/3 builds on TLS 1.3, so a new connection needs one round trip and resuming one needs none.

The lesson is that setup costs scale with distance. A visitor 20 milliseconds away pays a fifth of what the visitor 100 milliseconds away pays.

Three ways to pay less

1. Make each round trip shorter. Serve the page from a server near the visitor. A CDN ends the visitor's connection on a nearby server, and its connection to your server runs over its own network, which often has connections open already. See what a CDN is. In HTTP Archive's lab tests for the 2025 Web Almanac, the median TLS negotiation for a page took 57 milliseconds on a CDN and 177 on an origin server on desktop, and 183 against 302 on mobile. Treat these as lab figures that show the direction, not as promises.

2. Make fewer round trips. Use TLS 1.3 and HTTP/3 where you can. See HTTP/2 and HTTP/3 and HTTPS and TLS speed. Avoid redirects, because each one starts the whole sequence again if it leads to another host, and reuse connections.

3. Start earlier, or at the same time. The browser can open important connections before it needs them. preconnect and dns-prefetch do this, and the resource hints guide shows how.

Reuse is where the saving is

HTTP/1.1 allows one TCP connection to carry many requests one after another, so the setup cost is paid once. HTTP/2 and HTTP/3 go further, sharing one connection between many requests at once. In DevTools you can see which requests used which connection by adding the Connection ID column to the Network panel.

This is why the number of different hosts matters more than the number of files. Every new host needs its own lookup, its own connection and its own secure handshake.

Count your hosts

Open the Network panel in Chrome DevTools, reload the page and add the Domain column (right-click the column headers). Count the different domains. Many pages contact several hosts besides their own: fonts, analytics, tag managers, chat, maps, video and social buttons.

Ways to reduce the count:

• Serve fonts and libraries from your own address. The old reason for using a shared host, that a visitor might already have the file from another site, no longer holds because browsers keep separate caches for each site. See what a CDN is.
• Remove tags nobody uses. Every one is a host. See third-party scripts.
• Load widgets when they are needed, such as when the visitor scrolls to them or clicks, so the connection is made later instead of during the first load.
• Put several things behind one host when it makes sense, for example images on a CDN that also serves your scripts.

Chains of requests

A connection helps nothing if the browser does not know what to ask for. In a chain, one file reveals the next. A stylesheet imports another stylesheet, which names a font. A script loads a second script, which fetches data. Each step has to finish before the next one starts, and each step may need a new connection.

Lighthouse's Network dependency tree insight draws these chains and reports the "max critical path latency", the time of the longest one. Its advice is to reduce the length of chains, reduce the size of the files in them, or defer files the first screen does not need. In practice that means linking the stylesheets in the HTML instead of importing them from other stylesheets, and using a preload hint for a file that is found late, such as the font in a stylesheet. See critical CSS and render-blocking files.

The same insight checks the preconnect hints on the page. It warns when there are more than four, when a hint is unused, and when the crossorigin attribute is missing or wrong. It recommends adding preconnect to the most important origins, but no more than four. The code comments note that Chrome keeps an unused connection for about 10 seconds, so a hint for a request that comes much later is wasted.

Measure it

In Chrome DevTools, click a request in the Network panel and open the Timing tab. The phases that belong to this guide are:

• DNS Lookup: the browser is resolving the address.
• Initial connection: the TCP handshake and the TLS negotiation, together.
• Waiting (TTFB): one round trip of latency plus the server's time.

Later requests to the same host usually show no lookup or connection, because the connection is reused. The time to first byte guide has a command that prints these steps from a terminal.

When Chrome has six connections open to one host on HTTP/1.x, further requests wait in a queue, shown as Queueing. Over HTTP/2 or HTTP/3 that limit does not apply.

Check your own page

Run the free audit and look at Network dependency tree, 3rd parties and Document request latency. The number of hosts and the length of the longest chain tell you how much of the load is spent on connection setup, and the first byte time tells you whether distance is a problem.

Sources

• Understanding latency on MDN: what makes the first request slow.
• What is a domain name? and TCP handshake on MDN.
• Content delivery networks (CDNs) on web.dev: the TLS 1.3 and HTTP/3 handshakes.
• Network features reference in Chrome DevTools: the timing phases and optional columns.
• CDN chapter, Web Almanac 2025: TLS negotiation times.