Preload, Prefetch, and Preconnect Techniques Explained

In this tutorial, you will learn how to use resource hints, preload, prefetch, preconnect, and dns-prefetch to optimize resource discovery and reduce critical path length. Resource hints tell the browser about important resources before it discovers them in the HTML. DodaTech uses preload for hero images and critical fonts, cutting LCP by 400 milliseconds.

What You Will Learn

• The difference between preload, prefetch, and preconnect
• When to use each resource hint for maximum impact
• How to prioritize critical resources with preload
• How to avoid common anti-patterns with resource hints

Why It Matters

The browser preload scanner is good but not perfect. Resource hints give developers explicit control over loading priority. A correctly placed preload can save 200-500 milliseconds on LCP by starting the download earlier in the page load sequence.

Real-World Use Case

DodaZIP used preconnect to establish early connections to its API domain and CDN, reducing connection setup time by the equivalent of two round trips (approximately 200ms on 3G). Combined with preload for the hero image, the initial page load felt significantly faster in user surveys.

Prerequisites

You should understand HTML document parsing and how the browser Critical Rendering Path works. Familiarity with HTTP connection setup (DNS, TCP, TLS) is helpful.

Step-by-Step Tutorial

Step 1: Understand the Resource Hint Spectrum

Resource hints form a spectrum from early connection setup to speculative loading:

1. dns-prefetch: Resolves the domain name in advance
2. preconnect: Resolves DNS, establishes TCP, and performs TLS handshake
3. prefetch: Downloads resources for the next navigation (lower priority)
4. preload: Downloads critical resources needed for the current page (high priority)

<link rel="dns-prefetch" href="https://api.dodatech.com">
<link rel="preconnect" href="https://cdn.dodatech.com">
<link rel="prefetch" href="https://dodatech.com/blog/next-article">
<link rel="preload" href="/fonts/Inter.woff2" as="font" crossorigin>

Step 2: Use dns-prefetch for Third-Party Origins

DNS prefetch resolves domain names before they are needed. Use it for analytics, font services, and other third-party domains.

<!-- DNS prefetch for common third-party origins -->
<link rel="dns-prefetch" href="//www.googletagmanager.com">
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//connect.facebook.net">

Expected behavior: When the browser later needs to connect to these domains, the DNS resolution step is skipped because it already completed in the background.

Step 3: Use preconnect for Critical Third-Party Origins

Preconnect extends DNS prefetch by also establishing the TCP connection and performing the TLS handshake. Use it for the most critical third-party origins that are needed early in page load.

<!-- Preconnect to the most critical origins -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://cdn.dodatech.com">
<link rel="preconnect" href="https://api.dodatech.com">

Expected behavior: The browser opens a complete connection (DNS + TCP + TLS) to cdn.dodatech.com. When the CSS file references https://cdn.dodatech.com/styles.css, the connection is already established, saving 100-200ms.

Limit preconnect to 3-4 origins. Each preconnect opens a socket that stays idle until used, consuming system resources.

Step 4: Use preload for Critical Resources

Preload tells the browser to fetch a resource with high priority. Use it for LCP candidates, critical fonts, and hero images.

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

<!-- Preload critical fonts (must include crossorigin) -->
<link rel="preload" href="/fonts/Inter.woff2" as="font" type="font/woff2" crossorigin />

<!-- Preload a critical CSS file -->
<link rel="preload" href="/css/critical.css" as="style" />

<!-- Preload a critical JavaScript module -->
<link rel="modulepreload" href="/js/app.js" />

Expected behavior: The preloaded resource appears in the Network panel with Priority: High. It starts loading before the HTML parser reaches the <img> or <link> tag that references it.

Step 5: Verify with DevTools

Open Chrome DevTools, go to the Network panel, and check the Priority column. Preloaded resources show Priority: Highest (for images) or Priority: High (for other resources). Resources without preload show Priority: Low or Priority: Medium.

You can also use the Performance panel to see when each resource starts loading. With preload, the resource appears earlier in the Waterfall.

Step 6: Use prefetch for Next-Navigation Resources

Prefetch downloads resources for pages the user might visit next. The browser uses idle time to fetch these resources at low priority.

<!-- Prefetch the next page the user is likely to visit -->
<link rel="prefetch" href="/blog/next-article" as="document">

<!-- Prefetch assets for the next page -->
<link rel="prefetch" href="/images/next-hero.webp" as="image">

Expected behavior: When the user clicks the link to /blog/next-article, the page loads instantly from the prefetch cache. The Network panel shows the resource with Priority: Very Low.

Step 7: Use Preload with the Link Header (HTTP)

For resources that must be loaded before the HTML becomes available, send preload as an HTTP header.

# NGINX configuration for preload via HTTP header
add_header Link '</fonts/Inter.woff2>; rel=preload; as=font; crossorigin';

This header is sent before the HTML body starts streaming, starting the font download as early as possible.

Step 8: Create a Resource Hint Strategy

Map out your critical resources and assign appropriate hints:

<!DOCTYPE html>
<html>
<head>
  <link rel="preconnect" href="https://cdn.dodatech.com">
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="dns-prefetch" href="https://analytics.google.com">
  <link rel="preload" href="/images/hero.webp" as="image">
  <link rel="preload" href="/fonts/Inter.woff2" as="font" crossorigin>
  <link rel="preload" href="/css/main.css" as="style">
</head>
<body>
  <!-- Page content -->
  <link rel="prefetch" href="/next-page" as="document">
</body>
</html>

Learning Path

flowchart LR
  A[Critical Rendering Path] --> B[Preload, Prefetch, Preconnect]
  B --> C[Font Optimization]
  B --> D[Render-Blocking Resources]
  C --> E[Performance Budgets]
  
  style B fill:#4f46e5,color:#fff
  style A fill:#6366f1,color:#fff
  style C fill:#6366f1,color:#fff

Common Errors

1. Preloading too many resources: Every preload competes for bandwidth and connection slots. Limit preload to 2-3 truly critical resources.

2. Preloading with the wrong as value: The as attribute tells the browser how to prioritize and handle the resource. Wrong values (e.g., as="image" for a font) can cause incorrect prioritization.

3. Forgetting crossorigin on font preloads: Font preloads must include the crossorigin attribute. Without it, the browser performs two requests: one for preload (without credentials) and one for the @font-face rule.

4. Using preconnect for every domain: Preconnect consumes socket resources. Use preconnect for only 3-4 most critical origins. Use dns-prefetch for the rest.

5. Prefetching pages the user may never visit: Prefetch consumes bandwidth for resources that might not be used. Only prefetch high-probability next pages (e.g., the next article in a series).

6. Preloading lazy-loaded resources: Resources with loading="lazy" are intentionally deferred. Preloading them defeats the purpose and wastes bandwidth.

Practice Questions

1. What is the difference between preload and prefetch?
2. When should you use preconnect instead of dns-prefetch?
3. Why do font preloads require the crossorigin attribute?
4. How can you verify that a preload is working correctly?
5. What is the risk of preloading too many resources?

Answers: 1. Preload fetches critical resources for the current page with high priority; prefetch fetches resources for future navigation with low priority. 2. Preconnect should be used for the 3-4 most critical origins needed during initial page load; dns-prefetch is sufficient for less critical third-party origins. 3. Fonts are fetched in cors mode by default because they use anonymous CORS. The preload must match the fetch mode used by the @font-face rule. 4. Check the Network panel in DevTools for the correct priority and check that the resource starts loading earlier in the Waterfall. 5. Preloading too many resources can saturate the network and slow down the loading of truly critical resources.

Challenge

Analyze the resource loading Waterfall of a production site. Identify three resources that would benefit from preload, three origins that would benefit from preconnect, and one page appropriate for prefetch. Implement the resource hints and measure the improvement in LCP and overall load time using before and after Lighthouse audits.

FAQ