Performance
Connection reuse
Also called keep-alive.
Connection reuse is keeping one TCP and TLS connection open and sending many requests over it instead of opening a new one per file. It saves the handshake time on every request after the first.
How it is measured
In a waterfall, look at the connect and SSL segments for each request. A reused connection shows no connect time. In DevTools you can also add the Connection ID column and see which requests share a socket.
On the server, `Connection: keep-alive` and an idle timeout control how long a socket stays open. HTTP/2 and HTTP/3 multiplex requests over one connection by design, so reuse is built in.
Worked example
A shop page pulls 24 assets from its own host. With keep-alive disabled, each request pays a 60 ms TCP handshake plus a 70 ms TLS handshake on a 90 ms RTT link, adding about 3 seconds of stacked setup across six parallel connections. With reuse on, only the first requests pay and the rest start immediately.
A third-party font host that closes connections after one request shows up in the waterfall as a fresh connect bar on every file.
How it differs
Connection reuse is the idea. HTTP/2 is the protocol that makes it the default by sending many streams over one connection. The keep-alive timeout is the knob that decides how long an idle connection survives before it is closed. Reuse can exist without HTTP/2, but HTTP/1.1 needs multiple sockets for parallelism.
Common errors
Setting a keep-alive timeout of a few seconds on a server where users pause longer. Terminating connections at a load balancer that ignores the origin setting. Sharding domains for HTTP/2 and splitting one connection into many. Forgetting that different hostnames never share a connection. Assuming the CDN reuses its connection to your origin.
In practice
Open a waterfall for your home page and look for repeated connect segments to the same host. Raise the idle timeout where it is too short, and consolidate assets under fewer hostnames. Preconnect to third parties you cannot avoid.