What are Network Connections for Page Speed?

What are network connections in page speed?

A network connection is the channel a browser opens to a server before it can fetch anything. Setting one up costs time: a DNS lookup, a TCP handshake and, for HTTPS, a TLS negotiation. A page that pulls files from many different servers pays that cost many times, so how connections are opened, reused and shared often matters as much as how big the files are.

What a new connection costs

The first request to a server includes a DNS lookup, a TCP handshake and the secure TLS negotiation. Later requests are faster because the connection is already open (MDN, "Understanding latency"). Each step is a network round trip, so the cost grows with the distance between visitor and server. That is why a new connection hurts most on mobile networks and for visitors far from your servers.

Example: a page loads its own files, an analytics script, a font host, an ad network and a chat widget. That is five separate origins, so five DNS lookups and five connection set-ups before the last byte can arrive, even if each file is small.

Reusing connections

• Persistent connections (keep-alive). A persistent connection stays open and is reused for several requests, which saves repeating the handshake. In HTTP/1.1 persistence is the default; idle connections are closed after a while (MDN, "Connection management in HTTP/1.x").
• HTTP/1.x parallelism. HTTP/1.x handles requests one after another on a connection, so browsers open several connections per domain. 6 parallel connections is the common figure, which MDN describes as typical rather than a fixed standard.
• HTTP/2 multiplexing. HTTP/2 lets parallel requests share one connection and compresses repeated headers. Old HTTP/1 workarounds such as domain sharding stop helping and can hurt, so use fewer origins instead. HTTP/3 is also multiplexed and avoids blocking every stream when a packet is lost (MDN, "Evolution of HTTP").

Warming connections early

If you know the page will need another origin, tell the browser early. <link rel="preconnect"> starts the DNS, TCP and TLS work ahead of time, and it only helps cross-origin requests. MDN advises using it for the most critical origins only, since preconnecting to many third parties can backfire. For lower-priority origins, <link rel="dns-prefetch"> saves just the DNS step. See prefetching resources for the related hints, and read the MDN reference on preconnect for the exact syntax.

Other ways to cut connection cost

• Fewer origins. Self-host critical fonts and scripts, and drop third-party tags you do not need.
• Serve from nearby. A CDN shortens each round trip and lowers time to first byte.
• Do not block on third parties. Load non-critical scripts with asynchronous loading so a slow connection does not stall rendering.
• Use modern TLS and HTTP versions on your server and CDN.

Common mistakes

• Preconnecting to a dozen origins "just in case". Each one uses a connection and CPU time.
• Keeping HTTP/1 habits after moving to HTTP/2, such as sharding assets across subdomains.
• Testing only from one location. Connection cost depends on distance, so a page that feels fast near the server can be slow elsewhere.
• Blaming file size when the waterfall shows long DNS, connect or TLS bars.

How to measure it

The browser's network panel splits each request into DNS lookup, connecting, TLS, waiting and download, and shows when requests are blocked waiting for a connection (MDN, "Understanding latency"). Watch for repeated connection bars to the same origin and for many small origins. To track it over time, LoadFocus page speed monitoring runs Lighthouse audits on a schedule from 25 cloud regions, so you can compare how the same page loads from different distances. For a quick check, the Core Web Vitals checker is free. For your APIs, API monitoring splits each response time into DNS, TCP connect, first byte and download. If you are weighing protocol versions, see the blog posts on HTTP/3 and load testing and network protocols for performance testing. Background on delay itself is in latency.

FAQ

Why is the first request to a site slower than later ones?

The first request needs a DNS lookup, a TCP handshake and a TLS negotiation. Later requests reuse the open connection and skip those steps.

How many connections does a browser open to one server?

With HTTP/1.x, browsers commonly open 6 parallel connections per domain. With HTTP/2 and HTTP/3, requests share a connection through multiplexing, so one is usually enough.

What does preconnect do?

It tells the browser to start the DNS, TCP and TLS work for another origin before the page asks for it. It only helps requests to a different origin and should be kept to the most critical ones.

Does a faster connection fix a slow page?

Not always. Bandwidth helps with large downloads, but most pages are limited by round trips and by the number of origins. Cutting connections and distance often helps more than adding bandwidth.

What is the difference between dns-prefetch and preconnect?

dns-prefetch only resolves the domain name. preconnect also opens the TCP connection and, for HTTPS, completes the TLS negotiation, so it saves more time but costs more.