dns-prefetch, preconnect, preload: the prefetching pipeline in 2026

In the modern web, a site loads dozens of third-party resources: fonts, analytics, video, chat widgets, images from a CDN. Each one requires a DNS resolve, a TCP handshake, a TLS handshake, and an HTTP request — adding up to several hundred milliseconds per new connection. If those connections are established in advance, the main content renders faster.

In this article we break down four rel hints for the browser and explain when to use each one.

Four levels of hints

From lightest to heaviest:

1. dns-prefetch — DNS resolve only
2. preconnect — DNS + TCP + TLS handshake
3. prefetch — download a resource at low priority (for future use)
4. preload — download a resource at high priority (for the current page)

Each is "stronger" than the previous one and solves its own specific problem.

dns-prefetch

The lightest hint. The browser starts resolving DNS for the specified domain without opening a connection.

<link rel="dns-prefetch" href="//fonts.googleapis.com">

DNS resolution typically takes 20–50 ms on a cold cache. If a resource from that domain is needed later, the resolution time has already been spent in advance — the resource will start loading 20–50 ms faster.

When to use:

• For third-party domains you are certain will be needed (analytics, fonts, chat widgets)
• When you are NOT sure whether the connection will definitely be needed — dns-prefetch is cheap and harmless if it turns out to be unused
• For multiple domains at once — the browser will resolve all of them in parallel

What not to do:

• Do not dns-prefetch 30 domains "just in case." Each one consumes a share of the browser's fetch priority budget.
• Do not use dns-prefetch on domains you are already targeting with <link rel="preconnect"> — preconnect already includes DNS resolution.

preconnect

The browser performs a DNS resolve AND opens a TCP connection AND initiates a TLS handshake. When the real request arrives, the connection is already ready and the request can be sent immediately.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Time saved: 100–300 ms (DNS + handshake). On a cold connection, even more.

When to use:

• For a domain that will definitely be needed (a CDN serving critical resources, a font provider)
• When the resource will be needed 100+ ms after the HTML starts loading
• A maximum of 3–5 domains — more than that puts unnecessary load on the network

An important nuance — crossorigin:

If you are requesting fonts or other resources via a CORS request, you need the crossorigin attribute without a value (for credentials="omit") or with crossorigin="use-credentials". Without it, the preconnect and the real request will open separate connections, making the preconnect pointless.

Example with Google Fonts:

<!-- Correct -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Incorrect -->
<link rel="preconnect" href="https://fonts.gstatic.com">

Without crossorigin, the font will be downloaded over a new connection and the preconnect will have been wasted.

preload

The strongest hint. The browser not only opens a connection but also downloads the resource at high priority.

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/hero-image.webp" as="image">
<link rel="preload" href="/critical.js" as="script">

Use this for critical resources that are definitely required for above-the-fold rendering.

When to use:

• The primary font applied in the above-the-fold area
• The hero image (LCP candidate)
• A critical JS chunk

The as attribute:

Required for preload. It tells the browser what type of resource it is. Possible values:

• font — font (requires crossorigin)
• image — image
• script — JavaScript
• style — CSS
• fetch — XHR/Fetch request
• video — video

Without as, the browser does not know the priority and often ignores the preload entirely.

What not to do:

• Do not preload dozens of resources. If everything has high priority, nothing has high priority. 3–5 preloads per page is the optimum.
• Do not preload resources that might not be used. If a preloaded resource is not used on the page, the browser warns in DevTools: "preload was not used."

prefetch

Downloading a resource at low priority, for use on subsequent pages.

<link rel="prefetch" href="/next-page.html">
<link rel="prefetch" href="/large-bundle.js">

The browser downloads the specified resource during idle time, after the main page has already rendered and the network is free. If the user navigates to the corresponding link, the resource is already in cache and the transition is nearly instantaneous.

When to use:

• The next logical page (for example, on the homepage you can prefetch "About us" if 50% of users navigate there)
• SPA chunks the user is likely to navigate to next
• Large resources that will be needed "later, but certainly"

When not to use:

• On slow connections (mobile over 3G). Prefetch can consume the user's data allowance and provide no benefit.
• On pages where navigation patterns are rare and unpredictable.
• When you are not confident the user will go to that destination.

A modern alternative: the Speculation Rules API

Since 2024 in Chrome (and since 2026 in most browsers), the Speculation Rules API has become available. It is a more advanced page preloading system:

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/article/*" },
    "eagerness": "moderate"
  }]
}
</script>

The browser begins prerendering (not just prefetching, but fully loading and rendering) the specified pages in the background when the user hovers over a link or other signals of click intent are detected. The resulting navigation is instantaneous.

This is the future. It already works in Chrome and Edge in 2026, with other browsers gradually adopting it.

Strategy: what to use and when

For a typical commercial website:

<head>
  <!-- Fonts from CDN -->
  <link rel="preconnect" href="https://api.fontshare.com" crossorigin>
  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

  <!-- LCP image -->
  <link rel="preload" href="/hero-bg.webp" as="image">

  <!-- Analytics and chat — not critical, dns-prefetch is enough -->
  <link rel="dns-prefetch" href="//mc.yandex.ru">
  <link rel="dns-prefetch" href="//www.googletagmanager.com">

  <!-- Inside body, prefetch for subsequent pages -->
  <link rel="prefetch" href="/uslugi/">
  <link rel="prefetch" href="/cases/">
</head>

This delivers an optimal balance — critical resources are preloaded at high priority, secondary domains are resolved in advance, and the next pages are downloaded in the background.

Real numbers

On a typical site without prefetching:

• LCP: 2400 ms
• TTI: 3200 ms

After adding preload for the font and hero image, plus preconnect for the font CDN:

• LCP: 1800 ms
• TTI: 2700 ms

That is a 600 ms improvement in LCP — a significant gain from minimal changes to <head>.

What to avoid

1. Too many preloads — every preload takes priority away from other resources. If you have 20 preloads, none of them is truly high priority.
2. dns-prefetch where preconnect is already present — preconnect already does DNS resolution. It is redundant.
3. prefetch on slow connections — respect prefers-reduced-data via a JavaScript check.
4. preload without as — the browser ignores it.
5. preloading a font without crossorigin — the browser fetches it twice.

Summary

Prefetching is a powerful and inexpensive way to speed up a site. Use dns-prefetch for "might be needed," preconnect for "definitely needed soon," preload for "needed right now," and prefetch for "needed on the next page." Apply these hints deliberately — no more than 5 preloads + 3 preconnects + 5 dns-prefetches per page.

Want a prefetching audit of your site? Contact us. Free within 2 business days.