Connection reuse

A name resolution, unless the answer is already cached, which is a round trip to a resolver.

A transport handshake, which is another round trip before any application data moves.

An encryption negotiation on top of that, which historically added a further round trip and has since been reduced.

All of it is latency rather than bandwidth, which means it is barely affected by a faster connection and dominated by physical distance.

Persistent connections let several requests share one connection sequentially, removing the setup cost from all but the first.

Multiplexing removed the sequential part: many requests travel over one connection concurrently, so a slow response no longer blocks the ones behind it.

Together these made a page of fifty small same-origin resources a very different proposition from what it was when each needed its own connection.

Which is why bundling everything into one file is no longer automatically right: it trades caching granularity for a saving that has largely gone.

A new origin. Every additional hostname needs its own connection with the full setup cost, which is why a page contacting a dozen third parties is slow regardless of how small each response is.

Total transferred bytes, which multiplexing does nothing about.

Resources discovered late, because a resource the browser only learns about after parsing something else cannot be requested early no matter how the connection behaves.

So the useful modern advice is to reduce origins and bytes, and to make critical resources discoverable early — not to count requests.

The number of resources the served HTML references is reported as context, explicitly as a count of referenced files rather than of browser requests.

Third-party origins the page contacts are reported separately, since those are the count that still carries a real cost.

Preconnect declarations are compared against the origins really used, which is how a connection is warmed before it is needed.

The protocol version negotiated is observable from the response, which bears on whether multiplexing applied at all.

It keeps a small number open per origin and reuses them, closing idle ones after a timeout the server also has a say in.

Under the older protocol it opened several connections per origin to work around head-of-line blocking; under multiplexing one is usually enough.

A preconnect declaration asks it to establish one before anything requests from that origin, which is useful only where something will.

Connections are a limited resource, so opening them speculatively against low-value origins delays the ones that matter.