Some genuinely critical resources are discovered late by the browser's natural parsing process — rel="preload" corrects this specific timing problem, with a precise behavior and a mandatory, easy-to-miss requirement worth understanding fully.
1Fetching Early, Without Applying Or Executing
<link rel="preload" href="hero.jpg" as="image"> instructs the browser to begin fetching that specific resource immediately, at high priority, well before the browser's natural parsing process would otherwise discover it — solving a genuine timing problem for resources referenced late, such as a hero image only discoverable after parsing a linked CSS file's background-image declaration.
Critically, preload strictly fetches the resource into the browser's cache — it does not apply CSS, execute a script, or render an image automatically. The resource still needs to be used normally elsewhere in the document (a real <img> tag, an actual stylesheet <link>, a real <script> tag) at which point the browser retrieves it instantly from cache instead of fetching it anew.
2The Mandatory, Easily-Missed as Attribute
The as attribute — declaring the resource's type (image, script, style, font, fetch, and others) — is required for preload to function correctly, serving two purposes: setting the correct network request priority for that resource type, and letting the browser match the preloaded resource to its actual later use in the page.
A missing or incorrect as value is a frequent, easy-to-miss implementation mistake that commonly results in the resource being fetched a second time when actually used, since the browser can't confidently confirm the cached preloaded copy matches. Font preloads have an additional common gotcha: they typically require crossorigin as well, even for same-origin fonts, due to how font fetching's CORS mode works.
3Selective Use, Not Blanket Application
Because preload requests elevated priority for a resource, its value comes specifically from being applied selectively to genuinely critical, otherwise-late-discovered resources — most commonly the actual LCP candidate image or a critical custom font blocking text rendering.
Applying it broadly to many resources dilutes the benefit entirely: since network bandwidth and connection limits remain finite regardless of how many resources are marked high-priority, over-preloading means everything competes for the same limited early capacity, and nothing is actually meaningfully prioritized above anything else — directly undermining the technique's entire purpose.
4Step-by-Step Breakdown
Fetching A Resource Before The Parser Would Find It. Some critical resources — a hero image referenced deep in CSS, a web font, a key script — aren't discovered by the browser's parser until relatively late, delaying when they start downloading. rel="preload" tells the browser to fetch them immediately, as a high priority, well before that natural discovery point.
preload Fetches Early, Without Blocking Or Executing. <link rel="preload" href="..." as="..."> tells the browser to fetch that specific resource with high priority, as early as possible — but critically, only fetches it; it doesn't apply, execute, or render the resource, which still happens at its normal point of use.
What preload Actually Does. Does <link rel="preload" href="hero.jpg" as="image"> alone cause the image to actually display on the page?
- →Yes, preload alone renders the image automatically
- →No, it only fetches the resource early; a separate <img> tag (or CSS) is still needed to actually display it
- →Only in Firefox; other browsers display it automatically
The as Attribute Is Mandatory And Must Be Correct. as="..." tells the browser what type of resource is being preloaded (image, script, style, font, etc.), which the browser uses to set the correct request priority and, critically, to determine whether a cached copy can actually be reused later — an incorrect or missing as value commonly causes the resource to be fetched twice.
The as Attribute Requirement. What commonly happens when a preload link is missing a correct as attribute?
- →The preload is simply ignored with no consequence
- →The resource is often fetched twice, since the browser can't match the preloaded copy to its actual later use
- →The entire page fails to load
Reserve preload For Genuinely Critical, Late-Discovered Resources. Overusing preload on many resources dilutes its value entirely — since it requests high priority for everything, preloading too much means nothing is actually prioritized, competing for the same limited early bandwidth as truly critical resources like the LCP candidate.
Preload Overuse. What happens if a page preloads dozens of resources indiscriminately?
- →All resources load meaningfully faster with no downside
- →The prioritization benefit is diluted, since limited early bandwidth is now split across everything
- →The browser automatically rejects preloads beyond a certain count
preload Mastered. You now know that preload only fetches a resource early without applying or executing it, that the as attribute is mandatory and must correctly match the resource type to avoid duplicate fetches, and why preload should be reserved for genuinely critical, late-discovered resources rather than applied broadly.
Preload A Critical Stylesheet. Preloading a stylesheet with as="style" fetches it early without blocking on discovery order.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Preloading Critical Fonts Reduces Flash Of Invisible/Unstyled Text, Benefiting Reading Comprehension
Faster, more consistent text rendering particularly benefits users with cognitive or reading-related accessibility needs who are sensitive to abrupt visual changes during reading.
SEO Implications
- 1
Correctly Preloading The Actual LCP Candidate Is One Of The Most Direct, Targeted LCP Optimizations Available
Since preload specifically accelerates when the critical resource begins downloading, applying it precisely to the true LCP element directly and measurably improves that Core Web Vitals metric.
Best Practices
Always Include A Correct as Attribute (And crossorigin For Fonts) On Every preload Link
Missing or incorrect values are a common cause of the resource being fetched twice, which actively harms performance rather than helping it — the opposite of the intended effect.
Reserve preload Specifically For The True LCP Candidate Or Other Genuinely Critical, Late-Discovered Resources
Selective application preserves its actual prioritization value; broad application dilutes it entirely since finite bandwidth still has to be shared.
Frequent Bugs
A preloaded font appears to load twice in the network waterfall, with no performance benefit observed.
Verify the as="font", correct type, and crossorigin attributes are all present and correct — any mismatch commonly causes a duplicate fetch.
A page preloads a dozen images, but overall load performance doesn't meaningfully improve.
Reduce preload usage to only the genuine LCP candidate; broad preloading dilutes the prioritization benefit across too many competing resources.
Real-World Examples
Correctly Preloading The LCP Hero Image
A landing page's hero image, the confirmed LCP candidate, preloaded with correct attributes.
<link rel="preload" href="/hero.webp" as="image" fetchpriority="high">
<!-- Later in body: -->
<img src="/hero.webp" alt="..." width="1200" height="600">