WordPress: Preload, preconnect and prefetch resource hints

Using preload, preconnect, and prefetch resource hints can improve your website’s performance by reducing page load times. This post covers what each of these resource hints does, how to implement them on your WordPress website, when it’s beneficial to use them, and the potential pitfalls of relying on too many resource hints.

To understand how browser resource hints work, it helps to know that browsers have limited processing power. While modern browsers are capable and multi-threaded under the hood, the main thread (which is responsible for rendering your website) can only do one task at a time.

When a browser loads your website, it has to complete a number of tasks: downloading resources, parsing HTML, loading stylesheets, executing JavaScript, and more. The order and timing of these tasks affect how quickly your website is displayed.

Browser resource hints help the browser prioritise important tasks, so the most critical parts of your site load faster. By guiding the browser with hints like preload, preconnect, or prefetch, you can improve page load times and perceived performance.

Resource hints are placed in the head section of the HTML document. They provide the browser with early information about resources that are likely to be needed soon, allowing it to optimize loading behaviour.

Common resource hints include dns-prefetch, preconnect, prefetch, and preload, each serving a different purpose in improving performance.

Preconnect allows the browser to establish early connections to external domains, reducing latency for critical third-party assets.

Prefetch is used to fetch resources that might be needed for future navigation, such as the next page in a multi-page article or a script for a modal that hasn’t been triggered yet (this helps the browser load those resources instantly when required).

Preload can be used to load essential assets like fonts or hero images ahead of time. Using these hints strategically can lead to faster page rendering and an overall smoother user experience.

Browser hints are all written in HTML, and they have accompanying attributes which define the type, purpose, and behaviour of the hinted resource, allowing the browser to handle it appropriately during the loading process.

Load a resource now that will be needed in the future.

Prefetch is a resource hint that tells the browser to fetch a resource in the background that might be needed in the near future, such as during a subsequent page navigation or user interaction. It’s a low-priority fetch, meaning it won’t block the current page load or consume bandwidth needed for more urgent assets.

It helps reduce perceived latency when the user eventually requests the resource, because it’s already in the browser’s cache.

Suppose you have a blog post with a “Next Article” link at the bottom. You can use prefetch to load the HTML of the next page in advance, so if the user clicks the link, the transition feels instant.

<link rel="prefetch" href="/article-2.html" as="document">

• document – For full HTML pages.
• script – For JavaScript files.
• style – For CSS files.
• image – For images.
• font – For web fonts.

Look up the DNS of a domain early.

Dns-prefetch is a resource hint that tells the browser to resolve the DNS of a domain early, before any actual resource requests to that domain are made. This helps reduce latency by preemptively performing the DNS lookup, which is often one of the first steps in establishing a connection to an external resource.

Unlike other resource hints, dns-prefetch does not download or connect to a specific file — it simply performs the DNS resolution so the domain is ready when needed.

Let’s say your website includes fonts or scripts from a third-party CDN (like Google Fonts or a JavaScript library from a CDN). The browser won’t normally resolve that domain’s DNS until it encounters the actual request. By adding a dns-prefetch hint, you tell the browser to start the DNS lookup early.

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

Note: You only provide the domain (e.g. //example.com), not a full path or file.

You can use dns-prefetch even before any actual resources from that domain are requested.

It’s most useful for external third-party domains (CDNs, analytics, ad networks, etc.).

Some browsers support dns-prefetch even when it’s included within

<meta http-equiv="x-dns-prefetch-control" content="on">

but this is rarely necessary with modern browsers.

Initiate early connections to an external resource.

preconnect is a resource hint that tells the browser to initiate early connections to a specified origin. This includes DNS resolution, TCP handshake, and, for HTTPS, TLS negotiation—all before any actual resource requests are made.

This can significantly reduce latency, especially for critical third-party resources, by preparing the connection ahead of time.

Imagine your website uses a font from Google Fonts. Normally, the browser waits until it parses the

<link>

o the stylesheet before beginning the connection to fonts.googleapis.com. With preconnect, you tell the browser to set up that connection immediately, so when the font file is needed, its already partway loaded.

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

Important: You must include the full origin, including https://, not just //example.com.

Load a resource early.

Preload is a powerful resource hint that tells the browser to load a specific resource early, as soon as possible during page load—before it would normally be discovered. Unlike prefetch, which is low priority and speculative, preload is high priority and intentional.

This is particularly useful for critical assets like fonts, hero images, CSS, or scripts that are needed to render the page properly and quickly.

Let’s say your homepage has a large hero image at the top of the page, which is the Largest Contentful Paint (LCP) element. Normally, the browser may discover this image only after parsing the HTML or CSS, which delays its loading.

To improve performance and lower your LCP time, you can use preload to tell the browser to fetch the hero image immediately, even before it encounters the tag. This ensures the image is downloaded earlier in the critical rendering path, leading to a faster visual load.

<link rel="preload" as="image" href="/images/hero-banner.webp" type="image/webp" fetchpriority="high">

Make sure the image you’re preloading is actually the LCP element (usually the largest visible image above the fold).

Use a matching src in the

<img>

tag later in the HTML, otherwise the browser may treat it as a separate resource and re-download it.

Combine with the fetchpriority=”high” attribute on the

<img>

tag itself for full effect:

<img src="/images/hero-banner.jpg" alt="Welcome to our site" fetchpriority="high" width="1200" height="600">

preload does not apply the resource, it only downloads it early. You must still reference the resource normally (e.g., link to the font in CSS).

Preloading a resource that’s never used wastes bandwidth, so only preload resources guaranteed to be needed.

Using the correct as value is essential, if it’s missing or incorrect, the preload may be ignored or generate a browser warning.

While preload is a powerful tool for improving performance, especially for critical resources like fonts or LCP images, it should be used strategically, not excessively. Overusing preload can have the opposite effect and actually harm your site’s performance.

Preloading too many resources tells the browser to load them all early, regardless of whether they’re actually needed right away. This can lead to:

Bandwidth waste – Resources that are preloaded but never used still consume bandwidth.

Slower critical rendering – The browser may be forced to fetch less important resources ahead of truly critical ones, delaying First Contentful Paint (FCP) or LCP.

Network congestion – Especially on slower connections, preloading many resources can overwhelm the browser’s limited number of parallel requests.

Increased CPU usage – Processing many preloaded resources (scripts, styles, fonts) can increase parsing and memory overhead.

The goal is not to preload everything, but to only preload what will speed up rendering of above-the-fold content.

To get the most out of preload without hurting performance:

• Only preload resources that are definitely used on the current page (e.g. hero image, main font, essential CSS or JS).
• Match preloaded assets exactly with those later referenced (same path, file, and protocol).
• Avoid preloading resources used later in the page or during user interaction (use prefetch or lazy loading instead).
• Use the correct as value and MIME type, especially for fonts and images.
• Test on slower networks to see the real impact of your preloads on time to first render.

Here’s how you can identify which resources are good candidates for preloading:

Open Chrome DevTools → Performance tab → Record a page load.

Look for resources that block rendering or are delayed but used early (e.g., hero images, fonts).

Audit with Lighthouse, PageSpeed Insights or Debug bear’s page speed test and browser hints resource validator tool. These tools will suggest preloading key requests — especially LCP images and fonts. They may flag fonts or large images that are render-blocking.

Check Largest Contentful Paint (LCP) source:

If your LCP is an image or background image, preloading it can have a big performance payoff.

You can see this in a pagespeed insights report by expanding the Largest Contentful Paint section:

Or in the LCP section of Debug Bear’s Page Speed Test:

Only preload what’s important on the initial page load — don’t preload resources users might not request.

Use preload as a precision tool, not a blunt instrument. A few well-chosen preload hints can dramatically improve loading speed, but overdoing it leads to bloated performance, wasted resources, and slower user experiences. Focus on what’s above the fold, what blocks rendering, and what contributes directly to Core Web Vitals like LCP and FCP.

There are tools designed specifically to check resource hints, such as Debug Bear’s Browser Resource Hint Validator.

It’s a very good idea to use tools of this nature to check that your browser hints are valid, and that you’re not over using these.

It’s very tempting to see something positive taking place through the use of browser hints, such as your LCP metric improving, then to think “Excellent! What else can I browser hint?”. This doesn’t always have the desired effect, as the overuse of browser hints can be worse for performance than not using them at all.

If you think of browser hints managing a queue in a shop, this might help. Organising the queue helps the cashier deal with customers at an effective rate. This is the equivalent to a good use of browser hints. On the other hand if the queue in the shop turns in to a free for all, and five customers try and checkout and pay all at the same time, that doesn’t really help the cashier, or the efficiency of the queue.

Over using browser hints can result in the browser being told to do too much at the beginning of the page loading process. The balance between loading enough and loading too much can be a fine line to tread, so using tools to validate your browser hints is a good idea.

How you use browser hints in WordPress can be very varied according to your site, what it is you’d like to browser hint, and if you’d like to do this for the whole page or just one page.

Using global site wide browser hints in WordPress can be fairly straight forward.

Let’s say your site uses Google fonts, which load externally from https://fonts.googleapis.com . As your site uses these fonts on every page, a global DNS prefectch to //fonts.googleapis.com makes sense.

What this will do will tell the browser to carry out a DNS lookup on fonts.googleapis.com early in the page load. While this won’t actually load a resource, it will look up DNS for fonts.googleapis.com . The effect of this, is that the DNS lookup has already been carried out when it comes to actually loading the fonts. The time it takes to load the fonts from fonts.googleapis.com is reduced due to this.

Most code snippet plugins allow you to add directives to the head section of all pages on your website. You’d just need to install and activate a plugin of this nature, then add the DNS prefetch directive to the head section using:

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

There are magical zero config plugins such as Pre* Party Resource Hints.

Plugins like this will detect global preloading, automatically bring this in to effect, and provide you with an interface that allows you to disable and enabled the browser hints that it’s added:

There are other plugins such as WPcode and Code Snippets that you can use to manually add global browser hints to the site as a whole.

While these plugins are all well and good, they don’t allow for per page browser resource hints. As your LCP image is likely to vary between pages, this can cause a bit of a problem.

LCP is an important metric because it’s part of what’s used to assess your website’s Core Web Vitals. These metrics are a ranking factor, and failing to pass them can negatively affect your site’s position in search results.

LCP stands for Largest Contentful Paint. It measures the time it takes for the largest visible element above the fold (the part of the page displayed in the browser before scrolling) to be fully rendered.

On many WordPress sites, this largest element is often a large image at the top of the page (commonly a hero image or banner). Since this image often determines the LCP timing, optimising how quickly it loads can improve your Core Web Vitals score.

One way to do this is by using browser hints to preload the LCP image. This tells the browser to start downloading the image early in the render process—before it would normally be requested. Because the image is fetched sooner, it’s ready to display by the time the LCP is measured, reducing the delay.

Example of a preload browser hint:

<link rel="preload" as="image" href="/images/hero-banner.webp" type="image/webp" fetchpriority="high">

Since your LCP image will likely vary between pages, you’ll need a plugin that allows per-page

<head>

modifications.

The Header and Footer Script Adder plugin can be used to insert both global and page-specific browser hints. It adds a section to the bottom of each page in the WordPress editor where you can manually define the preload tags.

When optimising for LCP using the method outlined above, it’s important to:

• Ensure you have a mobile-optimised version of the LCP image, and that this is the one loaded on mobile devices.
• Use the preload browser hint to call the mobile-optimised image.
• Validate that the preload hint is working as intended by using tools such as DebugBear’s Browser Resource Hint Validator.

When improving LCP, it’s tempting to focus on desktop performance first—but in reality, mobile optimisation should be the priority. Here’s why:

Google’s mobile-first indexing means that the mobile version of your site is the primary version Google uses for ranking and indexing. If your mobile LCP is poor, it can directly hurt your search performance, even if your desktop score is excellent.

While desktop machines can load and render pages quickly, most mobile devices (especially older models) have less processing power, slower storage, and possible slower network connections. This makes the largest visible element on the page take longer to load and display, which can drag down your LCP score.

Even though tools like Lighthouse can simulate a mobile connection and device profile, these are still approximations. Real-world mobile users may experience slower speeds and higher latency than any lab simulation shows.

You can’t easily set up different preload hints for desktop and mobile users. Since preload hints are placed in the page’s before the browser knows the visitor’s screen size, you have to choose one version to prioritise. In most cases, choosing the mobile-optimised image will deliver better results for the majority of users.

Because desktops generally have faster CPUs, more RAM, and better network connections, they’ll often pass the LCP Core Web Vital without extra effort. Mobile, however, usually needs more optimisation to meet Google’s recommended 2.5-second threshold.

Optimising for mobile LCP ensures you’re addressing the most challenging performance scenario first. If you pass on mobile, you’ll almost certainly pass on desktop—giving your site the best chance to perform well in both search rankings and user experience.

Browser resource hints are HTML directives placed in a page’s section to help the browser load important resources sooner. Common examples include:

dns-prefetch – Resolves a domain’s DNS early.

preconnect – Opens a network connection to an external server in advance.

prefetch – Downloads resources that may be needed soon.

preload – Downloads a critical resource as soon as possible.

DNS-prefetch – Only resolves the domain’s DNS.

Preconnect – Resolves DNS, opens TCP, and negotiates TLS.

Prefetch – Fetches low-priority resources for later use.

Preload – Immediately downloads high-priority resources for the current page.

Preloading the Largest Contentful Paint (LCP) image tells the browser to fetch it early in the page load, so it’s ready by the time the LCP measurement occurs. This can reduce LCP times and improve Core Web Vitals scores.

Google’s mobile-first indexing prioritises your mobile version for ranking.

Mobile devices often have less processing power and slower connections.

Lab simulations can’t perfectly match real mobile conditions.

You can’t easily preload different images for mobile vs desktop in one request.

Passing LCP on mobile usually means you’ll pass it on desktop too.

Use a plugin that allows per-page modifications (e.g., Header and Footer Script Adder). Then add:

<link rel="preload" as="image" href="/images/hero-banner.webp" type="image/webp" fetchpriority="high">

Ensure you use the same file path in the tag to avoid duplicate downloads.

Not reliably. Preload hints are added before the browser knows the screen size, so it’s best to preload the mobile-optimised image—this benefits both mobile users and Google rankings.

Overusing resource hints can hurt performance by:

Wasting bandwidth on unused assets.

Delaying more important resources.

Increasing CPU and memory usage.

Always validate your hints with tools like DebugBear’s Browser Resource Hint Validator.

Use prefetch for resources that will be needed soon but not immediately (e.g., the next page in a series). Use preload only for assets needed right away in the current page view.

For resources used across the whole site (e.g., Google Fonts), add hints globally using:

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

You can do this via a code snippet plugin (WPCode, Code Snippets) or an automated tool like Pre* Party Resource Hints.

Audit with Chrome DevTools, Lighthouse, or PageSpeed Insights.

Focus on assets that block rendering and affect above-the-fold content.

Start small—only preload resources guaranteed to be used on that page.