Как отключить emoji в WordPress без лишнего кода и потери совместимости

Автор: Дмитрий Петров | Опубликовано: 18.09.2026

В WordPress поддержка emoji включена по умолчанию и тянет за собой небольшой набор скриптов и фильтров. На одном сайте это почти незаметно, на другом — лишний запрос в <head>, дополнительная работа на фронтенде и шум в аудите производительности. Если задача простая — убрать именно встроенный механизм WordPress, а не «сломать эмодзи вообще», — это лучше делать точечно.

Ниже — рабочий сценарий: как отключить emoji в WordPress через код, когда достаточно плагина, как проверить результат и где чаще всего ошибаются.

Когда отключение emoji действительно имеет смысл

Отключать встроенную поддержку стоит не ради «магии ускорения», а когда вы видите конкретную причину:

в отчёте Lighthouse или WebPageTest есть лишний запрос к wp-emoji-release.min.js;
на сайте не используется старый контент, который зависит от преобразования emoji в JS;
нужно сократить количество подключаемых ресурсов на страницах с высокой нагрузкой;
вы поддерживаете сайт, где редакторы уже вставляют emoji нативно, а не через старый механизм WordPress.

Если у вас активны плагины для комментариев, форумов или внешних виджетов, сначала проверьте, не рассчитывают ли они на стандартные фильтры WordPress. Обычно это редкость, но на старых сборках и кастомных темах такое встречается.

Диагностика: что именно подключает WordPress

Проверка занимает пару минут и помогает не гадать. Откройте исходный код страницы и найдите:

wp-emoji-release.min.js;
inline-скрипт с проверкой поддержки emoji;
подключение в админке, если вы смотрите не только фронтенд.

Если используете DevTools, смотрите вкладку Network и фильтруйте по emoji. На части сайтов файл может быть закеширован, поэтому лучше проверять и в режиме инкогнито, и после очистки кэша плагина/CDN.

Что важно не перепутать

Отключение emoji в WordPress не удаляет символы emoji из базы и не запрещает их ввод. Оно убирает именно встроенную обвязку WordPress, которая нужна для старых браузеров. Для современных сайтов это обычно безопасно, если вы не держите поддержку очень старых клиентов.

Пошаговое решение через functions.php или mu-plugin

Самый предсказуемый вариант — снять стандартные действия WordPress на init и wp_print_styles. Лучше положить код в mu-plugin, если сайт обслуживается командой и тема может меняться. Для разовой правки допустим functions.php дочерней темы.

<?php
/**
 * Disable WordPress emoji scripts and styles.
 */
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' );
} );

Этот вариант убирает фронтенд и админские подключения, а также фильтры, которые WordPress применяет к RSS и письмам. Если вам нужно отключить только фронтенд, а в админке оставить всё как есть, не снимайте админские действия.

Если нужен только фронтенд

Иногда редакторам удобнее оставить поведение в админке, но убрать лишний код на публичных страницах. Тогда можно ограничиться только фронтендом:

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_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' );
} );

Этот вариант обычно достаточно безопасен для обычных корпоративных и контентных сайтов.

Сравнение вариантов: код, плагин, ничего не делать

Подход	Что даёт	Минус
Код в `functions.php` или `mu-plugin`	Полный контроль, без лишних зависимостей	Нужно не забыть про обновления темы и перенос на staging
Плагин для оптимизации, например Clearfy Pro	Отключение части лишних функций без ручного кода	Добавляется ещё один слой настроек и зависимость от плагина
Ничего не менять	Нулевой риск вмешательства	Лишние ресурсы остаются, если они реально мешают

Если на сайте уже используется набор оптимизационных настроек, логично проверить, не отключены ли emoji там. Дублировать одно и то же в теме и в плагине не стоит: потом сложнее понять, что именно сработало.

Как проверить, что решение сработало

Проверка должна быть не «на глаз», а по фактам:

Откройте страницу сайта в режиме инкогнито.
Посмотрите исходный код и убедитесь, что wp-emoji-release.min.js больше не выводится.
Проверьте вкладку Network — запрос к emoji-скрипту должен исчезнуть.
Зайдите в админку и откройте редактор записи: интерфейс должен работать как раньше.
Если у вас RSS-ленты или рассылка через wp_mail, проверьте, что emoji в тексте не превратились в странные символы.

Для быстрой проверки можно выполнить поиск по исходнику страницы:

curl -s https://example.com/ | grep -i emoji

Если строка не возвращается, это хороший знак. Но всё равно проверьте несколько шаблонов страниц: главную, запись, архив и страницу с комментариями, если они есть.

Частые ошибки и как их исправить

Код добавили не туда

Если вставить фрагмент в родительскую тему, он может исчезнуть после обновления. Для постоянной правки лучше использовать дочернюю тему или mu-plugin.

Сняли действия слишком рано

Иногда код размещают на слишком раннем хуке или вообще вне WordPress-контекста. В таком случае remove_action() просто не находит нужные callback'и. Рабочий вариант — выполнять снятие на init, как в примере выше.

Отключили emoji, но скрипт всё равно остался

Частая причина — кэш страницы, CDN или оптимизатор, который хранит старую версию HTML. Очистите кэш на всех уровнях: плагин кэша, серверный кэш, CDN, браузер.

Сломали RSS или письма

Если вы убрали только фронтенд, а в письмах или лентах emoji ведут себя странно, проверьте фильтры wp_staticize_emoji и wp_staticize_emoji_for_email. Их лучше снимать только если вы понимаете, где именно используется этот вывод.

Безопасность и производительность: что учесть перед выкладкой

Само отключение emoji — безопасная правка, но в продакшене важен порядок действий. Сначала внесите изменения на staging, затем прогоните базовую проверку страниц, и только после этого переносите на боевой сайт. Если сайт обслуживается несколькими разработчиками, зафиксируйте изменение в репозитории, а не в ручной правке через редактор темы.

Если вы уже используете плагин оптимизации, не включайте в нём и ручной код одновременно. Двойная настройка редко ломает сайт, но создаёт ложные выводы при диагностике: кажется, что emoji отключены «не до конца», хотя на деле вы просто смотрите на старый кэш или дублирующийся фильтр.

Для сайтов, где важна минимизация фронтенд-ресурсов, разумно проверить и другие встроенные функции WordPress, которые давно не нужны конкретному проекту. Но делать это стоит по одной правке за раз, чтобы можно было быстро откатить изменения, если что-то пошло не так.

⭐⭐⭐⭐⭐