What is DNS-Prefetch, and Why it Matters

DNS-prefetch is a browser performance hint that tells the browser it may need to connect to a particular external domain soon, allowing the browser to resolve that domain’s DNS information in advance.

In HTML, it looks like this:

<link rel="dns-prefetch" href="//cdn.example.com">

It does not download a JavaScript file, stylesheet, image or font.

It does not open the complete HTTPS connection.

It simply gives the browser an opportunity to perform the DNS lookup earlier, before a resource from that domain is actually requested.

That distinction matters because modern WordPress websites frequently depend on resources from multiple origins:

• CDNs;
• font providers;
• analytics platforms;
• video services;
• advertising networks;
• payment providers;
• external APIs;
• social embeds;
• image services.

Each new hostname may require DNS resolution before the browser can connect to it.

DNS-prefetch can move part of that work earlier in the page-loading process.

What is DNS?

Before understanding DNS-prefetch, it helps to understand what DNS actually does.

Browsers ultimately connect to servers using network addresses.

Humans, however, normally use domain names such as:

www.example.com

The Domain Name System, or DNS, helps translate a hostname into the network information required to reach the server.

A simplified request looks like this:

www.example.com
↓
DNS resolution
↓
IP address
↓
connection to server
↓
HTTP request

The browser generally needs this resolution before it can establish a connection to a hostname it has not already resolved.

DNS resolution adds latency

DNS resolution is only one part of loading a web resource, but it still takes time.

The exact delay depends on factors such as:

• browser DNS cache;
• operating-system cache;
• recursive DNS resolver;
• network conditions;
• geographic distance;
• DNS provider performance;
• whether the result is already cached.

If the browser already knows the answer, the cost may be very small.

If it has to perform a fresh lookup, additional network work is required.

External domains make DNS more relevant

Imagine a WordPress page hosted at:

https://www.example.com

but loading resources from:

fonts.example-cdn.com
analytics.example.net
images.example-cdn.com
video.example.org

The browser may need to resolve each of those hostnames before requesting their resources.

The loading sequence can become:

HTML
↓
discover external resource
↓
resolve external hostname
↓
establish connection
↓
request resource
↓
download resource

DNS-prefetch attempts to move the DNS step earlier.

How DNS-prefetch works

The browser can be given a hint such as:

<link rel="dns-prefetch" href="//cdn.example.com">

When the browser encounters it, it may resolve:

cdn.example.com

before a resource from that origin is actually requested.

Later, if the page needs:

https://cdn.example.com/app.js

the DNS resolution may already be available.

The browser can then proceed toward establishing the network connection without waiting for that lookup at that moment.

DNS-prefetch is a hint, not a command

The word hint is important.

The official MDN dns-prefetch documentation describes dns-prefetch as a signal that the browser is likely to need resources from a particular origin.

The browser ultimately decides how to handle the hint.

You should therefore think of:

dns-prefetch

as:

"This hostname will probably be useful soon."

not:

"You must resolve this hostname immediately."

What DNS-prefetch does not do

DNS-prefetch performs a very specific job.

It does not:

• download the resource;
• download an entire page;
• open a complete HTTPS connection;
• perform the TLS handshake;
• execute JavaScript;
• load a font;
• preload an image;
• cache a future document;
• make a third-party service faster internally.

It only attempts to reduce the DNS-resolution portion of a future connection.

DNS-prefetch vs. preconnect

This is the most important distinction.

DNS-prefetch generally prepares:

DNS

Preconnect can prepare more of the connection:

DNS
+
TCP
+
TLS for HTTPS

The official MDN preconnect documentation explains that preconnect can establish part or all of the connection handshake in advance.

DNS-prefetch example

<link rel="dns-prefetch" href="//cdn.example.com">

Conceptually:

resolve hostname
↓
wait

resource needed later
↓
connect
↓
request

Preconnect example

<link rel="preconnect" href="https://cdn.example.com">

Conceptually:

resolve hostname
↓
establish TCP connection
↓
perform TLS negotiation
↓
wait

resource needed later
↓
request

Preconnect therefore performs more speculative work.

Why not use preconnect for every external domain?

Because opening connections consumes resources.

MDN recommends reserving preconnect for the most important cross-origin connections rather than applying it indiscriminately to every third-party domain.

If a page connects to many external origins, preconnecting to all of them can be counterproductive.

DNS-prefetch is lighter because it performs only DNS resolution.

A useful strategy is therefore:

Most critical external origins
→ preconnect

Less critical but likely origins
→ dns-prefetch

DNS-prefetch vs. preload

These solve very different problems.

DNS-prefetch targets an origin:

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

Preload targets a specific resource needed by the current page:

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

The official MDN preload documentation explains that preload tells the browser about resources needed soon in the current navigation so they can be fetched earlier.

The difference is:

dns-prefetch
→ resolve hostname

preload
→ fetch specific resource

DNS-prefetch vs. prefetch

The names are unfortunately similar, but the mechanisms are different.

DNS-prefetch:

resolves a hostname

Prefetch:

fetches a resource that may be useful later

The official MDN prefetch documentation describes prefetch as a hint for resources that are likely to be required by a future navigation.

A practical resource-hint comparison

dns-prefetch
→ Resolve external hostname early

preconnect
→ Prepare connection to external origin

preload
→ Fetch important current-page resource early

prefetch
→ Fetch likely future resource at low priority

They are complementary tools, not interchangeable names for the same optimization.

Why DNS-prefetch matters for WordPress

A simple WordPress installation can be almost entirely same-origin.

A modern production site, however, often contains third-party dependencies introduced by:

• themes;
• plugins;
• analytics;
• tag managers;
• advertising;
• web fonts;
• CDNs;
• embedded videos;
• social widgets;
• payment systems;
• maps;
• chat services.

Every additional origin potentially introduces connection setup work.

This is one reason third-party dependencies deserve careful auditing.

See WordPress Privacy and Third-Party Requests for the broader implications of external requests.

WordPress has native resource-hint support

WordPress core includes the:

wp_resource_hints()

function.

The official wp_resource_hints() documentation explains that WordPress can output browser resource hints for operations such as DNS lookup and connection preparation.

Current WordPress core handles resource-hint relation types including:

• dns-prefetch;
• preconnect;
• prefetch;
• prerender.

WordPress automatically discovers some external script and style hosts

For dns-prefetch, current WordPress core starts with:

wp_dependencies_unique_hosts()

This allows WordPress to inspect registered script and stylesheet dependencies and identify unique external hosts.

The result can then be used to generate DNS-prefetch hints.

This means you may see resource hints in your WordPress <head> even if you did not manually write them into your theme.

Example WordPress output

A WordPress page may contain output similar to:

<link rel='dns-prefetch' href='//cdn.example.com' />
<link rel='dns-prefetch' href='//analytics.example.com' />

Those lines are not necessarily plugin clutter.

They may be intentional resource hints generated through WordPress core’s resource-hint system.

This is why generic WordPress head-cleanup snippets should not blindly remove every unfamiliar <link> element.

See Cleaning Up WordPress’s Default Head Output for a broader audit of WordPress head markup.

The wp_resource_hints filter

WordPress exposes the:

wp_resource_hints

filter so developers can modify the resource hints generated for each relation type.

The callback receives:

$urls
$relation_type

This means you can distinguish between:

dns-prefetch
preconnect
prefetch
prerender

instead of treating all hints identically.

How to add DNS-prefetch in WordPress

A developer can add an external hostname using the native filter:

add_filter(
    'wp_resource_hints',
    function ( $urls, $relation_type ) {
        if ( 'dns-prefetch' === $relation_type ) {
            $urls[] = 'https://cdn.example.com';
        }

        return $urls;
    },
    10,
    2
);

WordPress will normalize the DNS-prefetch output to the appropriate host form.

This is generally cleaner than manually echoing arbitrary markup into wp_head when the site’s resource hints are already being managed through WordPress.

How to add multiple DNS-prefetch origins

You can add several origins:

add_filter(
    'wp_resource_hints',
    function ( $urls, $relation_type ) {
        if ( 'dns-prefetch' !== $relation_type ) {
            return $urls;
        }

        $urls[] = 'https://cdn.example.com';
        $urls[] = 'https://analytics.example.com';
        $urls[] = 'https://media.example.net';

        return $urls;
    },
    10,
    2
);

Only add origins that the site is genuinely likely to use.

Do not add the full asset URL unnecessarily

DNS-prefetch operates at the hostname level.

If the future resource is:

https://cdn.example.com/assets/js/app.min.js

the useful DNS target is:

cdn.example.com

not the individual JavaScript file.

WordPress’s resource-hint implementation normalizes DNS-prefetch entries to their host.

DNS-prefetch is primarily useful for cross-origin requests

Adding DNS-prefetch for your current website’s own origin normally provides no useful benefit.

By the time the browser parses:

<link rel="dns-prefetch" href="//www.example.com">

it already had to resolve:

www.example.com

to retrieve the HTML document.

MDN therefore recommends using DNS-prefetch for cross-origin domains.

A CDN may be a good DNS-prefetch candidate

Suppose your HTML is served from:

www.example.com

while images and JavaScript are served from:

static.examplecdn.com

If the browser will almost certainly request resources from that external origin, preparing its DNS lookup can reduce connection setup latency.

For the architectural tradeoffs around asset delivery, see CDN vs. Self-Hosted Assets in WordPress.

Web fonts are another common example

Externally hosted web fonts often involve one or more additional origins.

A simplified page might need:

www.example.com
↓
font stylesheet provider
↓
font file provider

Each external hostname can introduce connection setup work.

Resource hints can reduce some of that latency when the origins are known in advance.

However, resource hints do not eliminate the broader performance and privacy implications of remote fonts.

If external font infrastructure is becoming a significant dependency, see Self-Hosting Google Fonts in WordPress.

DNS-prefetch does not make a third-party script cheap

Suppose an analytics service requires:

DNS lookup
↓
connection
↓
100 KB JavaScript download
↓
JavaScript parsing
↓
JavaScript execution
↓
additional API requests

DNS-prefetch only addresses:

DNS lookup

It does not reduce:

• script size;
• execution cost;
• main-thread work;
• downstream requests;
• tracking behavior;
• server response time.

Do not use resource hints as an excuse to keep unnecessary third-party code.

Third-party embeds can introduce many origins

A single embedded video, map or social post may introduce several external domains.

The visible iframe may only be the beginning.

The embedded application can load:

• scripts;
• stylesheets;
• images;
• analytics;
• advertising;
• API requests.

See Why Third-Party Embeds Slow Down WordPress for the larger performance cost.

DNS-prefetch and privacy

Performance hints should also be reviewed from a privacy perspective.

A DNS-prefetch hint can cause the browser to resolve an external hostname earlier than it otherwise would.

That is not equivalent to loading and executing a third-party script, but it still means the browser may perform network-related activity associated with that external hostname.

For privacy-sensitive sites, do not automatically add speculative connections to every possible third-party service.

Ask:

Will this origin actually be needed?
Why is it present?
When should the browser contact it?
Does the resource require consent?

Consent-managed scripts require extra care

Suppose an advertising or analytics provider should only be contacted after consent.

Adding an unconditional resource hint for that provider may create external network activity before the main script is permitted to load.

Whether that is acceptable depends on the site’s legal and privacy architecture.

The technical optimization should not silently override the intended consent boundary.

DNS-prefetch does not guarantee a Core Web Vitals improvement

DNS-prefetch can reduce connection setup latency for suitable cross-origin requests.

That does not mean adding a DNS-prefetch hint automatically improves:

• Largest Contentful Paint;
• Interaction to Next Paint;
• Cumulative Layout Shift;
• every Lighthouse score;
• every real-user performance metric.

The impact depends on whether the hinted origin is:

• actually used;
• used early enough to matter;
• critical to rendering;
• already cached;
• already connected;
• limited by another larger bottleneck.

DNS-prefetch can be useful without producing a dramatic score change

Resource hints often improve one small part of the loading waterfall.

That can still be useful.

Performance engineering should not be reduced to chasing a single synthetic score.

The relevant question is whether the hint removes measurable latency from a real request path.

When should you use preconnect instead?

If an external origin is both:

• critical;
• required very early in the page load;

preconnect may provide a greater benefit because it can prepare the connection beyond DNS resolution.

For example:

<link rel="preconnect"
      href="https://critical.example.com">

may be appropriate when the page quickly requires an important resource from that origin.

Preconnect is more expensive than DNS-prefetch

A preconnect can perform:

DNS
+
TCP
+
TLS

That consumes more resources than simply resolving a hostname.

For this reason, preconnect should generally be limited to a small number of important origins.

MDN specifically warns that preconnecting to many third-party domains can become counterproductive.

Can you use DNS-prefetch and preconnect together?

You may encounter patterns such as:

<link rel="preconnect"
      href="https://cdn.example.com">

<link rel="dns-prefetch"
      href="//cdn.example.com">

This has historically been used as a compatibility strategy, allowing browsers that support preconnect to perform the stronger optimization while other browsers may still benefit from DNS-prefetch.

On a modern project, however, resource hints should be based on current browser support and actual performance testing rather than copied mechanically from older optimization templates.

DNS-prefetch and HTTP Link headers

Resource hints are not limited to HTML markup.

MDN documents that DNS-prefetch can also be expressed through an HTTP Link header.

Conceptually:

Link: <https://cdn.example.com/>; rel=dns-prefetch

This allows a server or application layer to communicate the hint through the HTTP response.

Do not confuse DNS-prefetch with browser DNS caching

DNS-prefetch and DNS caching are related but different.

DNS caching means a previously resolved hostname may already have a cached result.

DNS-prefetch means the browser is being encouraged to perform the resolution before the normal resource request requires it.

If the answer is already cached, there may be little or no additional work to perform.

Do not confuse DNS-prefetch with a DNS cache plugin

A WordPress plugin cannot eliminate the visitor’s entire DNS resolution process by caching DNS records inside the WordPress database.

The browser, operating system, recursive resolver and authoritative DNS infrastructure all participate in DNS resolution outside normal WordPress page-generation logic.

DNS-prefetch is a browser hint, not a WordPress server-side DNS cache.

How to inspect DNS-prefetch on a WordPress site

Start by viewing the generated page source.

Search for:

dns-prefetch

You may find:

<link rel='dns-prefetch' href='//example.com' />

Then determine:

• which hostname is being hinted;
• whether the page actually contacts that hostname;
• which theme, plugin or WordPress core mechanism added it;
• whether the origin is important;
• whether DNS-prefetch or preconnect is more appropriate.

Use browser DevTools to inspect external origins

Open the browser’s Network panel and reload the page.

Inspect the request domains.

Instead of only looking at filenames such as:

app.js
style.css
font.woff2

look at the hostnames:

www.example.com
cdn.example.com
fonts.example.net
analytics.example.org

This gives you the list of actual network origins involved in loading the page.

Compare the hint with the network waterfall

A DNS-prefetch hint is most useful when the browser can perform the lookup before the corresponding origin becomes part of the critical request chain.

If the resource is discovered immediately anyway, or the DNS result is already cached, the observable benefit may be small.

If the external resource is discovered much later, early DNS resolution may save useful time.

Test without browser cache

DNS-related optimizations can be difficult to evaluate when the browser has already cached previous lookups and connections.

When testing:

• use a clean browser context where practical;
• perform multiple runs;
• inspect the network waterfall;
• avoid drawing conclusions from one test;
• test under realistic network conditions.

Do not add resource hints simply because a domain appears somewhere

Suppose your site contains a link to:

https://social.example.com/company

but does not load any resources from that domain on the current page.

Adding:

<link rel="dns-prefetch"
      href="//social.example.com">

may perform speculative work for a destination the visitor never opens.

The cost of one DNS lookup may be small, but multiplying unnecessary hints across many domains defeats the purpose of deliberate optimization.

Prioritize likely origins

Good candidates generally have three characteristics:

1. The page is likely to use the origin.
2. The origin is external.
3. The lookup can happen meaningfully earlier than the actual request.

Do not create a giant DNS-prefetch list

A list such as:

20 analytics domains
15 advertising domains
10 social domains
8 font domains
6 video domains

is not evidence of sophisticated optimization.

It is usually evidence that the page’s third-party architecture needs to be reviewed.

Start by asking why so many external origins are required.

Third-party reduction is usually more valuable than hint proliferation

If a site loads ten unnecessary external services, adding ten DNS-prefetch hints does not address the primary problem.

A better sequence is:

audit third parties
↓
remove unnecessary dependencies
↓
identify remaining critical origins
↓
apply appropriate resource hints
↓
measure again

Self-hosting can eliminate the external DNS lookup entirely

Suppose a font currently comes from:

fonts.external-provider.example

If the same font is legally and technically self-hosted from:

www.example.com

the external origin disappears from that resource path.

There is then no need to optimize the DNS lookup for that removed dependency.

This is another reason optimization should begin with architecture rather than individual hints.

DNS-prefetch and CDNs

A CDN can improve asset delivery by serving resources from distributed infrastructure.

But if the CDN uses a separate hostname, the browser still needs to establish a relationship with that origin.

For example:

HTML:
www.example.com

Assets:
cdn.example.com

DNS-prefetch or preconnect may help prepare that external origin.

Whether preconnect is justified depends on how critical and immediate those CDN requests are.

DNS-prefetch and lazy-loaded resources

Lazy loading can delay when a browser requests certain resources.

An external resource might not be requested until:

• the user scrolls;
• an interaction occurs;
• a component becomes visible;
• JavaScript initializes a feature.

DNS-prefetch can potentially prepare the hostname before that later request.

But if many visitors never trigger the feature, the speculative lookup may also be unnecessary.

The decision should reflect the probability and importance of the future request.

DNS-prefetch and JavaScript-loaded resources

Some external domains do not appear directly in the initial HTML.

They may only be discovered after JavaScript executes.

For example:

HTML
↓
app.js
↓
JavaScript executes
↓
API hostname discovered
↓
DNS lookup
↓
API request

If the API request is predictable and important, a resource hint in the initial document can move the hostname resolution earlier:

HTML
↓
dns-prefetch API hostname

meanwhile:
app.js loads
↓
JavaScript executes
↓
API request
↓
DNS may already be resolved

This is one of the clearest cases where DNS-prefetch can reduce otherwise hidden latency.

DNS-prefetch and external links

DNS-prefetch can also theoretically prepare domains that users are likely to navigate to.

However, ordinary external links should not automatically trigger a DNS-prefetch strategy.

Use it only when the destination is sufficiently predictable and important to justify speculative work.

WordPress head cleanup can accidentally remove useful resource hints

Some optimization snippets recommend:

remove_action(
    'wp_head',
    'wp_resource_hints',
    2
);

This removes WordPress’s resource-hint output from the page head.

That may remove an unwanted hint, but it also removes the entire resource-hint system produced through that callback.

If only one entry is unnecessary, filtering that entry is generally more precise than disabling all resource hints.

Do not remove wp_resource_hints just to make the head shorter

A few additional bytes of useful HTML are not automatically worse than removing a legitimate connection optimization.

The purpose of head cleanup should be to remove unnecessary behavior, not to achieve the smallest possible source code at any cost.

This principle also applies to other WordPress head features covered in WordPress Head Tags You Can Safely Remove.

How to remove one DNS-prefetch entry

If a particular hostname is no longer used, you can filter the DNS-prefetch list instead of disabling the entire resource-hint system.

For example:

add_filter(
    'wp_resource_hints',
    function ( $urls, $relation_type ) {
        if ( 'dns-prefetch' !== $relation_type ) {
            return $urls;
        }

        return array_filter(
            $urls,
            function ( $url ) {
                return false === strpos(
                    (string) $url,
                    'unused.example.com'
                );
            }
        );
    },
    10,
    2
);

On production sites, make the matching logic as precise as necessary for the actual values generated by the theme, plugin or WordPress core.

Be careful with array-form resource hints

The wp_resource_hints filter can contain both URL strings and arrays of resource attributes.

WordPress supports attributes such as:

• href;
• as;
• crossorigin;
• pr;
• type.

If you are writing generic filtering code, do not assume every item is always a simple string.

DNS-prefetch does not replace good DNS infrastructure

A resource hint can move DNS resolution earlier.

It cannot repair:

• slow authoritative DNS;
• incorrect DNS records;
• DNS outages;
• poor resolver behavior;
• broken CDN configuration.

Infrastructure quality still matters.

DNS-prefetch does not replace a CDN

DNS-prefetch and a CDN solve different problems.

A CDN can change where and how assets are served.

DNS-prefetch only prepares hostname resolution.

The relationship is:

CDN
→ asset delivery architecture

DNS-prefetch
→ browser connection preparation

DNS-prefetch does not reduce file size

If an external JavaScript file is:

600 KB

DNS-prefetch does not make it:

100 KB

The browser still has to download the same file.

Compression, code reduction, caching and dependency removal address different performance costs.

DNS-prefetch does not reduce server response time

If the external server takes:

900 ms

to generate its response, resolving its hostname early does not eliminate that server processing time.

Again, DNS-prefetch optimizes only one part of the request chain.

When DNS-prefetch is useful

DNS-prefetch is worth considering when:

• the page uses predictable external origins;
• those origins are discovered later in the loading process;
• DNS resolution contributes meaningful latency;
• preconnect would be unnecessarily aggressive;
• the external dependency cannot reasonably be removed or self-hosted.

When DNS-prefetch is unnecessary

It may provide little value when:

• the target is the current page’s own origin;
• the domain is rarely used;
• the resource is not important;
• the browser already has a cached DNS result;
• a preconnect already prepares the same critical origin;
• the external dependency should simply be removed;
• privacy requirements discourage speculative contact.

A practical WordPress DNS-prefetch audit

For each important page template:

1. Open the page source.
2. Search for dns-prefetch.
3. List every hinted hostname.
4. Open browser DevTools.
5. Reload the page.
6. List every external hostname actually contacted.
7. Compare the two lists.
8. Remove stale hints.
9. Identify critical origins that may deserve preconnect.
10. Identify predictable secondary origins that may benefit from DNS-prefetch.
11. Review privacy and consent implications.
12. Retest the network waterfall.

Do not audit only the homepage

Different WordPress templates can load completely different dependencies.

Test representative pages such as:

• homepage;
• blog post;
• landing page;
• archive;
• contact page;
• product page;
• cart;
• checkout;
• account page.

A payment provider may appear only at checkout.

A video provider may appear only on selected posts.

A map service may appear only on the contact page.

Do not add every page-specific origin globally

If an origin is used only on one template, adding its resource hint to every page can create unnecessary speculative work.

Where practical, conditionally add hints only where they are relevant.

For example:

add_filter(
    'wp_resource_hints',
    function ( $urls, $relation_type ) {
        if (
            'dns-prefetch' === $relation_type
            && is_page( 'contact' )
        ) {
            $urls[] = 'https://maps.example.com';
        }

        return $urls;
    },
    10,
    2
);

This keeps the optimization aligned with the page that actually needs the external service.

DNS-prefetch checklist

• DNS translates hostnames into network addresses used to reach servers.
• A fresh DNS lookup can add latency before a browser connects to an origin.
• dns-prefetch lets the browser resolve a likely hostname in advance.
• DNS-prefetch is a browser hint rather than a guaranteed command.
• DNS-prefetch does not download the target resource.
• DNS-prefetch does not perform the complete HTTPS connection handshake.
• DNS-prefetch is mainly useful for cross-origin domains.
• There is normally no benefit in DNS-prefetching the current page’s own origin.
• Preconnect performs more connection setup than DNS-prefetch.
• Preconnect can include DNS, TCP and TLS preparation.
• Preconnect should be reserved for important external origins.
• Preloading fetches a specific current-page resource early.
• Prefetching can fetch resources likely to be useful later.
• DNS-prefetch, preconnect, preload and prefetch solve different problems.
• WordPress has native resource-hint support.
• wp_resource_hints() generates WordPress resource hints.
• wp_resource_hints can modify the generated hints.
• WordPress can derive DNS-prefetch hosts from script and stylesheet dependencies.
• Do not remove the entire WordPress resource-hint system to eliminate one unwanted hostname.
• Filter individual stale hints where possible.
• Do not add a large list of speculative domains without evidence.
• Audit actual external origins in browser DevTools.
• Check multiple WordPress page types.
• Third-party scripts can introduce additional domains dynamically.
• Remote fonts can create external DNS dependencies.
• CDNs using separate origins can be candidates for resource hints.
• Self-hosting can remove some external-origin dependencies entirely.
• DNS-prefetch does not reduce JavaScript execution cost.
• DNS-prefetch does not reduce resource size.
• DNS-prefetch does not fix slow external servers.
• DNS-prefetch does not replace caching.
• DNS-prefetch does not replace a CDN.
• DNS-prefetch does not repair poor DNS infrastructure.
• Resource hints should respect privacy and consent architecture.
• Page-specific external services do not necessarily need global hints.
• Measure the actual network waterfall before and after optimization.

Related guides

• Cleaning Up WordPress’s Default Head Output
• WordPress Head Tags You Can Safely Remove
• CDN vs. Self-Hosted Assets in WordPress
• WordPress Privacy and Third-Party Requests
• Why Third-Party Embeds Slow Down WordPress
• wp_enqueue_scripts Explained

Final recommendation

DNS-prefetch is a small but useful performance tool when a WordPress page relies on predictable external origins.

Its job is deliberately narrow:

identify likely external hostname
↓
resolve DNS earlier
↓
reduce potential delay when the real request begins

For a critical external origin needed immediately, preconnect may provide a stronger optimization because it can prepare DNS, TCP and TLS connection work.

For an important specific resource needed by the current page, preload may be the appropriate tool.

For a resource likely to be useful in a future navigation, a prefetching mechanism addresses a different problem again.

The correct strategy is therefore not:

add every resource hint everywhere

but:

audit external origins
↓
remove unnecessary dependencies
↓
identify critical connections
↓
choose the appropriate hint
↓
measure the result

On WordPress, use the native wp_resource_hints system when custom resource hints are required instead of scattering hardcoded <link> elements throughout theme templates.

And before removing resource hints during a generic wp_head cleanup, verify why they exist.

A DNS-prefetch entry that points to an unused domain is clutter.

A DNS-prefetch entry that prepares a real external dependency can be a legitimate part of the site’s performance architecture.