Preconnect and DNS-Prefetch Hints
Preconnect and dns-prefetch warm up connections to origins needed soon, cutting latency from DNS, TCP, and TLS before the first real request.
Definition
These resource hints ask the browser to begin name resolution, and optionally the full connection setup, to an origin in advance of the request that will actually use it.
Context and scope
They are applied to critical third-party origins such as font, analytics, or API hosts identified during performance profiling.
Common misconceptions
- preconnect is free and can be added for every origin
- dns-prefetch already performs the TLS handshake
Anti-patterns
- adding preconnect for dozens of origins indiscriminately
- combining preconnect with an attribute that blocks rendering
Related concepts
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preconnect
Definition
These resource hints ask the browser to begin name resolution, and optionally the full connection setup, to an origin in advance of the request that will actually use it.
They are applied to critical third-party origins such as font, analytics, or API hosts identified during performance profiling. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
A dns-prefetch hint resolves the hostname, while preconnect goes further and opens TCP and TLS, so the latter saves more time but consumes a socket and browser resources.
Browsers cap the number of concurrent speculative connections, so overusing preconnect can starve real requests; reserve it for a small set of known-critical origins.
Trade-offs and alternatives
Combine hints with a crossorigin attribute when the connection needs a separate credential context, otherwise the warmed socket will not be reused by the actual fetch. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that preconnect is free and can be added for every origin. Another is that dns-prefetch already performs the TLS handshake. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to adding preconnect for dozens of origins indiscriminately and to combining preconnect with an attribute that blocks rendering. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Fetch Priority Signals, Speculative Parsing and Preload Scanner, Render-Blocking Resources.