WordPress Emoji Removal

Remove the WordPress emoji scripts and styles that load on every page for a feature most sites do not need.

Overview

WordPress automatically loads an emoji detection script, a corresponding TinyMCE plugin, and an inline <style> block on every page — even sites that never use emoji in their content. The script (wp-emoji-release.min.js) detects whether the browser’s native emoji rendering is adequate and, if not, loads a fallback image set. In 2024, all modern browsers and operating systems render emoji natively without any fallback — making this entire system unnecessary overhead on virtually every WordPress site.

Impact grade, A+ to D: how much of the Lighthouse score this technique can move. Unaffected: LCP, CLS, TTFB.

The Problem

The emoji polyfill system adds 3 HTTP requests to every page load: the detection script, a DNS prefetch to s.w.org (where the emoji images are hosted), and the TinyMCE emoji plugin for the block editor. The detection script runs on the main thread during page initialization, contributing to Total Blocking Time. While the individual impact per request is small (the script is ~10 KB), the combination of an extra DNS lookup, an extra HTTP request, and main-thread JavaScript execution adds measurable overhead for a feature most sites do not use.

Performance Impact

TBT

Minor

emoji detection script removed from main thread initialization; small but real reduction

FCP

20–100ms

removes one render-relevant inline script and DNS prefetch from the early loading waterfall

Minor

slightly faster initial paint contributes marginally to Speed Index

Risk: Very Low

native emoji rendering in all modern browsers makes the fallback unnecessary; emoji display is unaffected

How it works

01
What WordPress emoji loading includes
On every page, WordPress adds: a <link rel="dns-prefetch" href="//s.w.org"> hint, an inline <style> block setting img.wp-smiley styles, the wp-emoji-release.min.js script loaded via wp_print_scripts, and the TinyMCE emoji plugin for the block editor. All of these are unnecessary when native emoji rendering suffices.
02
Remove via the init action
Hook into init with a high priority and remove all emoji-related output functions: remove_action('wp_head', 'print_emoji_detection_script', 7), remove_action('wp_print_styles', 'print_emoji_styles'), and the corresponding admin hooks. One function handles all of them cleanly.
03
Verify browser native emoji rendering
Visit a page containing emoji characters (✅ 🚀 💡 ❌) after removing the script. Modern Chrome, Firefox, Safari, and Edge all render emoji using the operating system’s native emoji font without any JavaScript fallback. The only scenario where the polyfill was historically useful was Internet Explorer — which has been retired.

Code Example

Before

<!-- WordPress adds to every page -->
<link rel="dns-prefetch" href="//s.w.org"/>
<script>
// Emoji detection script (10 KB, runs on main thread)
window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/..."};
!function(i,n){var o,s,e;...}(window,document)
</script>

After

<?php
// Add to functions.php or a site-specific plugin
function remove_wp_emoji() {
    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 array_diff($plugins, ['wpemoji']);
    });
    add_filter('wp_resource_hints', function($urls, $relation_type) {
        return $relation_type === 'dns-prefetch'
            ? array_filter($urls, fn($url) => !str_contains((string)$url, 's.w.org'))
            : $urls;
    }, 10, 2);
}
add_action('init', 'remove_wp_emoji');

This is a one-time setup with no ongoing maintenance. The emoji characters in posts and pages continue to render correctly via native browser/OS support — only the JavaScript detection and fallback polyfill are removed.

Limitations

If the site actively targets users on very old operating systems (Windows XP, Android 4.x) that lack native emoji font support, removing the polyfill may cause emoji to display as squares or question marks for those users. In practice, this represents a negligible fraction of modern web traffic.
Email content using wp_mail will no longer have emoji converted to images for email clients — some email clients do not render emoji natively. If emoji in transactional emails is important, keep the wp_staticize_emoji_for_email filter active.

Common Mistakes

Removing only the frontend emoji hooks but forgetting the admin hooks

The emoji scripts load in both the frontend and admin. Remove both sets of hooks: wp_head / admin_print_scripts and wp_print_styles / admin_print_styles. A partial removal still loads emoji scripts for logged-in admin users.

Test this techniqueWordPress AuditRun the tool

Targeted fixes, not guesswork.

Start an Engagement