A page pulls resources from six third-party origins. Which of them would you give a <link rel="preconnect">, which are better served by <link rel="dns-prefetch">, and why is preconnecting all six a bad idea?

## The two hints spend very different amounts Before a browser can request the first byte from a new origin it has to do three things: resolve the hostname (DNS), open a TCP connection, and negotiate TLS. On a fast desktop connection that might be 50 ms; on a mobile network with high latency it is routinely 200–300 ms, because each step costs at least one round trip. `<link rel="dns-prefetch" href="https://analytics.example.com">` does the **first** step only. It is cheap — a DNS query, no socket, no state to keep — and it can be applied fairly liberally. `<link rel="preconnect" href="https://cdn.example.com">` does **all three**, leaving a live, TLS-negotiated connection waiting. That is the bigger win and the bigger cost: an open socket on the client, a session on the server, and handshake traffic that shares the same pipe as everything else the page is loading. ## Ranking the origins The decision is not "which origins do we use" but "which origins block something the user is waiting for": 1. **Serves a first-paint or LCP resource, always.** Preconnect. The font host, the image CDN carrying the hero image, the API host the app calls immediately after boot. These are also the cases where the connection is needed *soon*, which is what makes preconnect pay. 2. **Used later or conditionally.** dns-prefetch. Analytics, a support widget that loads after interaction, a payment iframe on a page where most users never reach checkout. Resolving DNS ahead of time trims the tail without holding a connection open. 3. **Not used on this page at all.** Neither. A global list of hints copied into every template is how pages end up with a dozen of them. One origin that usually needs nothing: your **own**. The connection that delivered the HTML is already open and will be reused, so a same-origin preconnect buys nothing. A *different subdomain* of your site is a different origin and may well deserve one. ## The crossorigin trap A preconnect warms a specific kind of connection. Resources fetched anonymously in CORS mode — fonts, most notably — do not use a credentialed connection, so the hint must say so: ```html <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> ``` Drop the `crossorigin` and you have carefully warmed a connection the font request will not touch, then opened a second one anyway. If a single origin serves both anonymous and credentialed resources you genuinely need two preconnect lines, which is itself a reason to be sparing. ## Why more is worse Three effects compound: - **Bandwidth contention.** Handshakes are not free bytes. Six simultaneous TLS negotiations at the moment the page is trying to download CSS and the hero image take capacity from exactly the resources that determine when the user sees content. - **CPU and battery.** TLS is cryptographic work on the device, and on a low-end phone that work competes with rendering. - **Expiry.** A browser will not hold an unused connection indefinitely; Chromium closes an idle preconnected socket after roughly ten seconds. Preconnect to an origin whose resource is requested a minute later and the handshake happened twice, for nothing. The practical guidance that has survived is to keep preconnect to a handful of origins — realistically three or four — and let dns-prefetch cover the long tail. ## When neither hint is the answer Both hints exist to hide a cost, not to remove it. If a page talks to six third-party origins, the more durable fix is usually to talk to fewer: proxy an asset through your own origin so it reuses the existing connection, drop a vendor script nobody reads the data from, or self-host a font instead of reaching for another host. A hint that shaves 150 ms off a request the page did not need is a worse outcome than deleting the request. Finally, remember what these hints cannot do. Preconnect makes the *connection* ready; it does not fetch anything, so the resource still needs to be discovered before it is requested. If the real problem is that the URL is buried in a stylesheet or created by a script, warming the connection helps far less than making the resource discoverable earlier.