If you’ve spent any time digging into WordPress performance plugins or Core Web Vitals guides, you’ve probably run into two terms that sound almost identical: preload and prefetch. They’re both “resource hints” — small instructions in your page’s HTML that tell the browser to fetch something ahead of time. But they solve completely different problems, and mixing them up can actually slow your site down instead of speeding it up.

This guide breaks down exactly what each one does, when to use them, and why getting this right matters for real-world WordPress sites — from simple blogs to busy WooCommerce stores.

What is a resource hint?

Before comparing the two, it helps to know what they have in common. A resource hint is a line of HTML (or an HTTP header) that gives the browser advance notice about a resource — an image, a font, a script, a stylesheet — before the browser would normally discover it on its own.

Normally, a browser has to parse your HTML top to bottom, build the page structure, and only then figure out which images or fonts it needs. Resource hints let you skip ahead and say “you’re going to need this — go get it now” or “you might need this later — grab it when you have spare time.”

That difference in urgency is the whole story behind preload vs prefetch.

Preload: “I need this right now, for this page”

rel=”preload” tells the browser: this resource is required for the current page, and it’s important enough to fetch immediately, at high priority — often before the browser would otherwise discover it.

Typical candidates for preload:

• The LCP (Largest Contentful Paint) image — the largest visible element on screen, often a hero banner or featured product photo. LCP is one of Google’s Core Web Vitals, and it measures how long it takes for that biggest piece of content to finish rendering.
• Critical web fonts used in the initial viewport, so text doesn’t flash unstyled or invisible while the font loads.
• Above-the-fold CSS that’s essential for the first paint of the page.

Because preload competes for bandwidth with everything else the browser is already fetching, it’s a tool to use sparingly and deliberately. Preloading too many things defeats the purpose — you end up with a traffic jam of “urgent” requests, and nothing actually gets priority. The rule of thumb: preload only what’s needed to render what the visitor sees first.

Prefetch: “I’ll probably need this next, whenever there’s time”

rel=”prefetch” is the opposite instinct. It tells the browser: this resource probably isn’t needed on the current page, but it might be needed on the next page the visitor navigates to. Fetch it, but only during idle time, at low priority, so it never competes with anything the current page actually needs.

Typical candidates for prefetch:

• The main image or assets on a page your visitor is likely to click next (for example, prefetching a product page when someone is hovering over its link in a category grid).
• Assets for the next step in a checkout flow.
• A frequently-visited page, like the one linked in your primary navigation.

Because prefetch is low priority, the browser is free to deprioritize or skip it entirely if it’s busy with more important work. That’s by design — prefetch should never slow down the page the visitor is currently looking at.

Preload vs prefetch, side by side

The short version: preload is about right now, prefetch is about next. If you only remember one thing from this table, remember that distinction — it will steer you correctly in almost every situation.

The highest-impact quick win: preload your LCP image

If you’re auditing an existing WordPress site and want the single change most likely to move the needle on Core Web Vitals, it’s this: preload the hero or LCP image.

Here’s why it matters so much. Browsers discover images the normal way — by parsing the HTML and hitting the <img> tag — which can happen surprisingly late in the page load, especially if that image is set as a CSS background or loaded via a slider script. Every millisecond between “browser starts loading the page” and “browser starts fetching the LCP image” is time added directly to your LCP score.

Preloading that one image tells the browser to start fetching it as early as possible, in parallel with everything else — often shaving a meaningful chunk off your LCP time without touching anything else on the page.

The catch: this only helps if you preload the right image (the actual LCP element, not just any hero-looking graphic) and the right size for the device viewing the page. Preloading the wrong image, or a needlessly large one, wastes the same bandwidth budget you’re trying to protect.

How AWP handles this automatically

Manually identifying the LCP element, picking the right image size per device, and adding a correctly-configured preload tag is fiddly — and it can change over time as you update content, swap themes, or edit a page.

This is exactly the kind of decision AWP (Accelerate Website Pages) automates. When you run a personalized optimization, the AWP Exchange Server analyzes the page’s actual public output and determines the best image size for each device and which CSS is critical for first paint. AWP then applies that result on your own server: it encodes right-sized AVIF image variants into your own WordPress media library and serves them with a responsive srcset, along with inline critical CSS and the correct lazy-loading and LCP priority hints — including preloading the LCP image itself.

Because the analysis only measures image dimensions (never image content, and nothing is retained), and because everything is applied at the output layer — your original posts, pages, and uploaded images are never modified — the whole process is safe to run and fully reversible.

Wrapping up

Preload and prefetch are both resource hints, but they point in opposite directions: preload accelerates what’s needed right now, prefetch gets a head start on what’s needed next. For most WordPress sites, the biggest, safest win is preloading the LCP image on your key landing and product pages — and that’s precisely the kind of per-page, per-device decision AWP is built to make for you automatically, every time you run an optimization.