Preload

Discovery and initiation

When a browser encounters <link rel="preload"> in the HTML head or receives an HTTP Link header with rel=preload (optionally delivered via 103 Early Hints), it schedules the referenced resource for an early fetch. The request is initiated independently of the normal parser discovery path, which means the asset can be downloaded before the corresponding <img>, CSS background-image, @font-face, or <script> is parsed. This early initiation shortens the time to first byte for critical assets and can shift them to a higher priority queue, especially when the as attribute conveys the correct type.

Preload only makes the resource available; it does not render, apply, or execute it. The asset is stored in the appropriate cache (memory/HTTP cache) and will be reused if a later matching reference is encountered. For that reuse to succeed, the URL and key characteristics must match: the as value (image, font, style, script), crossorigin where relevant, and for responsive images the imagesrcset/imagesizes parameters. Mismatches can lead to duplicate downloads or the preloaded response being ignored.

Scope and relevance

Preload is most relevant to assets that materially affect the first screen and key user-centric performance metrics. Typical candidates include the LCP image (often a hero image), web fonts that would otherwise block or cause layout shifts, and a page’s main stylesheet if it cannot be inlined. For images specifically, preloading is valuable when the browser’s speculative parser will not discover the asset early—such as CSS background images, images injected by JavaScript, or markup that sits far down the document.

From an SEO perspective, preload is an indirect lever. Search engines do not evaluate the hint itself as a ranking factor, but improvements to Core Web Vitals—particularly LCP—can support better search performance. In analytics terms, preload can reduce time-to-paint variability across devices and networks, narrowing long-tail latency for users on high RTT connections or with constrained bandwidth.

Overview

Preload is a declarative scheduling signal rather than a rendering instruction. By declaring a resource early with as=image, as=font, as=style, or as=script, the browser can set an appropriate priority and request headers (for example, including an Origin header for fonts with crossorigin). The resource is fetched immediately, subject to connection limits and HTTP/2 or HTTP/3 prioritisation, then placed in cache for reuse when the page actually references it. If the preload arrives alongside 103 Early Hints, the browser can begin fetching even before the final HTML response headers are received.

Preload is most effective when the declared resource is truly on the critical path. For images, that often means the exact LCP candidate at the viewport’s initial size and DPR; for fonts, the subsets that render above-the-fold text; and for CSS, the primary stylesheet if critical CSS cannot cover the initial view. Overuse dilutes its effect by increasing queue contention and can slow other critical downloads. The goal is targeted, minimal preloading that aligns with real user navigation paths.

Preload, preconnect, and prefetch are related resource-hint mechanisms that target different stages of the network pipeline and have different scheduling semantics.

Stages and semantics

These hints operate at distinct points in the network pipeline. Preconnect warms up the path to an origin (DNS, TCP, TLS), reducing connection setup latency without transferring content. Preload fetches a specific resource for the current page immediately, elevating its scheduling priority so it is available to apply as soon as the parser reaches it. Prefetch fetches a resource opportunistically at a low priority for likely future navigations or late-in-lifecycle needs, aiming not to interfere with the current page’s critical path.

Scheduling differs across these hints. Preload tends to be queued as a high or medium-high priority request consistent with its as type and can be further influenced by Priority Hints (fetchpriority). Preconnect is an idle-time, low-cost optimisation that competes mainly for connection slots rather than bandwidth. Prefetch is explicitly low priority and should be cancelled by the browser if it risks contending with active, render-critical transfers. Choosing among them depends on whether you need an origin ready, a specific resource immediately, or a likely resource later.

Key risks

While preload can accelerate critical rendering, it also amplifies the cost of wrong predictions. Over-preloading increases bandwidth contention, delaying other essential resources. Preloading the wrong responsive image candidate, omitting crossorigin for fonts or third-party images, or failing to match imagesrcset/imagesizes can prevent reuse and trigger duplicate transfers. Aggressive preloading that outpaces the user’s device or connection can raise CPU, memory, and radio usage, degrading battery life on mobile devices without visible benefit.

Implementation details matter. Missing or incorrect as values reduce the browser’s ability to prioritise and validate the response. Preloading non-cacheable or dynamically variant resources (for example, personalised images) risks staleness or cache misses. Some browsers place caps on the number of active preloads and may cancel unused ones; preloading far below the fold often wastes work. Use of preload via HTTP headers without tight scoping can inadvertently apply across templates, resulting in recurrent downloads that are not actually needed on many pages.

Implementation notes

For images, declare <link rel="preload" as="image" href="..."> as early as possible and include responsive metadata when applicable: imagesrcset and imagesizes should mirror the eventual <img> attributes so the fetched candidate matches the browser’s selection logic. When the image is on a different origin or served with CORS checks (common for fonts and some CDNs), add crossorigin so the preloaded response is reusable by the rendering element. For fonts, include as="font" and a type (for example, type="font/woff2") to improve validation and caching behaviour.

Where server control is available, the HTTP Link header can move discovery even earlier, particularly with 103 Early Hints, reducing time spent idle before HTML parsing begins. Limit usage to truly critical assets—commonly one LCP image, the primary stylesheet if not inlined, and essential font subsets. Priority Hints (fetchpriority) can complement preload by nudging the relative weight of concurrent transfers; for example, an LCP image may be preloaded and also marked high priority, while secondary images remain default or low. Monitor impact with request waterfalls and Core Web Vitals to validate that preloads are helping rather than shifting contention elsewhere.

Comparisons

• Preload vs preconnect: Preconnect performs DNS/TCP/TLS handshakes early but transfers no bytes of the resource; preload downloads the resource itself for immediate reuse.
• Preload vs prefetch: Prefetch is low priority and speculative, best for next-page or late-stage assets; preload is for current-page, render-critical assets and competes for bandwidth now.
• Preload vs Priority Hints (fetchpriority): Priority hints adjust scheduling of discovered resources; preload forces early discovery and fetch. They can be combined but serve different roles.
• Preload vs server push (deprecated): HTTP/2 server push attempted to send assets unrequested; preload keeps the decision client-driven and is widely supported without the downsides of push.
• Preload vs lazy-loading: Lazy-loading delays non-critical image fetches; preload accelerates a select few critical assets. Both can coexist to shape the waterfall.

FAQs

Should an LCP image be preloaded or just given a high fetch priority?

Both approaches can work. If the LCP image appears very early in the HTML, setting fetchpriority="high" on the <img> often suffices. Preload is helpful when the image is discovered late—such as a CSS background or content injected by JavaScript—or when server-sent headers can initiate the fetch before HTML parsing. Many teams preload exactly one LCP candidate and rely on priority hints for the rest.

How many resources should be preloaded on a typical page?

Keep the set small—often one LCP image, one primary stylesheet (if not inlined), and one or two critical font subsets. Each additional preload competes for connection slots and bandwidth, increasing the risk of slowing other critical transfers. Real-world constraints such as HTTP/2 multiplexing, device capability, and network conditions mean results vary; validating with request waterfalls and Core Web Vitals is advisable before scaling up usage.

Is it better to use HTML markup or the HTTP Link header for preload?

The HTTP Link header can reach the browser earlier—especially with 103 Early Hints—because it does not wait for HTML parsing. However, HTML markup is easier to scope to specific templates and to keep in sync with the actual DOM usage. Many sites combine both: headers for invariant, global assets (like a core font subset) and HTML for page-specific resources (like the LCP image).

Why does a preloaded resource sometimes download twice?

Duplicate downloads usually stem from attribute mismatches. If the preloaded request lacks the correct as type, crossorigin, or responsive attributes (imagesrcset/imagesizes) used by the eventual element, the browser may treat it as a different cache key. Ensure the URL and relevant attributes match exactly. For fonts, omitting crossorigin prevents reuse; for images with srcset, preloading a different resolution than the browser selects will not be reused.

Does preload improve Core Web Vitals on all networks and devices?

Preload often improves LCP and can stabilise rendering across high-latency connections by pulling critical bytes forward. Gains vary with origin distance, server responsiveness, and how accurately the preloaded assets match what the browser ultimately needs. On very constrained devices or networks, excessive preloading can backfire by starving competing transfers; careful selection and measurement are key to net-positive outcomes.