WordPress до сих пор может подгружать служебные emoji-скрипты и стили, даже если сайт не использует встроенную поддержку старых браузеров. На небольшом проекте это не критично, но на нагруженной теме или при строгой оптимизации фронтенда лишние запросы лучше убрать. Важно сделать это аккуратно: не трогать то, что нужно редактору, и проверить, что после правки не появились ошибки в админке.
Когда отключение emoji действительно имеет смысл
Сценарий простой: вы открываете страницу в DevTools и видите отдельный запрос к wp-emoji-release.min.js или инлайн-обработчики emoji в wp-head. Если сайт рассчитан на современные браузеры, эти ресурсы обычно не дают пользы. На практике это полезно для:
- лендингов и корпоративных сайтов, где важна чистая фронтенд-загрузка;
- проектов с жёстким бюджетом по количеству запросов;
- сайтов, где уже есть собственная оптимизация скриптов и стилей;
- случаев, когда нужно убрать один из источников лишнего JS без установки отдельного плагина.
Если у вас аудитория со старыми браузерами или вы не уверены, что тема не завязана на эти стили, сначала проверьте поведение на тестовой копии сайта.
Диагностика: откуда берутся emoji-запросы
В WordPress emoji-логика подключается через стандартные действия в wp_head и admin_print_scripts. Это значит, что отключать её лучше на уровне хуков, а не правкой ядра или темы. Перед изменениями откройте исходный код страницы и найдите:
wp-emoji-release.min.js;- инлайн-скрипт с проверкой поддержки emoji;
- подключение в админке, если оно мешает только на фронтенде;
- кэш плагина или CDN, который может скрывать эффект после правки.
Если запросов не видно, но в коде страницы остаются emoji-обработчики, значит оптимизация частичная и нужно смотреть не только сетевые запросы, но и HTML-вывод.
Пошаговое решение без лишнего риска
Самый надёжный вариант — отключить emoji через remove_action() в дочерней теме или в небольшом mu-plugin. Так вы не потеряете правку после обновления темы.
Вариант 1: код в дочерней теме
Добавьте в 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' );
} );Этот вариант убирает и JS, и стили emoji на фронтенде и в админке. Если вам важно оставить админку без изменений, можно ограничиться только фронтендом, но тогда код будет чуть длиннее.
Вариант 2: отключить только на фронтенде
Если в редакторе или в админке вы хотите оставить стандартное поведение WordPress, используйте более точечный вариант:
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Так вы не вмешиваетесь в админскую часть, а на публичных страницах убираете лишние подключения.
Вариант 3: mu-plugin для проектов с несколькими темами
Если тема меняется или сайт обслуживается командой, удобнее вынести код в wp-content/mu-plugins/disable-emojis.php. Это снижает риск, что кто-то забудет перенести правку при смене темы.
<?php
/**
* Plugin Name: Disable Emojis
*/
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Для mu-plugin не нужен обычный экран активации: файл достаточно положить в правильную папку.
Сравнение подходов: плагин, код или ничего не делать
| Подход | Что даёт | Компромисс |
|---|---|---|
| Код в дочерней теме | Быстро убирает emoji без плагинов | Привязан к теме, нужно не забыть при миграции |
| mu-plugin | Стабильнее для нескольких тем и окружений | Нужно один раз правильно развернуть файл |
| Оставить как есть | Ничего не ломается и не нужно поддерживать код | Лишние запросы и HTML-обработчики остаются |
Если у вас уже стоит плагин оптимизации, проверьте, не делает ли он это автоматически. Дублировать одно и то же в двух местах не стоит: потом сложно понять, что именно отключило скрипт.
Как проверить, что решение сработало
После правки не ограничивайтесь визуальной проверкой страницы. Нужны три шага:
- Откройте исходный код страницы и убедитесь, что
wp-emoji-release.min.jsбольше не выводится. - Проверьте вкладку Network в DevTools и обновите страницу с отключённым кэшем браузера.
- Зайдите в админку и убедитесь, что редактор, меню и форма входа работают без ошибок JavaScript.
Если у вас включён серверный или плагинный кэш, очистите его перед проверкой. Иначе можно увидеть старую версию HTML и сделать ложный вывод, что код не сработал.
Частые ошибки и как их исправить
Правка сделана в родительской теме
После обновления тема перезапишется, и emoji-скрипты вернутся. Перенесите код в дочернюю тему или mu-plugin.
Отключили только один хук
Иногда убирают wp_head, но забывают про стили или админские подключения. В результате часть следов остаётся, а эффект выглядит неполным.
Проверяют без очистки кэша
Кэш страницы, CDN или браузерный кэш часто маскируют реальный результат. После изменения кода всегда делайте принудительное обновление и сброс кэша на уровне сайта.
Смешали оптимизацию emoji с минификацией
Если плагин оптимизации уже объединяет и откладывает скрипты, не дублируйте отключение вручную без необходимости. Иначе потом сложнее искать источник ошибки, если что-то сломается в админке.
Что ещё стоит проверить рядом с этой настройкой
Отключение emoji — мелкая, но полезная часть общей технической чистки. Если вы уже работаете с фронтенд-оптимизацией, имеет смысл заодно посмотреть на:
- лишние подключения CSS и JS в теме;
- неиспользуемые иконки и шрифты;
- дубли мета-тегов и canonical;
- лишние REST API-запросы на страницах, где они не нужны;
- кэширование HTML и статики.
Если нужен более широкий аудит технических дублей и мусора, в экосистеме WPShop для этого есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для самой задачи отключения emoji достаточно и обычного кода.
Безопасность и производительность: на что не наступить
Не редактируйте ядро WordPress и не правьте файлы плагинов вручную. Это ломает обновления и усложняет поддержку. Для таких мелких оптимизаций лучше использовать дочернюю тему или mu-plugin. Если сайт под управлением нескольких разработчиков, зафиксируйте изменение в репозитории, чтобы не потерять его при деплое.
И ещё один практический момент: если вы отключаете emoji ради ускорения, не ждите магического эффекта. Это точечная оптимизация, а не замена нормальной работы с кэшем, изображениями и скриптами. Проверяйте результат в контексте всей страницы, а не по одному удалённому запросу.