Open any WordPress site right now, view the source code, and search for wp-emoji. You’ll find a JavaScript file loading on every single page — your homepage, your contact page, your blog posts, your WooCommerce checkout. Every. Single. Page.
That file is wp-emoji-release.min.js, and unless you’re running a site where emoji rendering in Internet Explorer 10 is mission-critical, it’s doing nothing useful for you.
I manage over 30 WordPress sites at my agency. One of the first things I do on every fresh install is kill this script. Here’s why — and how.
What is the WordPress emoji script?
Back in 2015, WordPress 4.2 added native emoji support to the core. The idea was fine: make sure emojis display correctly on older browsers that didn’t have built-in emoji fonts.
The way it works is simple but wasteful. WordPress injects an inline JavaScript block into your that runs a canvas-based detection test. It draws an emoji character on a hidden canvas element and checks if the browser rendered it correctly. If the browser “fails” the test, WordPress loads wp-emoji-release.min.js from your server to polyfill emoji rendering with images from the WordPress CDN at s.w.org.
Here’s the problem: this detection script runs on every page load, even when your content has zero emojis. And it’s not just the script. WordPress also loads:
- An inline JavaScript block in
— render-blocking code the browser must execute before painting the page - Emoji CSS styles on both frontend and admin
- A DNS prefetch to
s.w.org— an external connection your visitors didn’t ask for - A TinyMCE emoji plugin loaded in your editor
That’s four pieces of overhead for a feature that 99%+ of modern browsers handle natively.
Why should you care?
Let’s talk numbers.
The emoji script itself is about 10.5 KB. That sounds small until you multiply it by every page view on your site. A site with 50,000 monthly page views is transferring roughly 500 MB of emoji script data per month — for nothing.
But file size isn’t the whole story. Here’s what’s actually hurting you:
Render-blocking execution. The inline detection script sits in your . The browser has to parse and execute it before rendering anything else. On mobile connections with high latency, this can cost 50–100ms of real rendering time.
DOM mutation listening. Here’s something most optimization guides skip: the emoji script uses MutationObserver to watch for DOM changes and re-parse the entire page for emoji characters. On sites using AJAX-heavy plugins — think WooCommerce product filters, live search, or infinite scroll — this constant monitoring can cause serious CPU overhead. In one documented case, an AJAX-based filtering plugin saw pages freeze for nearly 40 seconds because the emoji script was processing DOM updates.
Privacy and tracking concerns. The DNS prefetch to s.w.org means every visitor’s browser performs a DNS lookup to an external server. That’s data leaving your site without explicit consent. The emoji detection script also uses the Canvas API in a way that triggers tracking-protection warnings in privacy-focused browsers and extensions. Your legitimate business site ends up flagged as a potential tracker.
GDPR implications. If you serve European visitors (and if you’re reading this from Norway like me, you definitely do), that DNS prefetch to an external server is a data transfer you need to account for. Removing the emoji script eliminates this external connection entirely.
The quick fix
If you’re comfortable adding code to your site, drop this into your theme’s functions.php or — better — into a site-specific plugin:
// Remove WordPress emoji scripts, styles, and DNS prefetch
add_action( 'init', function() {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
add_filter( 'tiny_mce_plugins', function( $plugins ) {
return is_array( $plugins ) ? array_diff( $plugins, ['wpemoji'] ) : [];
});
add_filter( 'wp_resource_hints', function( $urls, $relation_type ) {
if ( 'dns-prefetch' === $relation_type ) {
$emoji_svg_url = apply_filters( 'emoji_svg_url', 'https://s.w.org/images/core/emoji/2/svg/' );
$urls = array_diff( $urls, [ $emoji_svg_url ] );
}
return $urls;
}, 10, 2 );
});This removes the detection script, the external CSS, the TinyMCE plugin, the RSS feed filters, the email filters, and — critically — the DNS prefetch to s.w.org. It’s the complete cleanup.
Important: Use a child theme or a code snippets plugin like WPCodeBox. Never edit a parent theme’s functions.php directly — your changes will disappear on the next theme update.
The one-click solution
If you’d rather not touch code — and honestly, for most site owners that’s the smarter choice — OvKit handles this with a single toggle.
Install the plugin, go to Features → Performance, and flip the Remove Emoji Scripts switch. Done in 5 seconds. No code, no child theme, no risk of a syntax error taking down your site.
OvKit removes the same hooks as the code above, plus it handles edge cases that simple snippets miss.
What happens after you fix this?
Once you remove the emoji script, here’s what changes:
- One fewer render-blocking script in your
— measurable improvement in First Contentful Paint - 10.5 KB less on every page load — adds up fast at scale
- No more DNS prefetch to
s.w.org— one less external connection, cleaner GDPR compliance - No more Canvas API fingerprinting triggers — privacy extensions stop flagging your site
- No more MutationObserver overhead — AJAX-heavy pages run smoother
And here’s what doesn’t change: emojis still work. Every modern browser released since 2015 renders emojis natively through the operating system’s built-in emoji font. Your visitors on Chrome, Firefox, Safari, and Edge will see emojis exactly as before. The only people affected are visitors on Internet Explorer 10 or Android 4.3 — and if those make up a meaningful share of your audience, you have bigger problems to solve.
To verify the script is gone, view your page source and search for wp-emoji. Zero matches means you’re clean.
FAQ
Is it safe to remove the WordPress emoji script?
Yes. This is one of the safest performance optimizations you can make. You’re removing a polyfill for browsers that represent less than 0.1% of global web traffic. Modern browsers handle emojis without any help from WordPress. If you’re using WP Rocket, Autoptimize, or Perfmatters, check your settings — you might already have this disabled.
Will emojis stop working on my site?
No. Emojis will continue to display correctly for virtually all visitors. The script only exists to support very old browsers. On modern devices, the operating system’s emoji font (Apple Color Emoji on Mac/iOS, Segoe UI Emoji on Windows, Noto Color Emoji on Android) handles rendering. The only visual difference: emojis might look slightly different depending on the visitor’s OS — an Apple user sees Apple-style emojis, a Windows user sees Microsoft-style. That’s standard behavior across the entire web.
Does this work with WooCommerce, Elementor, and GeneratePress?
Yes. I’ve deployed this on sites running all three — separately and together — with zero issues. The emoji script is a WordPress core feature, completely independent of themes and plugins. Removing it doesn’t touch any theme or plugin functionality.
Related reads: