WordPress Resource Hints: How to Use Preload, Prefetch, and Preconnect

When a browser loads a WordPress page, it discovers resources — stylesheets, scripts, fonts, images — one at a time as it parses the HTML. This sequential discovery means the browser often doesn’t start fetching a critical resource until long after the page has begun rendering.

Resource hints are HTML link tags that give the browser early information about resources it will need, allowing it to start fetching or connecting before it would otherwise know to. Used correctly, they can measurably reduce render times, especially for third-party resources like Google Fonts, analytics scripts, and CDN-hosted assets.

This guide explains the four main resource hint types, when to use each, and how to implement them in WordPress.

The Four Resource Hint Types

The W3C Resource Hints specification defines several directives that control how and when the browser prepares for future resource requests.

1. dns-prefetch

<link rel="dns-prefetch" href="//fonts.googleapis.com">

This hint tells the browser to resolve the DNS for a given domain early — before any resource from that domain is actually requested. DNS resolution is a prerequisite for any network connection, and for third-party domains it can take 20–120ms depending on the user’s DNS provider and network conditions.

dns-prefetch is the lightest of the resource hints. It only performs DNS resolution, not the TCP or TLS handshake. It works in essentially all browsers and has negligible cost, so it’s safe to apply broadly to any external domain your page connects to.

Best for: Any third-party domain your page loads resources from — Google Fonts, analytics providers, social media widgets, ad networks, your CDN.

2. preconnect

<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>

preconnect goes a step further than dns-prefetch. It performs the full connection setup: DNS resolution, TCP handshake, and TLS negotiation. For HTTPS origins (which is almost everything today), this can save 100–300ms or more on the first request to that origin.

The cost is higher than dns-prefetch — the browser allocates a socket and performs real network operations — so reserve preconnect for origins you are certain will be used. Speculative preconnects that never result in a request waste connection resources and may cause the browser to close the connection before it’s needed.

Best for: The 2–3 most critical third-party origins your page depends on. Google Fonts, your CDN origin, and any external API your above-the-fold content loads from are good candidates.

3. preload

<link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>

preload instructs the browser to fetch a specific resource at high priority during the initial page load, before it would normally be discovered during HTML parsing. Unlike the connection hints above, preload actually fetches the resource and stores it in the browser’s cache.

The as attribute is required and tells the browser what type of resource it is (font, style, script, image, fetch, etc.), which determines the request priority and which HTTP headers are sent.

preload is particularly valuable for:

• Custom web fonts — fonts are typically discovered late in the render cycle, causing flash of invisible text (FOIT) or flash of unstyled text (FOUT). Preloading the font file tells the browser to fetch it immediately.
• Critical CSS loaded from external files — if you’ve split your stylesheet into critical and deferred portions, preloading the critical portion can help it arrive earlier.
• Hero images that are CSS backgrounds — <img> elements are discovered in HTML parsing, but CSS background images are not discovered until the CSS is parsed and applied. Preloading them closes that gap.
• Late-discovered scripts — if a critical script is loaded by another script or injected dynamically, preloading the final URL fetches it sooner.

Important: Unused preload tags generate console warnings in Chrome and waste bandwidth. Only preload resources that are definitively needed on the current page.

4. prefetch

<link rel="prefetch" href="/about/" as="document">

prefetch is a low-priority hint for resources that may be needed for future navigation — not the current page. The browser fetches and caches these resources during idle time, so they are available instantly if the user navigates to that URL.

Unlike preload, prefetch does not affect current page performance. It trades a small amount of bandwidth for faster subsequent page loads.

Best for: Pages users are likely to visit next. Common patterns include preloading the next article in a series, the checkout page from a product page, or the primary call-to-action destination.

How to Implement Resource Hints in WordPress

There are two approaches: using a plugin or adding hints directly to your theme.

Plugin Approach

Several WordPress performance plugins include resource hint controls:

• WP Rocket includes preconnect and prefetch settings in its CDN and preloading tabs
• Perfmatters has a dedicated resource hints field where you can add preconnect and dns-prefetch entries by domain
• Flying Scripts and similar tools can manage script preloading alongside deferral settings

Plugin-based management is simpler to maintain and doesn’t require code changes when you update your theme. For most sites, a plugin is the right choice.

Code-Based Approach

You can add resource hints via a WordPress hook in your theme’s functions.php or a site-specific plugin:

function mytheme_add_resource_hints( $hints, $relation_type ) {
    if ( 'preconnect' === $relation_type ) {
        $hints[] = array(
            'href'        => 'https://fonts.googleapis.com',
            'crossorigin' => 'anonymous',
        );
        $hints[] = array(
            'href' => 'https://fonts.gstatic.com',
            'crossorigin' => 'anonymous',
        );
    }
    return $hints;
}
add_filter( 'wp_resource_hints', 'mytheme_add_resource_hints', 10, 2 );

WordPress passes the hint relation type to the filter, so you can target dns-prefetch, preconnect, prefetch, or prerender separately.

For preload tags, you typically add them with wp_head:

function mytheme_preload_font() {
    echo '<link rel="preload" href="' . get_template_directory_uri() . '/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin>';
}
add_action( 'wp_head', 'mytheme_preload_font', 1 );

Using priority 1 ensures the tag appears near the top of <head>, which is where preload hints are most effective.

Common Mistakes

Preloading too many resources. Preload competes with other high-priority resources like stylesheets and blocking scripts. A page with ten preload tags for fonts, images, and scripts will have all of them competing for bandwidth — which may actually slow the most critical resources down.

Using preconnect for domains you’re not sure about. If a preconnected domain isn’t actually used on the page, the browser wasted a socket setup and may have displaced a real connection from memory. Be deliberate about which domains you preconnect.

Forgetting crossorigin on font preloads. Font requests use CORS, so <link rel="preload" as="font"> tags require crossorigin to match the actual request headers. Without it, the browser may fetch the font twice — once for the preload and once when it’s actually needed.

Applying page-level hints globally. A hero image preload that makes sense on the homepage will waste bandwidth on every other page. If your WordPress setup serves different content types from different templates, apply hints conditionally using template tags like is_front_page(), is_single(), or is_woocommerce().

How to Verify Your Resource Hints Are Working

The Chrome DevTools Network tab is the best tool for validating resource hints. Load your page and look for:

• Resources with (disk cache) or (memory cache) labels — these were preloaded or prefetched successfully
• Connection timing in the waterfall — preconnected origins should show near-zero DNS and connection time for subsequent requests
• Any [Deprecation] or [Warning] messages in the Console tab, which may indicate unused preloads or missing crossorigin attributes

WebPageTest also shows resource hint effectiveness in its waterfall view, and the Opportunities section of Google PageSpeed Insights may suggest preconnect and preload improvements specific to your site.

The Role of Managed Hosting

Some resource hint optimizations depend on server-side configuration that individual site owners can’t control on shared hosting. HTTP/2 Server Push, for example, allowed servers to proactively send resources alongside the initial HTML response — but it required server configuration and has been largely superseded by preload headers and HTTP/103 Early Hints, which are only available on servers that support the relevant HTTP features.

Managed WordPress hosts like Rocket.net handle these infrastructure decisions for you. Rocket.net runs on Cloudflare’s global network with HTTP/2 and HTTP/3 support, NVMe storage for fast disk reads, and full-page caching that reduces the server response time that preload and preconnect are trying to compensate for.

When your server responds quickly and your assets are cached at edge locations close to your users, the marginal benefit of resource hints decreases — not because they stop working, but because the underlying bottlenecks are already addressed. That said, resource hints remain valuable for third-party resources that no managed host can cache on your behalf: Google Fonts, analytics scripts, advertising tags, and social embeds.

A Practical Starting Point

If you’re new to resource hints and want to start with the highest-impact changes:

1. Add preconnect for any Google Fonts domains (fonts.googleapis.com and fonts.gstatic.com)
2. Add dns-prefetch for your analytics provider (Google Analytics, Fathom, Plausible, etc.)
3. Add preload for your most important above-the-fold font file (usually the regular weight of your body typeface)
4. Inspect the Network waterfall before and after to confirm the changes are having the expected effect

These three steps cover the most common performance gaps that resource hints address, without the risk of over-preloading resources that aren’t needed.

---

If you’re serious about WordPress performance, the best foundation is hosting that’s built for speed from the start. Rocket.net is a managed WordPress hosting platform built on Cloudflare’s enterprise network, with automatic full-page caching, NVMe storage, and HTTP/2 and HTTP/3 support out of the box. A fast host means your resource hints are optimizing an already-fast baseline — not compensating for a slow one.