WordPress по умолчанию добавляет поддержку emoji через отдельные скрипты и стили. На небольших сайтах это часто незаметно, но в техническом аудите такие ресурсы всплывают как лишние запросы в <head> и на фронтенде. Если задача — сократить количество подключений без риска для контента, emoji можно отключить аккуратно, не трогая остальную часть ядра.
Когда отключение emoji действительно имеет смысл
Сначала стоит понять, что именно вы хотите убрать: саму возможность вставлять emoji в редакторе или только фронтенд-ресурсы, которые WordPress подгружает для старых браузеров. В большинстве случаев проблема не в функциональности, а в лишнем HTTP-запросе и дополнительном inline-коде в разметке.
Отключение уместно, если:
- вы не используете emoji в контенте и комментариях;
- нужно уменьшить число подключаемых файлов на страницах;
- вы проводите базовую оптимизацию темы или плагина;
- на сайте есть строгие требования к чистоте
<head>.
Если у вас редакторы, где emoji нужны пользователям, лучше отключать только фронтентную часть, а не ломать поддержку в админке.
Диагностика: где WordPress подключает emoji
Проверка простая: откройте исходный код страницы и найдите строки, связанные с wp-emoji-release.min.js. Обычно рядом будет inline-скрипт с настройками для emoji. Ещё один способ — посмотреть вкладку Network в DevTools и отфильтровать запросы по слову emoji.
Если ресурс есть, вы увидите примерно такую картину:
<script src="https://example.com/wp-includes/js/wp-emoji-release.min.js?ver=6.x" defer></script>На некоторых темах и плагинах этот скрипт может быть не самым тяжёлым, но он всё равно лишний, если функциональность не нужна. Важно не удалять его вручную из шаблона темы: после обновления изменения потеряются.
Пошаговое решение через functions.php
Самый надёжный способ — снять стандартные действия WordPress через хук init или after_setup_theme. Для фронтенда и админки логика немного отличается, поэтому лучше использовать готовую функцию в дочерней теме или в собственном мини-плагине.
Вариант 1: отключить emoji полностью
Если emoji не нужны нигде, добавьте код в functions.php дочерней темы или в отдельный плагин:
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' );
} );Этот вариант убирает и фронтенд, и админку, и связанные фильтры для RSS и email. Для большинства сайтов этого достаточно.
Вариант 2: оставить emoji в админке, убрать только на сайте
Если редакторы пользуются emoji в панели управления, а на публичной части они не нужны, можно отключить только фронтенд:
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' );
} );Здесь админка остаётся нетронутой, а на сайте исчезают лишние подключения. Это безопаснее, если у вас несколько авторов и вы не хотите менять их рабочий процесс.
Что выбрать: код, плагин или оптимизатор
Для такой задачи плагин обычно избыточен, но если вы уже используете оптимизатор, отключение emoji может быть частью общей чистки. Например, в Clearfy Pro есть инструменты для удаления лишних элементов WordPress, и это удобнее, чем держать отдельный кусок кода в теме. Но если вам нужен только один точечный фикс, код прозрачнее и легче контролируется.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме/плагине | Точно понятно, что отключено; не зависит от UI | Нужно не забыть перенести при смене темы |
| Оптимизирующий плагин | Удобно для нескольких правок сразу | Лишняя зависимость от настроек плагина |
| Ручное удаление из шаблона | Быстро | Сломается после обновления |
Если вы ведёте сайт как проект, а не как разовую настройку, лучше вынести код в маленький mu-plugin или в собственный плагин. Так решение не исчезнет после смены темы.
Проверка результата после внедрения
После добавления кода откройте сайт в режиме инкогнито и проверьте исходный код страницы. В нём не должно быть wp-emoji-release.min.js и связанных inline-блоков. Затем откройте DevTools → Network и обновите страницу с отключённым кэшем.
Что именно проверить:
- в
<head>нет подключения emoji-скрипта; - в админке, если вы её не отключали, emoji-поддержка осталась;
- RSS-ленты и письма не получили лишнюю замену символов;
- страница не показывает ошибок JavaScript после правки.
Если вы используете кэш-плагин или серверный кэш, очистите его перед проверкой. Иначе можно увидеть старую версию страницы и решить, что код не сработал.
Частые ошибки и как их исправить
Код добавили не туда
Самая частая проблема — вставка в файл активной темы, который потом перезаписывается обновлением. Правильнее использовать дочернюю тему или отдельный плагин. Если сайт уже на продакшене, не редактируйте файлы через встроенный редактор WordPress: при ошибке можно получить недоступность сайта.
Удалили не те хуки
Иногда пытаются убрать только print_emoji_detection_script, забывая про стили и фильтры. В результате часть ресурсов остаётся, а в отчётах оптимизации проблема выглядит «почти решённой». Проверьте весь набор хуков, а не один вызов.
Сломали отображение в письмах или RSS
Если у вас есть рассылки, интеграции с CRM или RSS-агрегаторы, не отключайте фильтры вслепую. Технически они нужны для корректной статической подстановки emoji в текстовых каналах. Если эти каналы важны, тестируйте отдельно.
Ожидали заметный прирост скорости
Отключение emoji — это точечная чистка, а не универсальная оптимизация. Оно полезно как часть общей работы с фронтендом, но не заменяет кэш, минификацию, оптимизацию изображений и контроль сторонних скриптов.
Практические советы по безопасности и производительности
Если вы вносите такие правки на клиентском проекте, держите их в отдельном маленьком плагине или mu-plugin. Тогда код не потеряется при обновлении темы и его проще ревьюить. Для проверки изменений удобно использовать staging-копию сайта, а не боевую среду.
Ещё один полезный приём — фиксировать подобные отключения в списке технических правок проекта. Когда через полгода кто-то спросит, почему emoji не работают в админке или почему их нет в письмах, у вас будет понятная история изменений.
<?php
/**
* Plugin Name: Disable Emoji Support
*/
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, можно посмотреть и на решения уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpsource.ru&utm_medium=article&utm_campaign=kak-otkljuchit-emoji-v-wordpress. Но для одной задачи отдельный кодовый фикс обычно проще и надёжнее.