View the source of your WordPress site and look near the top of . You’ll probably find this line:
<link rel='dns-prefetch' href='//s.w.org' />That one tag tells every visitor’s browser to perform a DNS lookup for s.w.org — a WordPress CDN server — before it’s even needed. On every page. For every visitor. Whether your site uses emojis or not.
It’s been a source of debate in the WordPress community for years, and it has both performance and privacy implications.
What is DNS prefetching?
DNS prefetching is a browser hint. The tag tells the browser: “you might need to connect to this domain soon, so resolve its IP address now.” The idea is to save the 50-100ms a DNS lookup takes when the resource is actually requested later.
WordPress adds a DNS prefetch for s.w.org because that’s where emoji images are hosted. If a visitor’s browser can’t render emojis natively, WordPress loads image replacements from this CDN. The prefetch is meant to speed up that potential load.
The problem: virtually every modern browser handles emojis natively. The CDN images are almost never loaded. So you’re making every visitor perform a DNS lookup for a server they’ll never connect to.
Why should you care?
Privacy concern. A DNS lookup is a network request. Even though it doesn’t download any content, it tells your visitor’s DNS resolver (often their ISP) that they visited a site connected to s.w.org. For European sites under GDPR, this is an external data transfer your visitors didn’t consent to. WordPress Trac ticket #40426 flagged this as a privacy concern years ago.
Wasted network round-trip. On mobile connections with high latency, DNS lookups can cost 50-100ms. That’s time spent resolving a domain your visitors will never actually connect to. It’s small, but it’s an unnecessary waste on every page load.
It’s a WordPress fingerprint. The s.w.org prefetch tells anyone viewing your source code that you’re running WordPress. While not a major security issue by itself, it’s one more signal for automated scanners.
The quick fix
// Remove s.w.org DNS prefetch
remove_action( 'wp_head', 'wp_resource_hints', 2 );Warning: This removes all default WordPress resource hints, not just s.w.org. If you want to keep other prefetch hints while removing only s.w.org, use the filter approach:
// Remove only s.w.org from DNS prefetch hints
add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
if ( 'dns-prefetch' === $relation_type ) {
$urls = array_filter( $urls, function( $url ) {
return strpos( $url, 's.w.org' ) === false;
});
}
return $urls;
}, 10, 2 );The one-click solution
OvKit includes Remove DNS Prefetch under Features → Performance. One toggle removes the s.w.org prefetch while preserving any other resource hints your theme or plugins might add.
What happens after you fix this?
- No more DNS lookup to s.w.org for every visitor on every page
- One fewer
tag in your HTML - Improved GDPR posture — no external DNS requests without consent
- One fewer WordPress fingerprint in your page source
FAQ
### Will removing this break emojis on my site?
No. Modern browsers render emojis natively using the operating system’s emoji font. The s.w.org CDN is only used as a fallback for very old browsers. If you’ve also disabled the emoji script (which you should), the prefetch is doubly unnecessary.
### Is this related to the emoji script removal?
Yes. If you remove the WordPress emoji script, the DNS prefetch for s.w.org becomes completely pointless — the code that would use the CDN no longer loads. However, WordPress adds them separately, so you need to remove both independently.
### Does this affect Google Fonts or other DNS prefetch hints?
Only if you use the remove_action method, which removes all default hints. The wp_resource_hints filter method (shown above) only targets s.w.org specifically. OvKit uses the filter approach for precision.
Related reads: