Preload and prefetch are browser resource hints that tell the browser to fetch files earlier than it normally would. Preload prioritizes resources the current page needs right away, like a hero image or web font, to improve Largest Contentful Paint. Prefetch fetches resources the user will probably need next, like the next page, so navigation feels instant. Used well, they sharpen Core Web Vitals and perceived speed.
What Preloading and Prefetching Are
Browsers discover resources by parsing HTML top to bottom, then requesting files as they appear. That sequential discovery can leave critical assets waiting in line behind less important ones. Resource hints let you override the default order and signal intent ahead of time.
Preload tells the browser: this resource is needed for the current page, fetch it now at high priority. It is for assets the browser would otherwise find late, such as a font referenced deep in a CSS file or a hero image set as a background. Prefetch tells the browser: this resource is needed for a future navigation, fetch it when idle at low priority. It is for the JavaScript chunk or page a user is likely to visit next. The two solve different problems, and confusing them wastes bandwidth or hurts the very metrics you are trying to improve.
The Hint Family at a Glance
| Hint | Purpose | Priority | Typical use |
|---|---|---|---|
| preload | Fetch a critical resource for this page early | High | Hero image, key font, critical script |
| prefetch | Fetch a resource for a likely next navigation | Low | Next page, deferred chunk |
| preconnect | Open a connection to a domain early | High | Font host, analytics, API origin |
| dns-prefetch | Resolve a domain’s DNS early | Low | Fallback for older browsers |
Why Resource Hints Matter for Core Web Vitals and Conversions
Largest Contentful Paint is the metric most directly improved by preloading. If your LCP element is a hero image or a headline rendered in a web font, the browser often discovers that asset late, after parsing CSS or running script. Preloading it moves the request to the front of the queue and can shave hundreds of milliseconds off paint time. Our Largest Contentful Paint guide explains how to identify which element is the LCP candidate in the first place.
Prefetching improves perceived performance rather than a single lab metric. By fetching the next likely page during idle time, you make navigation feel instantaneous, which keeps users moving through a funnel instead of waiting at each step. Faster transitions reduce abandonment and lift conversions on multi-step journeys like signup flows and checkouts. The connection between speed and the metrics Google rewards is covered in our piece on Core Web Vitals and SEO.
How to Diagnose Missing or Misused Hints
- Lighthouse: The audit flags “Preload Largest Contentful Paint image” and “Preconnect to required origins” when it detects assets that would benefit from earlier fetching.
- PageSpeed Insights: Confirms the same opportunities against field data, so you know whether real visitors are losing time to late-discovered resources.
- DevTools Network panel: Inspect the waterfall and the Priority column. If your LCP image starts downloading late or at low priority, it is a preload candidate. Watch for preloaded resources that never get used within seconds, which is wasted bandwidth.
- Console warnings: Chrome warns when a preloaded resource is not used soon after load, which signals an unnecessary or mis-typed hint.
Concrete Fixes With Resource Hints
1. Preload the LCP Resource
Identify the largest above-the-fold element and preload it. For a hero image:
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
Always include the as attribute so the browser assigns the correct priority and applies the right content type. Omitting it can cause the resource to download twice.
2. Preload Critical Fonts
Fonts are discovered late because the browser must parse CSS before it knows they exist. Preload the one or two fonts used above the fold and add the crossorigin attribute for fonts, since they are fetched anonymously:
<link rel="preload" as="font" type="font/woff2" href="/inter.woff2" crossorigin>
3. Preconnect to Third-Party Origins
For domains you will definitely request from, like a font host or an analytics endpoint, open the connection early so the TLS handshake does not sit on the critical path:
<link rel="preconnect" href="https://fonts.example.com" crossorigin>
4. Prefetch Likely Next Pages
For pages a user is likely to visit next, prefetch the document or its JavaScript chunk during idle time. On a pricing page, prefetching the signup page means the transition feels instant when the user clicks.
<link rel="prefetch" href="/signup" as="document">
Common Mistakes to Avoid
- Preloading too much: Preloading many resources defeats the purpose, since everything at high priority means nothing is prioritized. Limit preloads to a small set of genuinely critical assets.
- Forgetting the
asattribute: Without it the browser may misjudge priority or download the file twice. - Prefetching things nobody visits: Aggressive prefetching wastes data, especially on mobile. Prefetch only high-probability next steps.
- Confusing preload and prefetch: Preloading a next-page resource hogs bandwidth from the current page, while prefetching a current-page asset arrives too late to help.
How Modern Stacks Handle Preloading and Prefetching
Next.js
Next.js prefetches linked pages automatically. Its link component prefetches the code for any in-viewport route during idle time, so client-side navigations feel instant without you writing a single hint. The font system preloads fonts and the image component sets priority on the LCP image when you flag it, generating the preload tags for you.
Framer
Framer applies these optimizations at the platform level. Pages are prefetched for fast navigation, the primary image and fonts are prioritized for quick first paint, and assets are served from a global CDN so the round trips are short to begin with. You do not hand-write link tags or reason about the as attribute, which removes a frequent source of mistakes. Combined with automatic image optimization, this is why Framer sites tend to post strong Largest Contentful Paint numbers. For the wider performance playbook, see our website speed optimization guide.
Resource Hint Checklist
- Preload the single LCP image or hero asset with
fetchpriority="high" - Preload only the fonts visible above the fold, with
crossorigin - Preconnect to font and API domains you always use
- Prefetch high-probability next pages during idle time
- Keep preloads to a short list so priorities stay meaningful
- Verify in DevTools that every preloaded resource is actually used
A Practical Workflow for Adding Resource Hints
Resource hints reward precision, so the workflow matters as much as the syntax. Adding hints blindly wastes bandwidth and can even slow the page, while adding them surgically produces clear gains. Here is the sequence we use.
Start by identifying the Largest Contentful Paint element. Run Lighthouse or use the DevTools performance panel to see which element Google counts as the LCP candidate. It is usually a hero image, a background image, or a headline rendered in a web font. You cannot preload the right thing until you know what the right thing is, and our Largest Contentful Paint guide walks through pinpointing it.
Once identified, preload that single resource with the correct as attribute and fetchpriority="high". Resist the urge to preload more than the one or two assets that genuinely gate first paint. Every additional high-priority preload dilutes the prioritization and can push your actual LCP resource later in the queue.
Next, handle connections. List the third-party origins your page always contacts, such as a font host or an analytics endpoint, and add a preconnect hint for each. Connection setup, including DNS lookup and the TLS handshake, can cost hundreds of milliseconds, and warming it early removes that delay from the critical path entirely.
Then turn to navigation. Map the most common next step from each key page, the pricing page leads to signup, the blog post leads to a related guide, and prefetch that destination during idle time. Prefetch only high-probability paths so you are not burning mobile data on pages most visitors never reach.
Finally, audit for waste. Reload with the DevTools console open and watch for warnings that a preloaded resource went unused, which signals a mis-typed or unnecessary hint. Check the network waterfall to confirm your preloaded LCP asset now starts early and at high priority. Verify the change in field data over the following weeks rather than trusting a single lab run.
Resource hints are a precision tool: a few well-placed tags can lift Largest Contentful Paint and make navigation feel instant. On a platform that applies them automatically, you get the benefit without the risk of misuse. To see how we build sites that load fast by default, browse our portfolio or check our pricing.
Frequently Asked Questions
What is the difference between preload and prefetch?
Preload fetches a resource the current page needs right away at high priority, such as the hero image or a critical font, to speed up the current render. Prefetch fetches a resource the user is likely to need on a future navigation at low priority during idle time, so the next page loads instantly. Preload is for now, prefetch is for next.
Can preloading slow down my site?
Yes, if you overdo it. Preloading too many resources forces them all to compete for high-priority bandwidth, which can delay the genuinely critical asset and waste data. Limit preloads to a small set of truly important resources, always include the as attribute, and confirm each preloaded file is actually used soon after it loads.
Does Framer handle preloading automatically?
Yes. Framer prioritizes the primary image and fonts for fast first paint, prefetches pages for quick navigation, and serves assets from a global CDN. You do not need to write preload or prefetch tags manually, which is part of why Framer sites perform well on Largest Contentful Paint.