Preload (Resource Hint)

Preload is a resource hint — a small instruction you give the browser in HTML — that says 'fetch this specific asset now, at high priority, because the current page is going to need it.' Written as a link tag with rel='preload', it targets things the browser would otherwise discover late: a web font buried in a stylesheet, the hero image at the top of the page, a critical script, or a key CSS file. Normally the browser only learns it needs those resources after parsing the markup or the CSS, which can leave them arriving too late and stalling the render. Preload jumps the queue: it tells the browser about the resource up front so the download starts immediately, in parallel with everything else. The asset is then sitting in the cache the moment the page actually asks for it, shaving time off how quickly the page becomes usable.

Preload matters because page speed is a ranking and conversion factor, and much of the delay in a slow page comes from critical resources being fetched too late. Preloading the right assets can meaningfully improve metrics like Largest Contentful Paint, since the browser starts pulling the hero image or the display font before it would have discovered them on its own. But preload is a scalpel, not a firehose. Because it fetches at high priority right away, preloading too many things — or the wrong things — steals bandwidth from resources the page needs even sooner, and can make performance worse, not better. The rule is to preload only a small number of genuinely critical, above-the-fold assets that the browser would otherwise find late. Used sparingly and deliberately, preload is one of the sharpest tools for closing the gap between when a page loads and when it feels ready.

Preload is one of a family of resource hints, and it is constantly confused with its siblings prefetch and preconnect, which do genuinely different jobs. Preload is about the current page: fetch a critical asset now, at high priority, because this page needs it very soon. Prefetch is about the next page: fetch an asset at low priority during idle time because the user will probably navigate to it soon — the article they are likely to click, the next step in a funnel. The two differ in both priority and timing: preload is urgent and for the here-and-now; prefetch is speculative, low-priority, and for the near future. Using preload where you mean prefetch wastes high-priority bandwidth on something not needed yet; using prefetch where you mean preload leaves a critical current-page asset arriving too late. The question to ask is always 'this page, or the next one?'

Preconnect is the third sibling, and it solves a different part of the problem: not the asset itself, but the connection to the server that holds it. Setting up a connection to another origin — the DNS lookup, the TCP handshake, the TLS negotiation — takes time before any file can be downloaded. Preconnect warms up that connection early so that when the browser does request a resource from, say, a font host or an analytics domain, the expensive setup is already done. So the trio divides the work cleanly: preconnect opens the door to a third-party origin ahead of time; preload fetches a specific known asset for the current page; prefetch grabs an asset for a page the user has not visited yet. They are complementary, not interchangeable. A well-tuned page might preconnect to a font provider, preload the specific font file it needs, and prefetch the likely next page — each hint doing exactly its own job.

Using preload well is an exercise in restraint. Reserve it for a handful of assets that are both critical to the initial render and discovered late by the browser — typically the LCP hero image, a web font that would otherwise cause a flash of unstyled text, or a render-blocking script the parser meets too late. Specify the resource type correctly with the 'as' attribute, and for fonts include the cross-origin setting, or the browser may fetch the file twice and waste the effort. Measure before and after with real performance tooling, because preload's whole value is empirical: it should improve LCP or first render, and if it does not, remove it. Above all, resist preloading everything. Each preload competes for high-priority bandwidth, so a long list dilutes the benefit and can delay the very assets you most need. A few well-chosen preloads beat a page full of them.

The failures are mostly overuse and mismatch. Teams preload dozens of assets in the hope of a blanket speed-up and instead slow the page, because everything at high priority means nothing is truly prioritized. They preload resources that are not actually critical or that the browser already finds early, spending effort for no gain. They confuse preload with prefetch, fetching next-page assets at urgent priority or current-page assets too lazily. And they forget the details — the wrong 'as' type or a missing cross-origin flag on a font — which causes double downloads that erase the benefit. The discipline is to preload a small, measured set of genuinely critical, late-discovered assets, declare them correctly, verify the improvement with real metrics, and reach for prefetch or preconnect when the job is actually about the next page or the connection rather than a known current-page asset.

Preload is a value of the HTML link element's rel attribute, defined in the W3C Preload and Resource Hints specifications to control how early and how urgently the browser loads a resource.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where preload (resource hint) is a core concern: