Если на сайте WordPress не нужен встроенный emoji-скрипт, его можно убрать без плагинов. Это полезно на проектах, где важны чистый фронтенд, контроль над подключаемыми ресурсами и отсутствие лишних HTTP-запросов. Решение простое, но важно отключать не только скрипт на фронтенде, а все связанные с ним фильтры и эмодзи-стили в админке, если они действительно не нужны.
Ниже — рабочий сценарий: что отключать, где это делать, как проверить, что WordPress больше не грузит emoji, и какие побочные эффекты встречаются чаще всего.
Когда отключение emoji действительно уместно
Встроенная поддержка emoji в WordPress нужна в основном для старых браузеров и совместимости с частью контента. На современных проектах она часто не дает практической пользы, но добавляет лишний JavaScript, фильтры в wp_head и иногда дополнительные запросы к ресурсам.
Отключать emoji имеет смысл, если:
- сайт работает на современном стеке и не ориентирован на старые браузеры;
- вы вручную контролируете фронтенд и хотите убрать лишние подключения;
- на сайте уже есть собственная политика по оптимизации head и assets;
- нужно сократить шум в отчете по производительности без риска для контента.
Если у вас редакция с активной работой в админке и много авторов, отключение лучше делать аккуратно и проверять именно в редакторе, а не только на публичной странице.
Диагностика проблемы: что именно подключает WordPress
Перед правкой кода полезно убедиться, что речь действительно об emoji-скрипте WordPress, а не о чем-то стороннем. Откройте исходный код страницы и найдите строки, связанные с wp-emoji-release.min.js или фильтрами emoji в wp_head. Обычно они выглядят как отдельный inline-скрипт и подключение файла из /wp-includes/js/wp-emoji-release.min.js.
Проверить можно и через DevTools:
- Откройте страницу сайта в браузере.
- Перейдите во вкладку Network.
- Обновите страницу и отфильтруйте запросы по слову
emoji. - Посмотрите, есть ли запрос к
wp-emoji-release.min.jsили связанные inline-обработчики.
Если запросов нет, а в коде страницы emoji-скрипт не появляется, значит проблема уже решена на уровне темы, плагина оптимизации или кэша. В этом случае не стоит добавлять еще один слой отключения, чтобы не усложнять поддержку.
Как отключить emoji через functions.php или mu-plugin
Самый надежный способ — добавить код в дочернюю тему или в mu-plugin. Для продакшена mu-plugin удобнее: код не потеряется при обновлении темы и не зависит от переключения шаблона.
Вариант для дочерней темы
Добавьте в 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' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
} );Этот набор отключает и фронтенд, и админку, и обработку emoji в контенте и письмах. Если вам нужно убрать только фронтенд, можно не трогать админские хуки, но на практике чаще отключают все сразу, когда проект полностью контролируется.
Вариант для mu-plugin
Создайте файл, например wp-content/mu-plugins/disable-emoji.php, и поместите туда тот же код. Минимальный рабочий вариант:
<?php
/**
* Plugin Name: Disable Emoji
*/
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' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
} );mu-plugins не требует активации в админке, и это удобно, если вы не хотите зависеть от действий редакторов или администраторов сайта.
Сравнение подходов: плагин, код, оптимизатор
Если задача точечная, код обычно надежнее. Но иногда удобнее использовать уже установленный оптимизатор, если он и так закрывает несколько задач сразу.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Код в functions.php | Быстро, без лишних зависимостей | Слетает при смене темы | Для дочерней темы и небольших сайтов |
mu-plugin | Не зависит от темы, легко контролировать | Нужно один раз создать файл | Для продакшена и проектов с техподдержкой |
| Плагин оптимизации | Удобно, если уже используется | Может дублировать другие настройки | Если нужен единый интерфейс для нескольких оптимизаций |
Если вы уже используете инструменты класса Clearfy Pro для чистки WordPress, проверьте, не отключен ли emoji там. В таком случае не нужно добавлять второй способ в тему — достаточно оставить один источник настройки, иначе потом сложно понять, кто именно что отключил.
Проверка результата после внедрения
После добавления кода проверьте не только главную страницу, но и админку, RSS и письма, если вы отключали фильтры полностью.
- Откройте исходный код страницы и найдите
wp-emoji-release.min.js— его быть не должно. - Проверьте Network в DevTools: запросов к emoji-скрипту быть не должно.
- Откройте редактор записей и убедитесь, что он работает без визуальных ошибок.
- Если на сайте есть комментарии или RSS, проверьте, что текст отображается нормально.
Для быстрой проверки можно использовать поиск по исходнику страницы. Если в HTML по-прежнему есть вызовы print_emoji_detection_script или ссылки на emoji-ресурсы, значит код не сработал или был подключен слишком поздно.
Частые ошибки и как их исправить
Код добавили не туда
Самая частая проблема — вставка в файл активной темы, который потом перезаписывается обновлением. Для продакшена лучше использовать дочернюю тему или mu-plugin.
Отключили только фронтенд
Иногда убирают только wp_head, а в админке emoji-скрипт остается. Это не ошибка, если вы сознательно хотите оставить поддержку в редакторе. Но если цель — полная чистка, проверьте и админские хуки.
Сломали письма или RSS
Если убрать фильтры без понимания, где они используются, можно получить неожиданный результат в email-уведомлениях или RSS-ленте. Обычно это не критично, но на проектах с автоматическими рассылками лучше сначала протестировать письма на тестовом ящике.
Конфликт с плагином оптимизации
Если emoji уже отключен в плагине кэширования или оптимизации, ваш код не даст заметного эффекта, но усложнит поддержку. В такой ситуации оставьте один способ отключения и удалите дублирующий.
Практические советы по безопасности и производительности
Отключение emoji само по себе не делает сайт быстрее радикально, но помогает убрать лишний код из базовой загрузки. Чтобы не получить хаос в оптимизациях, держите такие изменения в одном месте и документируйте их в репозитории или в заметке проекта.
Если вы ведете несколько сайтов на одной инфраструктуре, удобно хранить подобные правки в отдельном mu-plugin с понятным названием. Тогда любой разработчик быстро увидит, что именно отключено и почему.
И еще один практический момент: не отключайте то, что не проверили. Если сайт обслуживает старую аудиторию, использует нестандартные формы или интеграции с письмами, сначала прогоните тест на staging-окружении, а уже потом переносите изменение в продакшен.
В итоге задача сводится к одному: убрать emoji там, где он не нужен, но не размазывать настройку по теме, плагинам и ручным правкам. Чем меньше мест, где это отключается, тем проще сопровождать сайт.