Why WordPress Loads an Emoji Script on Every Page

WordPress includes an emoji detection system on the frontend even when a page does not visibly contain an emoji.

Its purpose is not to insert emojis into your content. Modern browsers and operating systems already render normal Unicode emoji characters themselves.

Instead, WordPress uses its emoji system as a compatibility fallback. The browser is tested to determine whether it can correctly render the emoji features WordPress currently checks. When support is insufficient, WordPress can fall back to emoji images hosted by WordPress.org.

This distinction matters because the common explanation:

WordPress loads an emoji script
because your page contains emojis

is inaccurate.

The detection mechanism is normally part of WordPress’s default page infrastructure, so it can appear even when the current page contains no emoji characters at all.

The implementation has also changed significantly over time. In older WordPress versions, the detection code was an inline script in the document head. Starting with WordPress 6.9, Core converted it to a deferred script module and moved its execution toward the footer to reduce its effect on the critical rendering path.

This guide explains why WordPress includes the emoji system, what the detection script actually does, how modern WordPress has optimized it, when external emoji requests occur, what happens if you disable the system and when removing it is a reasonable optimization.

What are WordPress emojis?

First, separate three concepts that are often treated as if they were the same thing:

Unicode emoji characters

WordPress emoji detection

WordPress emoji fallback images

They are related, but they are not identical.

Unicode emojis are characters

An emoji such as:

😀
❤️
👍

can exist directly in text as Unicode characters or sequences.

Your browser, operating system and installed fonts normally determine how those characters are rendered.

WordPress does not need to download an image every time someone writes an emoji.

The WordPress emoji script is a compatibility detector

WordPress’s frontend emoji JavaScript exists primarily to detect whether the visitor’s environment correctly supports the emoji features expected by Core.

The current print_emoji_detection_script() documentation describes the function as printing the inline emoji detection system if it has not already been printed.

In current WordPress, the public function coordinates when the actual detection code should be emitted rather than simply dumping the old blocking script immediately into the document head.

Why does WordPress need emoji detection?

Emoji support is not simply:

browser supports emoji
or
browser does not support emoji

Unicode continually evolves.

Emoji can involve:

• newer Unicode characters;
• variation selectors;
• skin-tone modifiers;
• zero-width joiner sequences;
• flags;
• gender variants;
• combined emoji sequences;
• newer emoji specifications.

An operating system may display common emojis correctly while lacking support for newer or more complicated sequences.

The WordPress detection layer exists so Core can determine whether a fallback is required.

WordPress introduced its emoji support in version 4.2

The current WordPress code reference records print_emoji_detection_script(), wp_encode_emoji() and related functionality as having been introduced in WordPress 4.2.

The environment in which that system was introduced was very different from the modern browser ecosystem.

Native emoji support was less consistent across:

• operating systems;
• browsers;
• devices;
• Unicode versions.

A compatibility layer therefore had a much clearer practical purpose.

Why does the emoji detector appear on pages without emojis?

Because WordPress does not normally begin by asking:

Does this specific page contain an emoji?

before deciding whether the browser’s emoji capabilities need to be known.

The system is registered as part of WordPress Core’s default frontend behavior.

Current Core still attaches:

print_emoji_detection_script

to the normal frontend lifecycle.

That means a standard installation can expose the detection infrastructure across ordinary frontend pages regardless of whether a particular page visibly contains emoji.

If you are auditing other globally loaded JavaScript too, see How to Remove Unused WordPress Scripts.

The title “emoji script” can now be slightly misleading

Historically, developers inspecting WordPress source commonly found a sizeable inline JavaScript block associated with emoji detection inside the document <head>.

That implementation changed.

The official WordPress 6.9 Frontend Performance Field Guide explains that Core converted the emoji detection code from a classic inline script into an inline script module.

It was also moved away from the critical rendering path and toward the footer.

What changed in WordPress 6.9?

Before the optimization, the simplified architecture was:

HTML parsing
↓
emoji detection JavaScript in head
↓
JavaScript executes
↓
HTML parsing continues

The WordPress performance team identified approximately 3 KB of inline JavaScript participating in the critical rendering path.

WordPress 6.9 changed the architecture toward:

HTML parsing
↓
page continues building
↓
emoji script module
↓
deferred execution
↓
fallback detection

Script modules are deferred by their nature, so the browser does not need to stop parsing the document in the same way it would for a traditional blocking inline script.

Why WordPress moved the emoji system to the footer

The emoji fallback is not normally required to produce the page’s primary content.

It is also extremely unlikely to represent the page’s Largest Contentful Paint element.

Core therefore had little reason to give the detector valuable space and execution time in the critical rendering path.

The WordPress 6.9 performance work explicitly deprioritized it for that reason.

The performance improvement was measurable on slower devices

WordPress Core’s published testing found that converting the detector to a script module produced measurable improvements on emulated lower-powered mobile hardware.

The Core performance tests reported approximately:

~7% improvement in FCP
~4% improvement in LCP

from the module conversion under the tested low-tier mobile conditions, with another smaller improvement from moving the detector to the footer under the tested network configuration.

Those figures are benchmark results for a specific WordPress test configuration, not a promise that every production website will improve by the same percentages.

For the broader distinction between individual asset optimizations and total page weight, see Reducing WordPress Front-End Page Weight.

What does the emoji detector actually test?

The detector evaluates whether the browser can correctly render the emoji cases WordPress considers relevant.

The important conceptual sequence is:

Browser loads page
↓
WordPress detection code runs
↓
browser emoji support is tested
↓
supported?
├── yes → native rendering remains sufficient
└── no  → WordPress fallback can be used

This is why calling it an “emoji library” can be misleading.

Its primary job is detection and fallback coordination, not replacing every emoji with an image unconditionally.

WordPress does not necessarily contact the emoji CDN on every page

This is another important distinction.

You may see WordPress configuration referencing:

https://s.w.org/images/core/emoji/...

but that does not mean every normal page view necessarily downloads emoji image files from that host.

The external resources are relevant when fallback behavior is needed.

The current emoji_url filter documentation shows that WordPress’s PNG emoji base URL points to s.w.org.

WordPress also exposes an emoji_svg_url filter for the SVG emoji base URL.

Detection infrastructure and network requests are different things

A page can therefore contain:

emoji detection infrastructure

without necessarily producing:

emoji image CDN request

during that particular visit.

When auditing privacy or performance, inspect the actual Network panel rather than assuming that a URL mentioned in JavaScript configuration was requested.

For a broader network-level audit, see WordPress Privacy and Third-Party Requests.

What happens when fallback is required?

WordPress can use image-based emoji resources when native support is insufficient.

The simplified model is:

Unicode emoji in content
+
insufficient native support
↓
WordPress fallback
↓
emoji image resource

This helps produce a more consistent representation on environments that cannot correctly render the expected emoji.

WordPress also has server-side emoji functionality

The frontend detector is only one part of the WordPress emoji system.

Core also contains PHP functions for processing emojis in other contexts.

For example, the official wp_staticize_emoji() documentation describes a function that converts supported emoji into static image elements.

That means:

disable frontend detector

and:

disable every WordPress emoji-related behavior

are not necessarily identical operations.

WordPress can process emojis in feeds

Current Core attaches:

wp_staticize_emoji

to feed content and feed comment text.

This is separate from the browser detection script.

RSS itself is a different WordPress subsystem. If you are auditing it too, see How WordPress Advertises RSS Feeds by Default.

WordPress can process emojis in HTML email

Core also includes:

wp_staticize_emoji_for_email()

The official wp_staticize_emoji_for_email() documentation shows that WordPress can convert emojis into static images for HTML email messages.

Again, this is independent of whether the normal frontend detector appears in a browser page.

WordPress also includes emoji-related styles

The emoji system is not exclusively JavaScript.

WordPress has styles for image-based emoji fallback output.

Current Core uses:

wp_enqueue_emoji_styles()

to enqueue the relevant CSS.

The official wp_enqueue_emoji_styles() documentation shows that WordPress registers an inline stylesheet under:

wp-emoji-styles

with rules for:

img.wp-smiley
img.emoji

Old emoji-style snippets may now be outdated

Older WordPress tutorials often reference:

print_emoji_styles()

as if it were the primary modern API.

That function was deprecated in WordPress 6.4 in favor of:

wp_enqueue_emoji_styles()

The old callback remains involved for backward compatibility, which is precisely why copying an old four-line optimization snippet without understanding the current hook structure is unreliable.

The official print_emoji_styles() documentation records the deprecation.

For the same reason, broad WordPress cleanup should be based on current Core behavior. See WordPress Head Tags You Can Safely Remove.

Does WordPress still add the emoji detector to wp_head?

Yes, from a hook-registration perspective.

Current WordPress Core still registers:

add_action(
    'wp_head',
    'print_emoji_detection_script',
    7
);

But in modern WordPress that does not mean the final detection module itself must execute there.

The current print_emoji_detection_script() implementation coordinates the actual output with the footer-script lifecycle.

This preserves backward compatibility with existing code that disables the feature by unhooking the function from wp_head.

This backward compatibility is intentional

The WordPress 6.9 Frontend Performance Field Guide explicitly notes that existing code using:

remove_action(
    'wp_head',
    'print_emoji_detection_script',
    7
);

continues to prevent the frontend detection script from being printed.

This matters because the internal implementation changed without forcing every existing site to rewrite its emoji-disable logic.

Can you safely disable the WordPress emoji detector?

For many modern websites, disabling the WordPress emoji fallback is a reasonable choice.

Modern browsers and operating systems have broad native emoji support, so many projects decide that they do not need WordPress to provide additional fallback rendering for older or incomplete environments.

However, the correct question is not:

Does my site use emojis?

It is:

Do I need WordPress's
emoji compatibility fallback?

Your emojis do not disappear when the detector is disabled

This is probably the most important practical point.

Disabling WordPress’s emoji compatibility system does not normally remove Unicode emoji characters from:

• post content;
• page content;
• titles;
• comments;
• menus;
• custom fields;
• database records.

A character such as:

🚀

remains a Unicode character.

Modern browsers can still render it using their native emoji support.

What you lose is WordPress’s fallback layer

The change is closer to:

Before
Unicode emoji
↓
native support check
↓
WordPress fallback if necessary

After
Unicode emoji
↓
native browser / OS rendering

On a modern environment, the visible result may be identical.

On an older or incomplete environment, some newer emoji may render differently, as monochrome glyphs, boxes or unsupported characters.

Do not confuse WordPress emojis with emoticons

WordPress historically also contains functionality around textual emoticons and smileys.

For example:

:-)
;-)

can be conceptually separate from Unicode emoji support.

Removing the modern emoji detection system should not be described as a universal switch for every smiley-related behavior WordPress has ever supported.

How to disable the frontend WordPress emoji detection script

If the only objective is to stop the normal frontend detection module, the backward-compatible removal remains:

add_action(
    'init',
    function () {
        remove_action(
            'wp_head',
            'print_emoji_detection_script',
            7
        );
    }
);

Running the removal from your own initialization code makes the intent explicit after Core’s default hooks have been registered.

Why not edit WordPress Core?

Never remove the emoji code directly from:

wp-includes/

Core files are replaced during WordPress updates.

Direct modifications create:

• update problems;
• maintenance ambiguity;
• security-management problems;
• unnecessary differences from standard Core.

Use hooks, a site plugin, an MU plugin or an appropriate maintained utility instead.

Disabling the script alone is not a complete emoji cleanup

If your goal is:

remove all unnecessary
WordPress emoji support

you should think beyond the frontend detector.

Potential areas include:

• frontend detection;
• admin detection;
• emoji styles;
• embed pages;
• feed staticization;
• email staticization;
• editor integration;
• emoji resource URLs.

The exact scope should match the requirement.

Frontend-only removal and complete removal are different policies

A site might reasonably decide:

Visitors
→ native emoji only

wp-admin
→ keep WordPress emoji support

Another project might decide:

WordPress emoji fallback
→ disabled everywhere

Neither policy should be implemented accidentally.

The WordPress admin has its own emoji hooks

Emoji detection is also connected to WordPress administration screens.

Removing the frontend wp_head callback therefore does not automatically mean every admin-side emoji behavior has been disabled.

This distinction is similar to other WordPress frontend/backend asset boundaries discussed in wp_enqueue_scripts Explained.

Embedded WordPress content is another context

WordPress’s embed templates have their own lifecycle.

Core can attach emoji detection and styles to embed output independently of an ordinary frontend page.

If your optimization policy includes WordPress embeds, audit that system separately.

See How to Disable oEmbed in WordPress for the broader embed architecture.

Do not remove all resource hints just to target emoji

Older optimization snippets sometimes remove:

wp_resource_hints

from wp_head simply because they want to eliminate a WordPress.org-related hint.

That is unnecessarily broad.

The official wp_resource_hints() documentation explains that the system handles browser resource hints generally.

Removing the entire system can discard useful hints unrelated to emoji.

Target the emoji functionality instead of the entire optimization system

This principle applies throughout WordPress optimization:

identify exact feature
↓
remove exact feature

rather than:

find broad WordPress hook
↓
disable everything attached to it

The same approach is important when removing other default WordPress output. See Cleaning Up WordPress’s Default Head Output.

Does the emoji system meaningfully slow down WordPress?

On modern WordPress, the correct answer is:

usually not by very much, but its cost is not literally zero.

WordPress Core has already invested in reducing that cost.

The major WordPress 6.9 change specifically moved the detector away from the critical rendering path because its previous placement had a measurable impact, particularly on lower-powered devices.

Do not exaggerate the optimization

Disabling the emoji system should not be presented as a transformation that will suddenly make a slow WordPress website fast.

In many real projects, larger performance costs come from:

• oversized images;
• large JavaScript bundles;
• page builders;
• third-party trackers;
• web fonts;
• video embeds;
• chat widgets;
• poor caching;
• slow PHP or database work.

Removing emoji support is a small cleanup compared with eliminating hundreds of kilobytes of unnecessary JavaScript.

For a systematic JavaScript audit, see How to Remove Unused WordPress Scripts.

Why remove it if the performance gain is small?

A small optimization can still make architectural sense when:

• the functionality is unnecessary;
• the project supports modern browsers;
• native emoji rendering is acceptable;
• you want fewer default frontend systems;
• you want to minimize potential external asset dependencies;
• you are deliberately reducing frontend output.

The decision is therefore often about removing unnecessary functionality, not chasing a dramatic benchmark improvement.

What about privacy?

The emoji system deserves privacy review because WordPress’s fallback configuration can reference resources on:

s.w.org

When a browser actually requests a remote resource, that creates communication between the visitor and another host.

But the distinction remains important:

URL exists in configuration
≠
browser necessarily requested it

Use the Network panel to determine the site’s actual behavior.

For the wider architectural question, see CDN vs. Self-Hosted Assets in WordPress.

Do not make automatic legal claims from the presence of s.w.org

Whether an external request creates a specific privacy or compliance obligation depends on the actual request, transmitted information, jurisdiction, purpose and broader site implementation.

A technical audit should establish:

Is a request made?
To which host?
When?
What information is transmitted?
Why is it required?

Legal conclusions should then be evaluated in the appropriate context.

Does disabling WordPress emojis improve SEO?

Not directly.

There is no meaningful SEO rule stating:

disable WordPress emojis
=
higher rankings

If removing unnecessary frontend work improves real user performance, that can contribute to a better technical experience.

But the emoji cleanup itself should not be treated as an SEO technique.

Does disabling emojis improve security?

It is not a meaningful WordPress security control by itself.

Removing unnecessary functionality can simplify a system, but disabling the emoji detector does not replace:

• WordPress updates;
• plugin updates;
• strong authentication;
• authorization controls;
• server hardening;
• backups;
• monitoring.

If security is the actual objective, start with a broader process such as A WordPress Login Hardening Checklist rather than treating frontend cleanup as a security boundary.

How to check whether the WordPress emoji system is active

Do not rely only on an optimization plugin’s status label.

Inspect the actual page.

1. View the rendered page source

Search for terms such as:

emoji
_wpemojiSettings
wp-emoji-settings

The exact markup depends on the WordPress version.

2. Check the Network panel

Filter for:

s.w.org
emoji

Remember that no remote request does not necessarily mean the detector itself is absent.

3. Inspect script elements

Modern WordPress versions may expose the emoji detector differently from older installations because the implementation became a script module.

4. Check styles

Search for:

wp-emoji-styles
wp-smiley
img.emoji

5. Test an actual emoji page

Do not test only a page containing plain ASCII text.

Create or use representative content containing:

• a common emoji;
• a skin-tone modifier;
• a flag;
• a multi-person sequence;
• a newer emoji relevant to your supported environments.

Test more than one browser

If you remove a compatibility layer, compatibility testing becomes more important.

At minimum, consider the browsers and operating systems represented by your actual audience.

Possible test environments include:

• current Chrome;
• current Safari;
• current Firefox;
• current Edge;
• iOS;
• Android;
• older supported devices if your project still targets them.

The operating system matters as much as the browser

Emoji glyph support often depends heavily on the underlying operating system and font stack.

Two browsers with similar capabilities can therefore display a newer emoji differently when running on different operating-system versions.

Do not test only whether the character appears

An unsupported sequence can sometimes degrade into multiple individual glyphs rather than disappearing completely.

For example, a combined emoji sequence may render as separate component characters.

Compatibility testing should therefore examine whether the intended representation remains understandable.

Disabling WordPress emojis is usually easier on modern-only projects

If your browser-support policy targets current operating systems and browsers, relying on native emoji rendering is often reasonable.

If the site must support:

• old corporate desktops;
• legacy browsers;
• older embedded browsers;
• unusual kiosk environments;
• long-lived enterprise devices;

the fallback deserves more careful evaluation.

Do not decide from browser market share alone

Your actual analytics are more useful than global browser statistics.

A business application used entirely on managed hardware has different compatibility requirements from a public marketing site.

What if your site never uses emojis?

If the site’s content policy deliberately avoids emojis and you support modern browsers, the WordPress fallback becomes particularly difficult to justify as a required frontend feature.

However, remember that user-generated content may introduce emojis through:

• comments;
• reviews;
• community profiles;
• forum posts;
• product reviews;
• forms that display submitted content.

Audit the entire content model rather than only editorial posts.

What if your site uses many emojis?

Frequent emoji usage does not automatically mean WordPress’s fallback must remain enabled.

The real question is still native support across the environments you support.

A modern site can contain hundreds of Unicode emojis while relying entirely on the visitor’s operating system for rendering.

Emoji appearance can vary between platforms

Native emoji rendering is not visually identical everywhere.

An emoji can look different across:

• Apple platforms;
• Android devices;
• Windows;
• Linux distributions;
• different font packages.

If pixel-identical emoji artwork is a design requirement, relying on ordinary Unicode emoji is already the wrong abstraction.

Use intentional graphical assets for brand-critical illustrations instead.

Emoji should not carry essential meaning alone

Regardless of whether WordPress fallback support is enabled, important information should not depend entirely on a particular emoji rendering.

For example:

🔴

should not be the only indication that a critical system state means “error.”

Use accompanying text and accessible interface semantics.

How WordPress emoji cleanup fits into frontend optimization

A useful optimization hierarchy is:

Measure page
↓
remove large unnecessary features
↓
reduce third-party scripts
↓
fix globally loaded plugin assets
↓
optimize images and fonts
↓
review smaller WordPress defaults
↓
measure again

The emoji system belongs toward the smaller-default-assets end of that process.

It should not distract from substantially larger bottlenecks.

Compare it with other WordPress default assets

Depending on the site, other default or commonly global assets may include:

• block styles;
• Dashicons;
• jQuery;
• jQuery Migrate;
• embed functionality;
• comment-reply JavaScript.

Each requires a separate dependency decision.

For example, jQuery should be audited through its actual dependency graph. See Checking Your Site for Legacy jQuery Dependencies and What Is jQuery Migrate, and Do You Need It?.

Do not create one giant “remove everything WordPress” snippet

Combining unrelated optimizations into one anonymous code block makes future debugging difficult.

Prefer clearly separated controls such as:

disable emoji fallback
disable embeds
remove unused block assets
disable unused Dashicons
remove specific plugin script

Then each decision can be tested and reversed independently.

TheOneWP Disable Emojis module

If the project does not require WordPress’s emoji fallback layer, TheOneWP Disable Emojis provides a dedicated control for removing the WordPress emoji system without editing Core files.

The module removes the relevant WordPress emoji detection output and related support components, including:

• emoji detection scripts;
• related inline styles;
• emoji-related DNS prefetch behavior;
• the TinyMCE emoji plugin.

It does not delete Unicode emoji characters from your content.

The conceptual result is:

WordPress emoji fallback
→ disabled

Unicode emoji content
→ unchanged

browser / OS native emoji rendering
→ remains available

This makes the module appropriate when the requirement is specifically to remove WordPress’s compatibility layer rather than to prohibit emojis from the website.

Why a dedicated module is preferable to unrelated optimization hacks

The emoji system spans more than one output mechanism.

A dedicated implementation can keep the cleanup grouped around one responsibility instead of mixing it with unrelated head, script and editor modifications.

That also makes the configuration easier to understand later:

Disable Emojis
=
we intentionally rely on native emoji support

rather than discovering an unexplained collection of remove_action() calls months later.

When should you keep WordPress emoji support enabled?

Consider keeping it when:

• support for older devices matters;
• emoji compatibility is important to the content;
• you have not tested the supported browser matrix;
• your users regularly submit emoji-heavy content;
• the tiny remaining overhead is irrelevant to the project;
• you prefer WordPress’s compatibility fallback to native-only rendering.

When does disabling it make sense?

Disabling WordPress emoji support is easier to justify when:

• the site targets modern browsers and operating systems;
• native emoji rendering is acceptable;
• legacy fallback support is unnecessary;
• you are deliberately reducing default WordPress frontend output;
• you want to minimize unnecessary external fallback dependencies;
• you have tested representative emoji content after removal.

WordPress emoji audit checklist

• Understand that Unicode emojis and the WordPress emoji fallback are different things.
• Remember that the detector can appear even when a page contains no visible emojis.
• Do not assume every emoji causes an image download.
• Do not assume the presence of an emoji CDN URL means the browser contacted it.
• Inspect the browser Network panel for actual requests.
• Remember that WordPress introduced its emoji support in version 4.2.
• Account for the WordPress 6.9 implementation change.
• Do not describe the current detector as the old blocking head script.
• Remember that WordPress 6.9 converted the detector to a script module.
• Remember that current Core defers the detector toward the footer.
• Do not expect every site to reproduce Core’s benchmark improvements exactly.
• Check whether print_emoji_detection_script() is active.
• Check for wp-emoji-settings in current markup.
• Check for emoji-related styles.
• Understand that print_emoji_styles() has been deprecated since WordPress 6.4.
• Use wp_enqueue_emoji_styles() when reasoning about the current style architecture.
• Do not edit WordPress Core files.
• Use hooks or a maintained module to disable the feature.
• Do not remove the entire resource-hints system merely to target emoji.
• Distinguish frontend emoji detection from admin behavior.
• Distinguish normal frontend pages from WordPress embed pages.
• Remember that feeds can use server-side emoji staticization.
• Remember that HTML email can use server-side emoji staticization.
• Test normal Unicode emojis after disabling the fallback.
• Test newer and combined emoji sequences.
• Test multiple browsers.
• Test relevant operating systems.
• Use actual audience analytics when deciding legacy support.
• Do not treat emoji removal as a major SEO technique.
• Do not treat emoji removal as a security control.
• Do not exaggerate the performance benefit.
• Prioritize larger JavaScript, image, font and third-party bottlenecks first.
• Document why the emoji system was disabled.
• Retest after major WordPress updates because Core implementation details can change.

Related guides

• How to Remove Unused WordPress Scripts
• Reducing WordPress Front-End Page Weight
• WordPress Head Tags You Can Safely Remove
• Cleaning Up WordPress’s Default Head Output
• WordPress Privacy and Third-Party Requests
• CDN vs. Self-Hosted Assets in WordPress

Final recommendation

WordPress loads emoji detection infrastructure by default because it is designed as a compatibility layer, not because every page contains emojis and not because browsers require WordPress to render ordinary Unicode characters.

The architecture is best understood as:

Unicode emoji
↓
native browser / OS support
↓
WordPress checks compatibility
↓
fallback available when needed

That fallback made particularly clear sense when WordPress introduced emoji support in version 4.2, when native emoji capabilities varied much more widely between platforms.

Modern browsers and operating systems now provide much broader native support, which is why many current WordPress projects can reasonably choose to rely on native rendering instead.

WordPress itself has also reduced the cost of keeping the system enabled. Since WordPress 6.9, the detector no longer behaves like the traditional blocking inline JavaScript commonly described in older optimization tutorials. Core converted it to a deferred script module and moved it away from the critical rendering path.

Therefore, disabling WordPress emoji support should not be presented as an essential performance fix.

It is better understood as a deliberate cleanup decision:

Do we need WordPress's
legacy compatibility fallback?

Yes
→ keep it

No
→ remove it
→ rely on native Unicode rendering

If you disable it, verify the result on the browsers and operating systems your audience actually uses, check both ordinary and more complex emoji sequences, and confirm through the Network panel that the frontend behaves as intended.

The goal is not to remove WordPress functionality merely because it exists. The goal is to understand what the functionality does, decide whether the project still needs it and remove only the parts that no longer serve a purpose.