What Are Resource Hints (preload, prefetch, preconnect)?
Learn the difference between preload, prefetch, preconnect, and dns-prefetch, and when each resource hint actually improves load time.
Expected Interview Answer
Resource hints are HTML/HTTP directives such as preload, prefetch, preconnect, and dns-prefetch that tell the browser to start network work — connecting, resolving DNS, or fetching a specific resource — earlier than it would discover the need on its own, reducing perceived load latency.
"preload" tells the browser to fetch a resource the current page will definitely need soon (a hero font or critical CSS) at a high priority, so it is ready before the parser would normally reach it. "prefetch" is a low-priority hint for a resource likely needed for a future navigation, fetched during idle time and cached for later. "preconnect" opens the TCP/TLS handshake to a cross-origin host ahead of time, while “dns-prefetch” performs only the DNS lookup, a cheaper fallback when a full connection is not yet justified. Overusing any of these competes with the current page critical path for bandwidth and connections, so hints must be scoped to a handful of genuinely high-value resources, not sprinkled across every asset.
- preload eliminates late-discovery delay for critical render-blocking assets
- prefetch warms the cache for a likely next navigation during idle time
- preconnect removes handshake latency from a subsequent cross-origin request
- dns-prefetch offers a very cheap fallback hint for less-certain cross-origin needs
AI Mentor Explanation
Resource hints are like a team manager sending the physio ahead to the next venue before the match itinerary officially requires it. Preload is booking the exact treatment room you already know you need for the star bowler. Preconnect is just getting the venue gate unlocked and the access road cleared, without yet knowing which room. Both save time later, but only because the manager committed resources to a genuinely likely need instead of prepping every possible venue in the calendar.
Step-by-Step Explanation
Step 1
Identify the true critical-path resource
Pick assets the current page definitely needs immediately, like a hero font, LCP image, or critical CSS.
Step 2
Add a preload link for certain, near-term needs
Use <link rel="preload"> with the correct “as” attribute so the browser assigns proper priority and reuses the cached fetch.
Step 3
Add prefetch or preconnect for likely, later needs
Use prefetch for a probable next-page asset, or preconnect/dns-prefetch to warm a cross-origin connection ahead of an anticipated request.
Step 4
Measure and prune
Verify via performance tooling that hints actually improve LCP/TTFB metrics and are not competing with the main page’s bandwidth.
What Interviewer Expects
- Correct distinction between preload (certain, near-term), prefetch (likely, future), and preconnect/dns-prefetch (connection warm-up only)
- Awareness that preload is high priority and can hurt performance if overused or misapplied
- Mention of the required “as” attribute on preload for correct prioritization
- Recognition that hints should be measured, not applied speculatively everywhere
Common Mistakes
- Using preload for resources that may never actually be used, wasting bandwidth
- Omitting the “as” attribute on <link rel="preload">, causing the browser to fetch at the wrong priority or twice
- Confusing prefetch (next navigation) with preload (current page)
- Preconnecting to many origins at once, which can throttle the connections that matter most
Best Answer (HR Friendly)
“Resource hints are little instructions in the page that tell the browser to get a head start on things it will probably need soon — like starting to connect to a server, or downloading a font — before it would normally realize it needs them. Used carefully on just the most important resources, they make pages feel noticeably faster to load.”
Code Example
<!-- Certain, near-term critical resource -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<!-- Likely resource for a probable next navigation -->
<link rel="prefetch" href="/checkout/bundle.js" as="script">
<!-- Warm the connection to a third-party origin used soon -->
<link rel="preconnect" href="https://api.example.com" crossorigin>
<!-- Cheaper fallback when a full connection is not yet justified -->
<link rel="dns-prefetch" href="https://cdn.example.com">Follow-up Questions
- How does preload interact with the browser preload scanner and render-blocking resources?
- When would prefetch actually hurt performance instead of helping?
- What is the difference between preconnect and dns-prefetch in terms of what work each performs?
- How would you measure whether a resource hint actually improved a Core Web Vitals metric?
MCQ Practice
1. What is the key difference between preload and prefetch?
preload targets resources the current page definitely needs soon; prefetch targets low-priority, probable future needs.
2. What does the preconnect hint actually accomplish?
preconnect completes the connection setup steps early so a later request to that origin skips that latency.
3. What is the risk of overusing <link rel="preload"> across many assets?
Preload is high priority; too many preloads dilute the benefit and can starve resources that matter more.
Flash Cards
What does preload target? — A resource the current page definitely needs soon, fetched at high priority.
What does prefetch target? — A resource likely needed for a future navigation, fetched at low priority during idle time.
What does preconnect set up? — DNS, TCP, and TLS handshake to a cross-origin host ahead of the actual request.
What is dns-prefetch? — A cheaper hint that performs only the DNS lookup step, for less-certain cross-origin needs.