Performance Oct 2, 2026 6 min read

How Resource Hints Like Preload and Prefetch Speed Up Navigation

Preload, prefetch, and preconnect are small HTML tags that can meaningfully cut page load time optimization efforts, if you know when to use each one and when you're overdoing it.

Your browser is smarter than most people give it credit for. It can start fetching resources before it even needs them, if you tell it to. That's the whole idea behind resource hints like preload, prefetch, preconnect, and dns-prefetch. They're small HTML tags that give the browser a heads-up about what's coming next, and used correctly, they can shave hundreds of milliseconds off your page load time optimization efforts without touching your server or your codebase much at all.

Let's break down what each hint actually does, when to use it, and where people tend to mess it up.

What Resource Hints Actually Do

Browsers normally discover resources as they parse your HTML, line by line. A stylesheet linked near the bottom of your head tag gets requested later than one near the top. A font referenced inside a CSS file doesn't get requested until the browser has already downloaded and parsed that CSS. This waterfall effect adds up.

Resource hints let you jump the queue. You're telling the browser, "Hey, you're going to need this soon, start now instead of waiting to discover it naturally."

Preload: For Resources You Know You Need Right Now

Your largest contentful paint (LCP) image, like a hero banner
Critical web fonts that would otherwise cause a flash of invisible text
A key CSS or JS file that's normally discovered late

Here's a typical example for a hero image:

And for a font:

In testing, preloading an LCP image has reduced LCP scores by 300-600ms on sites where the image was previously discovered through a background-image CSS rule. That's a meaningful chunk when Google's threshold for "good" LCP is 2.5 seconds.

The catch: preload is a promise. If you preload something and then never actually use it on the page, Chrome will throw a console warning and you've wasted bandwidth for nothing. Only preload what you're certain the page needs.

Prefetch: For Resources You'll Need Soon, Just Not Yet

This is the hint behind the "instant" feeling you get on sites like Google search results or well-built ecommerce stores. When a user hovers over a link, or when a page finishes loading and the browser has spare capacity, you can prefetch the next likely page:

Some frameworks, like Next.js, do this automatically for any link visible in the viewport. If you're building this manually, a common pattern is to prefetch on hover with a short delay (around 65ms) to avoid wasting requests on accidental mouse-overs.

Prefetching the next page in a checkout flow, for example, can make the transition feel instant because the HTML, CSS, and JS are already sitting in the browser cache by the time the user clicks.

Preconnect and DNS-Prefetch: For Third-Party Origins

If your page loads resources from other domains (Google Fonts, a CDN, an analytics script, a payment gateway), the browser has to do a DNS lookup, TCP handshake, and TLS negotiation before it can even start downloading anything from that domain. That round trip alone can cost 100-300ms depending on the user's connection.

preconnect does all three steps ahead of time:

dns-prefetch is a lighter version that only resolves DNS, useful as a fallback for browsers that don't support preconnect, or for origins you're not 100% sure you'll use:

A good rule of thumb: preconnect to origins you know you'll load resources from almost immediately, and keep the list short. Each preconnect opens a connection that consumes CPU and memory, so preconnecting to ten different domains can actually backfire and slow things down.

How Many Resource Hints Is Too Many

This is where a lot of well-intentioned developers go wrong. Resource hints are not free. Each one competes for bandwidth and connection slots with the resources your page actually needs right now.

Limit preconnect to 3-4 critical third-party origins max
Only preload resources that are used above the fold and would otherwise be discovered late
Don't prefetch every link on a page, pick the 1-3 most likely next destinations
Test with Chrome DevTools' network panel to confirm the hint is actually changing request timing

We've seen sites that preloaded a dozen fonts, half of which weren't even used on first paint. The result was a slower initial render, not a faster one, because the browser was busy fetching things the user didn't need yet.

Measuring the Impact

Don't guess, measure. Run your page through Lighthouse or WebPageTest before and after adding hints, and watch these specific numbers:

Time to First Byte (TTFB) - unaffected by resource hints, but good to have as a baseline
Largest Contentful Paint (LCP) - should drop when you correctly preload the LCP resource
Total Blocking Time (TBT) - watch for regressions if you preload too much JS

If you're not sure which metrics matter most or how to read the report, our page speed analysis tooling breaks these down without requiring you to decode raw waterfall charts.

Where This Fits With WordPress

If you're running WordPress, you don't necessarily need to hand-write these tags. Good optimization tooling handles LCP and font preloading as a configurable setting, so you can flag your hero image or key fonts without editing theme files. That's exactly the kind of thing we built into our own optimization dashboard, where a Preload and LCP tab lets you set this up in a couple of clicks rather than hunting through your theme's header template.

We've covered the broader picture of what actually helps WordPress speed in WordPress Speed Optimization: A Practical Guide That Actually Works, and if font rendering specifically has been bugging you, How Font Loading Strategies Prevent the Flash of Invisible Text From Slowing You Down goes deeper into that piece.

The Takeaway

Resource hints are cheap to add and, used thoughtfully, genuinely effective for page load time optimization. Preload what the current page needs right now. Prefetch what the user will probably click next. Preconnect to the handful of third-party origins you can't avoid. And always measure before and after, because the line between "helpful hint" and "wasted bandwidth" is thinner than it looks.

Start with your LCP image and your most-used web font. Those two changes alone usually deliver the biggest visible improvement for the least amount of effort. For a deeper look at related caching strategies that compound these gains, see our overview of server-side caching.