Как отключить Emoji в WordPress и убрать лишние запросы из фронтенда

Автор: Игорь Фомин | Опубликовано: 13.09.2026

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

Важно понимать: речь не о том, чтобы «сломать смайлики», а о том, чтобы отключить именно встроенную проверку и подгрузку emoji-ресурсов WordPress там, где она не нужна. В большинстве случаев контент при этом не страдает: обычные Unicode-символы и системные emoji в браузерах продолжают отображаться.

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

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

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

Диагностика: как понять, что WordPress грузит emoji

Проверка занимает пару минут. Откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или инлайн-скрипт, который добавляет классы emoji и no-js. Если сайт подключает их, значит, встроенная поддержка активна.

Еще один способ — вкладка Network в DevTools. После загрузки страницы посмотрите, есть ли запрос к файлу из /wp-includes/js/wp-emoji-release.min.js. На некоторых конфигурациях он может быть замаскирован кешем, но в списке ресурсов его все равно видно.

Что именно нужно проверить

есть ли wp-emoji-release.min.js в исходнике;
не добавляет ли тема или плагин собственную замену emoji;
не ломается ли отображение символов в редакторе и на фронтенде после отключения;
не используется ли старый браузерный парк, где это может быть важно.

Пошаговое решение: отключаем emoji через код

Самый предсказуемый способ — добавить фильтры в functions.php дочерней темы или в небольшой mu-plugin. Так вы не зависите от настроек темы и не теряете правку после обновления.

<?php
// Отключаем emoji-скрипты и стили WordPress.
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' );
} );

add_filter( 'emoji_svg_url', '__return_false' );

Этот вариант убирает и фронтенд, и админку. Если вам нужно оставить emoji в редакторе, но убрать только на сайте, не трогайте админские хуки:

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );

add_filter( 'emoji_svg_url', '__return_false' );

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

Если удобнее через плагин оптимизации

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

Подход	Плюсы	Минусы
Код в теме или mu-plugin	Прозрачно, быстро, без лишних зависимостей	Нужно не забыть при переносе сайта
Плагин оптимизации	Удобно для нескольких настроек сразу	Риск дублей функций и конфликтов
Ничего не делать	Ноль действий	Лишние запросы и лишний код на фронтенде

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

Проверка результата после внедрения

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

Откройте страницу сайта в режиме инкогнито.
Посмотрите исходный код и убедитесь, что wp-emoji-release.min.js отсутствует.
Откройте DevTools → Network и обновите страницу.
Проверьте, что запросов к emoji-скрипту больше нет.
Создайте или отредактируйте запись в админке и убедитесь, что редактор работает нормально.

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

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

Отключили только один хук

Частая ошибка — убрать только print_emoji_detection_script, но оставить стили или SVG URL. В результате часть связанного кода все еще остается. Для чистого отключения лучше убрать весь набор хуков, а потом проверить исходник страницы.

Добавили код в родительскую тему

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

Сделали дублирование через плагин и код

Когда emoji отключают одновременно в плагине и в functions.php, потом сложно понять, что именно влияет на результат. Если что-то перестало работать, сначала временно оставьте только один способ.

Не очистили кеш

После изменения кода старый HTML может продолжать отдаваться из кеша. В такой ситуации в исходнике вы все еще увидите старый скрипт, хотя код уже исправлен. Очистка кеша — обязательный шаг проверки.

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

Отключение emoji само по себе не дает драматического ускорения, но это нормальная часть технической уборки. Такие мелкие правки имеют смысл в сумме: меньше лишних запросов, меньше стороннего кода, проще контроль над фронтендом.

Если вы ведете сайт как проект, а не как набор разрозненных правок, держите подобные изменения в одном месте: mu-plugin, репозиторий темы или отдельный слой технических настроек. Тогда проще откатить правку, сравнить поведение после обновлений и не искать, кто именно отключил тот или иной хук.

Для проверки после любых изменений полезно держать короткий чек-лист:

исходник страницы не содержит emoji-скрипт;
в Network нет запроса к wp-emoji-release.min.js;
админка и редактор открываются без ошибок;
кеш очищен и страница проверена в инкогнито;
нет второго решения, которое делает то же самое параллельно.

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