Web Performance & Standards
What is preloading?
Preloading is a browser performance technique that instructs the browser to fetch specific resources needed for the current page as early as possible, before the browser would normally discover and request them through its regular parsing and rendering process. Where prefetching speculatively loads resources for future navigations preloading prioritises resources for the current page, ensuring critical assets are available sooner in the loading sequence than they would otherwise be.
The <link rel="preload"> HTML element is the standard preloading mechanism, declaring in the document head that a specific resource is needed with high priority and that the browser should begin fetching it immediately, before it encounters the resource reference later in the document. This early fetch declaration moves critical resource loading earlier in the timeline, reducing the gap between when the browser receives the HTML and when critical resources are available for rendering.
Preloading is most valuable for resources that are discovered late in the browser’s normal loading sequence, resources that would otherwise create bottlenecks by not being known about until the browser has parsed deep into the HTML or executed JavaScript. A hero image defined in CSS would not be discovered until the browser downloads and parses the CSS file, preloading it from the HTML head eliminates this discovery delay. A critical font referenced inside a CSS file would not be discovered until after CSS parsing, preloading moves its fetch to the earliest possible moment.
For redirect management preloading is relevant as a performance optimisation tool for destination pages that benefit from early resource loading, and for understanding how preload hints interact with the performance cost of redirect chains. A destination page that uses preloading effectively minimises the LCP impact of any redirect overhead by ensuring its critical resources load as quickly as possible once the destination page’s HTML is received.
How preloading works
Preloading operates through a declarative hint in the HTML that instructs the browser’s preload scanner, a lightweight HTML parser that runs ahead of the main parser, to begin fetching specified resources before normal document parsing would discover them.
The browser’s preload scanner, modern browsers employ two parallel HTML parsing processes. The main parser processes the full document, building the DOM, encountering resource references, and queuing resource loads. The preload scanner, a faster, lighter scanning pass, looks ahead in the HTML looking for resource references to begin fetching in parallel with the main parser’s work. Preload hints, <link rel="preload"> elements, in the document head are discovered by the preload scanner immediately, instructing it to begin fetching the specified resources at the highest priority.
Fetch priority, preloaded resources are fetched at high priority, competing with other high-priority resources like render-blocking CSS and critical scripts. The fetchpriority attribute provides additional control over relative priority within the high-priority queue:
fetchpriority="high", fetch with the highest priority, appropriate for the LCP image. fetchpriority="low", fetch with lower priority within the preload category. fetchpriority="auto", browser determines appropriate priority, the default.
The as attribute, required for <link rel="preload">, specifies the type of resource being preloaded. The as attribute enables the browser to:
Apply the correct content security policy for the resource type. Set appropriate request headers, Accept header matching the resource type. Prioritise the resource correctly, images have different priority than scripts. Avoid duplicate fetches, matching the preloaded resource with the subsequent request that uses it.
Valid as values, image, style, script, font, fetch, document, track, worker, audio, video.
Cross-origin preloading, resources from different origins, particularly fonts, require the crossorigin attribute on the preload hint to use the correct CORS fetch mode. Without crossorigin on a font preload the browser makes two separate fetches, one for the preload and one when the font is actually used, defeating the purpose of preloading.
Resources that benefit from preloading
Different resource types benefit from preloading to different degrees, the benefit is proportional to how late the resource would normally be discovered without preloading.
LCP images, the highest-impact preload target for most pages. The LCP element, typically a hero image or featured product image, is often referenced in CSS rather than directly in HTML or is not the first image in the document. Without preloading the browser discovers the LCP image only after downloading and parsing CSS, adding the CSS download time to the LCP image discovery delay. Preloading the LCP image from the HTML head eliminates this delay, the browser begins fetching the LCP image while CSS is still downloading.
The imagesrcset and imagesizes attributes on preload hints enable preloading responsive images, allowing the browser to select and preload the appropriately sized image variant before it encounters the <img> element.
Web fonts, fonts referenced in CSS are discovered only after the browser has downloaded and parsed the CSS file. Without preloading the font loading sequence is: download HTML, download CSS, parse CSS, discover font reference, download font. With preloading the font begins downloading alongside CSS, reducing the font loading delay and minimising flash of unstyled text.
Only preload fonts used in above-the-fold content, fonts only used below the fold do not benefit from preloading and add unnecessary high-priority network competition.
Critical CSS not in the HTML head, CSS loaded through JavaScript or deferred CSS that is actually needed for above-the-fold rendering can be preloaded to ensure it is available before it is executed:
JavaScript modules for immediate execution, JavaScript modules that are needed immediately on page load, initialisation scripts, framework chunks, benefit from preloading when they are not directly referenced in the initial HTML:
API responses for server-side rendering, for server-rendered pages that require data from an API endpoint preloading the API response as a fetch request can overlap the API call with HTML transmission, reducing the data-loading delay for API-dependent content:
Preloading vs prefetching, the key distinction
Preloading and prefetching are both speculative resource loading techniques, but they serve different purposes and have different priority characteristics.
Preloading, current page resources, <link rel="preload"> is for resources needed by the current page. The browser treats preloaded resources as high priority, necessary for the current page’s correct rendering. Preloaded resources are fetched immediately, competing with other high-priority resources. If a preloaded resource is not used within a few seconds after the page loads the browser generates a warning, unused preloads waste bandwidth and compete with truly needed resources.
Prefetching, future navigation resources, <link rel="prefetch"> is for resources likely needed in future navigations. The browser treats prefetched resources as low priority, fetching them during idle time without competing with current page resources. Prefetched resources are stored for potential future use, not for the current page.
The wrong technique wastes resources, using preload for future navigation resources wastes bandwidth and degrades current page performance, the browser fetches future page resources at high priority competing with current page resources. Using prefetch for current page critical resources is equally wrong, low-priority fetching means the resource may not arrive in time for the current page’s rendering needs.
Preloading and performance metrics
Preloading directly improves specific performance metrics, the impact is measurable and significant for correctly targeted resources.
LCP improvement, preloading the LCP image is among the most reliable and impactful LCP optimisations available. Lighthouse and PageSpeed Insights explicitly recommend preloading LCP images when they are not discovered early in the document. Studies show that LCP image preloading can improve LCP by 200-500ms, moving pages from needs improvement to good LCP thresholds.
The improvement comes from eliminating the resource discovery delay, the LCP image begins downloading when the preload hint is discovered in the HTML head rather than after CSS parsing completes. The combined time for CSS download and parse, which could be several hundred milliseconds, is eliminated from the LCP critical path.
TTFB interaction, preloading does not affect TTFB, the time to receive the first byte of the HTML response. Preloading begins after the HTML arrives. However preloading can prevent the LCP from being dominated by post-TTFB resource discovery delays, even with high TTFB pages can achieve good LCP if critical resources are preloaded effectively.
CLS improvement, preloading images with declared dimensions does not directly reduce CLS, dimension declarations prevent layout shifts regardless of load timing. However preloading fonts, preventing late font loading and text reflow, can eliminate font-swap related CLS. Fonts that arrive before text is rendered do not cause reflow, the text renders immediately in the web font without a fallback font intermediate step.
Preloading and redirect management
Preloading interacts with redirect management in a few specific ways, primarily relevant for destination pages that use preloading for performance optimisation.
Preloading across redirects, preload hints defined on a redirect source page, in HTML that the browser briefly receives before following a redirect, are generally not processed. The browser follows the redirect and processes the destination page’s HTML, preload hints on the redirect source are not acted upon. Preload hints should be defined on the final destination page, not on redirect source pages.
For pages served through redirect chains, common for brand protection domains, legacy URLs, and campaign redirect URLs, ensuring the final destination page implements effective preloading is the appropriate approach. The redirect adds TTFB overhead, effective preloading on the destination minimises the subsequent resource loading time, partially offsetting the redirect’s LCP impact.
Edge-side preload headers, some infrastructure, including CDN platforms, support adding Link preload headers to responses through server configuration:
This server-side preload header approach can be applied through CDN rules or edge functions, enabling preloading for pages where the HTML cannot be modified directly. For redirect management platforms that serve HTTPS redirect responses adding preload headers to redirect responses would be unusual, the redirect response body is not rendered so preloading is not applicable to the redirect itself.
Common preloading mistakes
Preloading resources not used on the current page, triggering browser warnings and wasting bandwidth on resources that are never used. Every preloaded resource should be used by the current page within a reasonable time. Audit preload implementations to verify each preloaded resource is actually consumed.
Preloading too many resources, preloading many resources simultaneously adds them all to the high-priority fetch queue, competing with each other and with genuinely render-blocking resources. Focus preloading on the one or two resources with the highest impact, typically the LCP image and critical fonts.
Missing crossorigin on font preloads, the most common font preloading mistake. Without crossorigin the browser makes two separate font requests, one speculative preload and one actual request, wasting bandwidth and providing no performance benefit. Always include crossorigin on font preload hints.
Preloading when prefetching is appropriate, using <link rel="preload"> for resources needed in future navigations rather than <link rel="prefetch">. Preloaded future navigation resources compete with current page resources, degrading current page performance without providing additional benefit over prefetch for future navigations.
Not using fetchpriority="high" for LCP images, adding preload without explicitly marking the LCP image as high fetch priority. The browser may deprioritise the preloaded image if other resources compete for bandwidth. fetchpriority="high" on the LCP image preload ensures the browser treats it as the most important resource to fetch.