Resource hints look like free performance wins: a few extra tags in your document head, and the browser supposedly does the rest. In practice, preload, prefetch, and preconnect each solve a narrow problem, and using them outside that narrow lane can add latency instead of removing it. Here is what each one actually does, when it earns its place in your markup, and where site owners commonly overdo it.
What these hints actually tell the browser
All three are <link> tags with a rel attribute that nudge the browser’s network and resource scheduler. They do not change what loads, only when and how eagerly.
- preconnect: open the DNS, TCP, and TLS handshake to another origin before you actually need a resource from it.
- preload: fetch a specific resource on the current page early and at high priority, because you know the browser will need it soon.
- prefetch: fetch a resource at low priority, usually for a future navigation, because the user is likely to need it next.
There is a fourth, older hint, dns-prefetch, which does only the DNS lookup piece of what preconnect does. It is cheaper and a reasonable fallback for origins you are not fully sure you need a full connection to.
Preload: for the one thing blocking your LCP
Preload is the most useful of the three and the most abused. Its entire job is to remove a request from the browser’s normal discovery order and promote it to the front of the line. That is exactly the treatment your Largest Contentful Paint (LCP) element deserves, since Core Web Vitals treats LCP under 2.5 seconds as the passing bar.
Good preload candidates are narrow and specific:
- The hero image or above-the-fold background image that renders as the LCP element.
- A custom web font used in the initial viewport, especially if it is referenced only inside a CSS
@font-faceblock the browser would otherwise discover late. - A critical CSS file, if you are not already inlining critical styles.
In WordPress, you can add a targeted preload with a small snippet in your theme’s functions.php:
add_action( 'wp_head', function() {
echo '<link rel="preload" href="' . esc_url( get_template_directory_uri() . '/fonts/heading.woff2' ) . '" as="font" type="font/woff2" crossorigin>';
}, 1 );
Note the as attribute. Without it, the browser cannot set the right priority or reuse the fetch when the actual reference shows up in your CSS, and you end up downloading the same file twice.
The misuse: preloading everything above the fold, or every font weight in a family, or a slider image that is not actually the LCP element. Each preload competes for the same limited early bandwidth. Preload three things and you have prioritized three things. Preload fifteen and you have prioritized nothing, because the browser still has to schedule them against each other, and you have likely delayed the one resource that mattered.
Preconnect: a handshake head start, used sparingly
Preconnect is valuable when your page depends on a cross-origin resource early in the render path, typically a font host, an analytics endpoint that blocks something visible, or a CDN serving your hero image. Establishing the connection ahead of time removes DNS lookup, TCP handshake, and TLS negotiation from the critical path for that first request to the origin.
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://fonts.gstatic.com">
Pairing preconnect with dns-prefetch as a fallback is a common, sensible pattern, since older browsers that ignore preconnect still benefit from the DNS lookup.
The misuse: preconnecting to every third-party domain a site touches, from ad networks to social widgets to five different font CDNs. Each open connection holds resources on both ends, and browsers cap how many they will keep warm. If you preconnect to everything, the browser deprioritizes or drops some, and you have spent effort achieving nothing. A reasonable ceiling is two to four preconnected origins, reserved for things that actually render early. If a site sits behind Cloudflare, the connection to your own origin is already handled by the edge, so preconnect hints should focus on genuinely separate origins like font or asset CDNs, not your own domain.
Prefetch: betting on the next click
Prefetch is forward-looking rather than current-page-focused. It tells the browser, at idle, low-priority time, to fetch something the user will probably need next, most commonly the next page in a paginated series, a likely next article, or the checkout page from a cart.
<link rel="prefetch" href="/shop/checkout/" as="document">
Because prefetch is low priority, it generally will not compete with resources the current page needs. That is also its limitation: on a slow connection, or a page that is already resource-heavy, there may be no idle bandwidth for it to use, so it quietly does nothing.
The misuse: prefetching content the user rarely follows through on, especially large pages, video, or anything behind a login. Every prefetch is a bet, and a wrong bet on mobile data is a real cost to the visitor, not just a wasted optimization. Prefetch works best when the next step is highly predictable, like a “next post” link on a series, or the second step of a short checkout flow.
Getting hints out without breaking caching
If you run LiteSpeed with LiteSpeed Cache, the plugin already handles some of this groundwork through its critical CSS and font optimization features, so check what it is already emitting before you hand-add hints that duplicate its work. Object caching through Redis has no direct relationship to resource hints, since hints affect the browser’s fetch behavior, not your server-side cache, but a fast, warm cache means your hints have less ground to make up in the first place.
After adding or changing hints in a theme file, purge the page cache so the new head markup actually reaches visitors rather than a cached version of the old page:
wp litespeed-purge all
Then verify with your browser’s network panel, checking that the preloaded resource actually gets used (no duplicate download) and that its priority looks the way you expect.
The takeaway
Resource hints are a scalpel, not a spray can. Preload one or two resources that truly block your LCP. Preconnect to a small handful of origins that matter early. Prefetch only the next step a visitor is genuinely likely to take. Used this way, they shave real time off real page loads. Used liberally, they just add more competing requests to a browser that was already doing a reasonable job of scheduling things on its own.