Preconnect, Prefetch, Preload: Resource Hints That Speed Up Your Site

Your browser is smart, but it’s not psychic. When it starts loading a page, it discovers resources one at a time as it parses the HTML. First it finds the stylesheet, then the fonts referenced in the stylesheet, then the images referenced in the HTML. Each discovery triggers a new request, and each request takes time. The browser can’t start downloading a resource it doesn’t know about yet.

Resource hints change that. They let you tell the browser about critical resources before it discovers them naturally, so it can start preparing earlier. The right resource hints can shave hundreds of milliseconds off your load time by eliminating the discovery delay for your most important assets. This post covers one piece of a bigger system, and we mapped out the rest in the website performance guide written for business owners.

But resource hints are easy to misuse. Preloading everything defeats the purpose, and incorrect hints can actually hurt performance by wasting bandwidth on resources that weren’t needed. Understanding when to use each type of hint, and when not to, is what separates a well-optimized site from one that just added more tags to the HTML head.

We use resource hints strategically on every site we build. Here’s what each one does, when to use it, and the real performance gains you can expect.

How Resource Loading Normally Works

To understand why resource hints matter, you need to understand the normal resource loading timeline.

When a browser requests your page, it receives the HTML document first. It then parses the HTML from top to bottom. When it encounters a <link> tag for a stylesheet, it sends a new request for that CSS file. When it encounters a <script> tag, it requests the JavaScript file. But here’s where it gets slow.

Your CSS file might reference a Google Fonts stylesheet, which itself references font files hosted on yet another domain. Your JavaScript might dynamically create an image element. Your analytics script might load additional tracking scripts.

Each of these nested resources introduces a chain of discovery:

1. Browser downloads HTML
2. HTML references CSS file (new request)
3. CSS references font files (new requests, but the browser didn’t know about these until the CSS was downloaded and parsed)
4. CSS references background images (same delay)

This waterfall pattern means resources deep in the chain don’t start downloading until resources earlier in the chain finish. Resource hints break these chains by telling the browser about downstream resources upfront.

dns-prefetch

DNS prefetch is the lightest resource hint. It tells the browser to perform the DNS lookup for a domain before it’s needed. DNS lookups typically take 20-120 milliseconds, and they must complete before any resources can be downloaded from that domain.

How It Works

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

This tag tells the browser: “You’re going to need resources from fonts.googleapis.com, so resolve that domain name now.” The DNS lookup happens in the background while the browser continues parsing HTML. By the time a resource from that domain is actually needed, the DNS lookup is already done.

When to Use dns-prefetch

• Third-party domains referenced later in the page. Google Fonts, analytics services, CDNs, embedded maps, social media widgets.
• Domains used by resources discovered late. If a CSS file references fonts from a different domain, dns-prefetch that domain in the HTML head so the lookup is done before the CSS even loads.
• API endpoints called by JavaScript. If your JavaScript makes requests to an external API, pre-resolve the domain.

When Not to Use dns-prefetch

• Your own domain. The browser already resolved your domain to load the HTML document.
• Domains you’re already preconnecting to. Preconnect includes DNS prefetch, so adding both is redundant.
• Domains you might not actually use. If a resource is only loaded conditionally, the DNS lookup is wasted.

Performance Impact

DNS prefetch typically saves 20-120 milliseconds per domain. It’s a small gain per resource, but it adds up when your page references multiple third-party domains. It’s also extremely low-cost, using virtually no bandwidth or CPU.

preconnect

Preconnect goes further than DNS prefetch. It performs the DNS lookup, the TCP connection, and the TLS handshake (for HTTPS) all before any resources are requested from the domain.

How It Works

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

The crossorigin attribute is important for font files and resources loaded with CORS. Without it, the browser may establish the connection but then need to establish a new one when the actual resource request requires CORS.

When to Use preconnect

• Third-party origins that provide critical resources. Font servers, CDNs serving your images, essential API endpoints.
• Origins needed for above-the-fold content. If your hero image is served from a CDN, preconnect to that CDN.
• Google Fonts. If you use Google Fonts, preconnect to both fonts.googleapis.com (for the CSS) and fonts.gstatic.com (for the font files).

When Not to Use preconnect

• More than 4-6 origins. Each preconnect holds an open connection, which consumes resources on both the client and server. Preconnecting to too many origins wastes resources. Prioritize the most critical ones.
• Origins used much later in the page lifecycle. If a resource isn’t needed until the user scrolls far down the page or triggers an interaction, the preconnect may time out (typically after 10 seconds) before it’s used, wasting the effort.
• Origins only used conditionally. If a resource only loads for certain users or certain pages, preconnect wastes connection resources for users who won’t need it.

Performance Impact

Preconnect typically saves 100-500 milliseconds per origin, depending on the user’s network conditions and geographic distance from the server. On mobile networks, where latency is higher, the savings are even more significant.

preload

Preload is the most powerful and most specific resource hint. It tells the browser to start downloading a specific resource immediately, at high priority, because it will definitely be needed for the current page.

How It Works

<link rel="preload" href="/fonts/heading-font.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/images/hero.webp" as="image">
<link rel="preload" href="/css/critical.css" as="style">

The as attribute is required and critical. It tells the browser what type of resource it’s preloading, which determines the download priority, the correct content security policy, and whether the resource gets the right request headers.

When to Use preload

• Fonts referenced in CSS. The browser can’t discover font files until it has downloaded and parsed the CSS. Preloading them eliminates the discovery delay.
• Hero images. The Largest Contentful Paint element should be preloaded so it starts downloading as early as possible.
• Critical CSS or JavaScript. If a specific file is essential for above-the-fold rendering, preload it.
• Resources discovered late in the parsing process. Any resource that the browser wouldn’t naturally discover until well into page loading.

When Not to Use preload

• Too many resources. Preloading everything means prioritizing nothing. Limit preloads to 3-5 critical resources. Every preloaded resource competes for bandwidth with other downloads.
• Resources not used on the current page. Preload is for the current page only. If you preload a resource and don’t use it within a few seconds, the browser logs a warning and the bandwidth was wasted.
• Below-the-fold images. These should be lazy-loaded, not preloaded. Preloading them steals bandwidth from above-the-fold resources.
• Third-party scripts you don’t control. If the URL changes frequently, your preload tag will point to a stale URL.

Performance Impact

Preloading the right resources can improve Largest Contentful Paint by 200-1000 milliseconds. The impact is largest for resources that would otherwise be discovered late, like fonts hidden behind CSS imports or hero images set via CSS background properties.

prefetch

Prefetch is forward-looking. It tells the browser to download a resource that will likely be needed for a future navigation, not the current page. The browser downloads prefetched resources at the lowest priority during idle time, so they don’t compete with current page resources.

How It Works

<link rel="prefetch" href="/about.html">
<link rel="prefetch" href="/css/about-page.css">

When to Use prefetch

• Next-page resources. If analytics show that 70% of users on your homepage navigate to your services page, prefetching the services page’s critical resources makes that navigation feel instant.
• Predictable user flows. Multi-step forms, checkout processes, and wizards have predictable next steps. Prefetch the next step’s resources.
• Search result pages. If a user is browsing search results, prefetching the top result’s page can make the click feel instant.

When Not to Use prefetch

• Current page resources. Use preload, not prefetch, for resources needed on the current page. Prefetch has the lowest priority and won’t help your current page load.
• Unpredictable navigation. If users could go anywhere from the current page, prefetching any single page is likely a waste.
• Mobile users on metered connections. Prefetching downloads resources the user may never need, consuming data. Consider using the saveData hint to disable prefetch for users who have requested reduced data usage.
• Large resources. Prefetching a 5MB video that the user might watch is a significant data cost. Be conservative with prefetch sizes.

Performance Impact

Prefetch doesn’t improve current page load time. It improves perceived performance of subsequent navigations. When a user clicks to a prefetched page, the resources are already cached, and the page loads dramatically faster, often appearing nearly instant.

prerender (Speculation Rules)

Prerender goes beyond prefetch by actually rendering an entire page in the background. When the user navigates to it, the prerendered page is swapped in almost instantly. Modern browsers implement this through the Speculation Rules API.

How It Works

<script type="speculationrules">
{
  "prerender": [
    {"urls": ["/services/", "/contact/"]}
  ]
}
</script>

When to Use prerender

• Very high-confidence navigations. When you’re nearly certain the user will navigate to a specific page, such as the next step in a multi-step process.
• Key conversion pages. If users on your pricing page almost always click through to the contact page, prerendering the contact page creates a seamless experience.

When Not to Use prerender

• Pages with side effects. Prerendering a page that triggers analytics events, form submissions, or API calls creates phantom data.
• Multiple candidate pages. Prerendering is expensive in terms of memory and CPU. Only prerender pages with high navigation probability.
• Dynamic, personalized pages. Pages that change based on user state may prerender incorrectly.

Performance Impact

When applicable, prerender makes subsequent page loads feel nearly instant, typically under 100 milliseconds. But the cost in resources means it should be used sparingly and only for high-confidence navigations.

Putting It All Together: A Real-World Example

Here’s how resource hints work together on a typical small business website:

<head>
  <!-- Preconnect to critical third-party origins -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

  <!-- DNS prefetch for less critical third-party origins -->
  <link rel="dns-prefetch" href="https://www.google-analytics.com">
  <link rel="dns-prefetch" href="https://maps.googleapis.com">

  <!-- Preload critical resources for current page -->
  <link rel="preload" href="/fonts/brand-font.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/images/hero-banner.webp" as="image">

  <!-- Prefetch likely next page -->
  <link rel="prefetch" href="/services/">
</head>

This setup eliminates connection overhead for Google Fonts, pre-resolves analytics and maps domains, starts critical font and image downloads immediately, and prepares the most likely next page for instant navigation.

Measuring the Impact

After adding resource hints, measure the results:

• Chrome DevTools Network tab. Look at the waterfall chart. Resources with hints should start downloading earlier in the timeline.
• WebPageTest. Compare waterfall charts before and after adding hints. You should see parallel downloads where there were previously sequential chains.
• Lighthouse. Improved LCP and Speed Index scores reflect faster critical resource loading.
• Real User Monitoring. Tools like Google Analytics or Web Vitals library track actual user experience improvements.

The improvements are cumulative. DNS prefetch saves 50 milliseconds. Preconnect saves 200 milliseconds. Preloading the hero image saves 400 milliseconds. Together, these small optimizations add up to a noticeably faster experience.

Common Mistakes to Avoid

• Preloading resources that aren’t used. This wastes bandwidth and triggers console warnings. Audit your preloads regularly.
• Using preload instead of prefetch for next-page resources. Preload is high-priority and competes with current page resources. Use prefetch for future navigations.
• Preconnecting to too many origins. Keep preconnects to 4-6 critical origins.
• Missing the as attribute on preload. Without it, the browser may download the resource at the wrong priority or double-download it.
• Missing crossorigin on font preloads. Fonts are requested with CORS, so the preload must match.
• Not testing on slow connections. Resource hints provide the most benefit on slow connections. Test with throttled network speeds to see the real impact.

Keep Reading

• Multi-Location SEO: Managing Rankings Across Multiple Markets
• Webhook Workflows: Automating Business Processes with Custom Code
• CDNs Explained: How Content Delivery Networks Speed Up Your Site