Reuse connections and cached responses

The first request to a server is expensive. It needs a DNS lookup, a TCP connection, and a TLS handshake before a single byte of HTTP moves. Later requests to the same origin can skip all of that by reusing the connection that’s already open.

HTTP/2 and HTTP/3 carry many requests over one connection, as we saw in the previous lesson. Reuse cuts setup cost a lot. Server limits, network changes, and connection policies still play a part, but the general rule holds: the second request is cheaper than the first.

Caching skips even more

Reusing a connection still transfers the response. Caching can avoid that too.

When a response arrives with a header like this:

Cache-Control: max-age=31536000, immutable

the browser stores it and reuses it for a year without asking the server. That’s a fresh cached response. No request leaves the machine.

When a stored response is stale, the browser can revalidate it. It sends a conditional request, and if nothing changed the server answers with a tiny 304 Not Modified instead of the whole body:

HTTP/1.1 304 Not Modified
ETag: "a3f9c1"

The browser then uses the copy it already had.

Different rules for different resources

A versioned asset like /assets/app.8f3a2c.js never changes. When the file changes, the name changes. So it’s safe to cache it for a year.

HTML and API responses are different. The URL stays the same while the content changes, so they need short lifetimes or revalidation on every request.

A repeat visit is not a first visit

This makes a repeat visit a different scenario from a first visit. Test both on purpose.

In the Network panel, reload once with “Disable cache” checked, then once with normal caching. Compare the transferred size column, the status codes, and the Timing details. On the warm reload you’ll see (memory cache), (disk cache), or 304 next to many resources.

Don’t treat your own warm reload as what a new visitor experiences. Their browser has nothing cached and no connection open.

Try this on your own project: pick one stylesheet and compare its first and second request. Write down whether the browser transferred the body again, and which header made the difference.