If you’ve ever looked at a PageSpeed Insights report and seen the suggestion “Preload key requests,” you’ve bumped into one of the most misunderstood tools in web performance. It looks like a simple fix — add a line of HTML, get a faster page. In practice, it’s easy to use badly, and using it badly can actually slow your site down.
Let’s fix that. This guide explains what rel=”preload” really does, which assets on a WordPress page are worth preloading, why preloading too much backfires, and how AWP handles the trickiest part — the hero image — automatically.
What rel=”preload” actually does
By default, a browser discovers what it needs to load by reading your HTML from top to bottom. It finds a <link rel=”stylesheet”> tag, so it fetches that stylesheet. It finds an <img> tag, so it fetches that image. It finds a @font-face rule inside a stylesheet, so it fetches that font — but only after it has downloaded and parsed the CSS file the rule lives in.
That normal discovery process is efficient most of the time, but it has a weak spot: some resources are discovered late, even though they’re critical to what the visitor sees first. A background-image set in CSS, a web font referenced three files deep, or a large hero image that’s technically in the HTML but competing with dozens of other requests — all of these can end up loading later than they should.
rel=”preload” is a hint you add to your page’s <head> that tells the browser: “You’re going to need this resource soon and it’s important — start fetching it right now, at high priority, before you’d normally discover it.” For example:
<link rel=”preload” as=”image” href=”/wp-content/uploads/hero.avif” fetchpriority=”high”>
This doesn’t change what loads — it changes when the browser decides to start loading it, and how much priority it gets relative to everything else competing for bandwidth.
The best candidates for preloading
Not every resource deserves this treatment. Preload is meant for the handful of assets that are genuinely needed for the first thing your visitor sees. On a typical WordPress page, that shortlist usually looks like this:
- The LCP (Largest Contentful Paint) image. LCP is one of Google’s Core Web Vitals — it measures how long it takes for the biggest visible element (usually a hero image, banner, or large photo) to finish rendering. If that image loads late, your LCP score suffers, and so does the visitor’s sense that your page is “ready.”
- Critical web fonts. If your headline or body text uses a custom font, the browser can’t render that text properly until the font file arrives. Preloading the exact font file used above the fold avoids the flash of unstyled or invisible text some sites suffer from.
- Above-the-fold CSS. The styles that control what’s visible in the first screenful of content need to be available immediately. This is usually handled by inlining critical CSS directly in the <head> rather than preloading an external stylesheet, but the goal is the same: don’t make the browser wait for a full stylesheet download before it can paint what’s on screen.
A background image used as your hero (set via CSS background-image rather than an <img> tag) is a special case worth a quick note: because the browser can’t discover it until it has parsed the CSS that references it, it’s a common LCP bottleneck — and one of the reasons some themes prefer real <img> tags for hero content.
The real risk: over-preloading
Here’s the part that trips people up. Preload doesn’t create bandwidth out of nowhere — it just tells the browser to reprioritize. If you preload five images, three fonts, and a couple of scripts, you haven’t made your connection faster. You’ve told the browser that all of those things are equally urgent, which means they now compete with each other and with the resource that actually matters most.
The practical symptom is a page that feels slower to first paint even though “more things are being preloaded.” The browser’s priority queue gets crowded, actually-critical requests get delayed behind mostly-critical ones, and your LCP or First Contentful Paint numbers can get worse instead of better.
The rule of thumb: preload only the one or two assets that are truly needed for the first paint — typically the LCP image and, if applicable, one critical font. Everything else should load through normal discovery, or be deliberately deferred.
Preload vs. prefetch: not the same tool
It’s worth clearing up a common mix-up, because the two look similar in HTML but do opposite jobs:
- rel=”preload” fetches something the current page needs, right now, at high priority — for content the visitor is about to see immediately.
- rel=”prefetch” fetches something the next page might need, at low/idle priority, when the browser has spare capacity — a bet that the visitor will click through to another page soon.
Preload competes for bandwidth now because it’s urgent. Prefetch deliberately avoids competing for bandwidth because it’s a low-confidence guess about the future. Using one where the other belongs is a common cause of both slow first paints (prefetch used when preload was needed) and wasted bandwidth (preload used for things that aren’t actually urgent).
How AWP handles this automatically
Manually figuring out which image is your LCP element — and it can be different on mobile versus desktop, and different from post to post — is tedious to do by hand across a whole site. This is exactly the kind of decision AWP’s personalized optimization is built to make.
When you run an optimization, the AWP Exchange Server analyzes each page’s actual output and identifies which image is the real LCP element for that page, on that device. It never sees your image files or content — only sizing information — and nothing about your content ever leaves your server. AWP then applies the result locally, on your own WordPress install: the identified LCP image is served with loading=”eager” and fetchpriority=”high”, and a matching <link rel=”preload” as=”image” …> hint is added to the page’s <head>, pointing at the correctly sized image variant.
In other words, instead of guessing which image deserves the preload treatment (or preloading everything “just in case,” which — as covered above — backfires), AWP measures it per page and applies just the one hint that matters. Combined with AWP’s critical/deferred CSS handling, the result is a first paint that isn’t waiting on guesswork: the browser is told, accurately, what to fetch first.
Preloading is a precise tool. Used on the right one or two assets, it can meaningfully speed up how soon your page’s most important content appears. Used indiscriminately, it works against itself. If you’d rather not track LCP elements page-by-page across your site, AWP’s optimization handles that measurement and applies the hint for you, automatically.
