В WordPress поддержка emoji включена по умолчанию и тянет за собой дополнительный JavaScript, стили и проверки в браузере. На небольшом сайте это обычно незаметно, но на проектах, где уже вычищают лишние запросы и считают каждый ресурс, этот хвост часто просто не нужен. Особенно если контент в основном на русском, а эмодзи используются редко или вообще не используются.
Ниже — рабочая схема: как понять, что именно грузится, как отключить emoji безопасно, и как проверить, что после правки не поехала админка, редактор или фронтенд.
Что именно отключаем и где это видно
В WordPress emoji-логика состоит не только из одного скрипта. Обычно это:
- скрипт
wp-emoji-release.min.jsна фронтенде и в админке; - фильтры, которые подмешивают inline-стили и detection script;
- дополнительная обработка в редакторе и комментариях.
Если открыть исходный код страницы или вкладку Network в DevTools, можно увидеть запрос к wp-emoji-release.min.js. На некоторых темах и плагинах он грузится и там, где эмодзи не используются вообще. Это и есть основной кандидат на отключение.
Когда отключение действительно уместно
Сценарий простой: сайт не использует emoji как часть интерфейса, не строит на них контент и не зависит от старых браузеров, которым нужен polyfill. Тогда отключение — это не «оптимизация ради оптимизации», а нормальная чистка лишнего поведения ядра.
Если у вас редакция, где эмодзи — часть контента, или есть аудитория со старыми браузерами, сначала проверьте, не ломается ли отображение символов в нужных местах. WordPress сам по себе не запрещает emoji, он просто добавляет поддержку там, где она может не понадобиться.
Диагностика: как понять, что emoji реально грузятся
Перед правкой не нужно гадать. Проверьте три места:
- Исходный код фронтенда: ищите
wp-emoji-release.min.js. - Админку и редактор: откройте любую запись и посмотрите Network.
- Консоль браузера: убедитесь, что нет ошибок после отключения.
Если используете Query Monitor, можно быстро увидеть подключенные скрипты и стили. Это удобнее, чем вручную искать по HTML, особенно если тема или плагины добавляют свои обертки.
Еще один практический тест: откройте страницу в приватном окне без кэша и посмотрите, исчез ли запрос к emoji-скрипту после внедрения решения. Если запрос остался, значит отключение сработало не полностью или его снова подключает тема/плагин.
Пошаговое решение через functions.php или mu-plugin
Самый надежный вариант — убрать emoji через код. Лучше не править тему напрямую, если у вас есть дочерняя тема или отдельный mu-plugin для технических правок.
Добавьте в functions.php дочерней темы или в отдельный файл в wp-content/mu-plugins/ такой код:
<?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' );
} );Этот вариант убирает стандартные точки подключения emoji в фронтенде, админке и RSS/почте. На обычных сайтах этого достаточно.
Почему лучше делать это на init
Функции ядра уже зарегистрированы к моменту init, поэтому remove_action() и remove_filter() отрабатывают предсказуемо. Если пытаться снять их слишком рано, можно попасть в ситуацию, когда код есть, а эффекта нет.
Если у вас очень кастомная сборка темы, и emoji снова появляются, проверьте, не добавляет ли их плагин через собственный inline-скрипт. Тогда отключение на уровне ядра не решит вопрос полностью.
Альтернатива: отключить emoji через плагин чистки
Если на сайте уже стоит плагин для технической оптимизации, проще использовать его, чем размазывать код по теме. Например, в Clearfy Pro есть функции для отключения лишних элементов WordPress, включая emoji и другие стандартные «хвосты» ядра.
Плюс плагина в том, что правки можно включать и выключать из интерфейса без редактирования PHP. Минус — еще один слой абстракции и зависимость от настроек плагина. Если задача точечная и вы ведете проект как разработчик, код обычно прозрачнее.
| Подход | Что дает | Компромисс |
|---|---|---|
Код в functions.php или mu-plugin | Полный контроль, минимум лишнего | Нужно следить за обновлениями и местом размещения |
| Плагин оптимизации | Быстро включить без кода | Зависимость от интерфейса и набора опций |
| Ничего не делать | Нулевая вероятность сломать текущую сборку | Лишние запросы и стандартное поведение ядра остаются |
Проверка результата после внедрения
После отключения проверьте не только визуально, но и технически.
- Откройте страницу в режиме инкогнито и убедитесь, что
wp-emoji-release.min.jsбольше не загружается. - Проверьте HTML исходник: не должно быть подключения emoji detection script в
<head>. - Откройте админку и редактор записей: интерфейс должен работать без ошибок в консоли.
- Если есть кэш-плагин или серверный кэш, очистите его и повторите тест.
Для быстрой проверки можно использовать поиск по исходнику страницы или DevTools. Если в Network запрос исчез, а ошибок нет, решение сработало.
Что считать нормальным результатом
Нормально, если:
- страница открывается без визуальных артефактов;
- в консоли нет новых ошибок;
- в исходнике не видно emoji detection script;
- редактор и комментарии работают как раньше.
Если сайт использует RSS-ленты или email-уведомления, проверьте и их тоже. В коде выше мы убираем статическую обработку emoji для feed и email, поэтому лучше убедиться, что письма и ленты не потеряли нужное форматирование.
Частые ошибки и как их исправить
Отключили только фронтенд, а в админке скрипт остался
Это типичная ситуация, когда снимают только wp_head, но забывают про admin_print_scripts и admin_print_styles. Если вас раздражает именно лишняя нагрузка в админке, убирайте обе стороны.
Код добавили в активную тему, а после обновления он пропал
Так бывает, если правка сделана в родительской теме. Для технических отключений лучше использовать дочернюю тему или mu-plugin. Тогда обновление темы не сотрет изменения.
После отключения сломались emoji в письмах или RSS
Значит, вы убрали только визуальную часть, но не проверили фильтры wp_staticize_emoji и wp_staticize_emoji_for_email. Верните нужные фильтры или отключайте только фронтенд, если почтовые шаблоны завязаны на emoji.
Скрипт продолжает грузиться из-за темы или плагина
Иногда emoji подключает не ядро, а сторонний код. Тогда ищите по проекту строку wp-emoji-release.min.js или вызовы, связанные с emoji detection. В таком случае отключение через remove_action() не даст полного эффекта, пока не уберете источник повторного подключения.
Что еще стоит вычистить рядом с emoji
Если вы уже занимаетесь технической чисткой WordPress, emoji обычно идут в одном пакете с другими мелкими оптимизациями: отключением лишних эмодзи в RSS, удалением wp_generator, чисткой oEmbed, отключением XML-RPC, если он не нужен, и ревизией подключаемых скриптов в теме. Но не стоит сваливать все в один комок без проверки — каждое отключение нужно тестировать отдельно.
Практика здесь простая: меняете одну настройку, проверяете результат, только потом идете дальше. Так проще понять, что именно повлияло на фронтенд, админку и индексацию.
Если нужен более «безопасный» путь без ручного кода, можно собрать такие отключения в одном техническом плагине или использовать Clearfy Pro как слой управления стандартными функциями WordPress. Но даже в этом случае проверка через DevTools и тестовый прогон в админке обязательны.
