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

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

Если задача стоит практическая — убрать именно emoji-механику, не ломая редактор и не трогая лишнее, — лучше действовать точечно. Ниже разберём, что именно отключать, как проверить результат и где чаще всего ошибаются.

Что именно добавляет WordPress и почему это видно в head

На стороне фронтенда WordPress может выводить:

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

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

Диагностика: как понять, что emoji действительно грузятся

Проверка занимает минуту и не требует плагинов. Откройте любую публичную страницу сайта и посмотрите исходный код. Ищите строки вроде:

<script src="https://s.w.org/images/core/emoji/15.0.3/svg/emoji.js"></script>

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

Дополнительно можно проверить в DevTools на вкладке Network, фильтруя по emoji или s.w.org. Если запрос есть, отключение имеет смысл. Если запросов нет, значит тема или оптимизатор уже убрали их раньше, и повторно вмешиваться не нужно.

Как отключить emoji правильно

Самый надёжный способ — снять стандартные действия WordPress через remove_action(). Это безопаснее, чем править ядро или вырезать код из темы вручную.

Вариант через functions.php дочерней темы

Добавьте код в 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' );
} );

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

Вариант через 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' );
} );

Для продакшена это удобнее: код не потеряется при смене темы и не зависит от того, кто редактирует шаблон.

Сравнение подходов: плагин, код или оптимизатор

Подход	Когда уместен	Плюсы	Минусы
Код в `functions.php`	Один сайт, есть дочерняя тема	Быстро, прозрачно, без лишних зависимостей	Сломается при смене темы, если код не перенесут
MU-plugin	Несколько сайтов или нужен стабильный техдолг	Не зависит от темы, легко контролировать	Нужно один раз правильно развернуть
Плагин оптимизации	Уже используется для чистки head и кеша	Удобно собрать всё в одном месте	Можно случайно отключить лишнее вместе с emoji

Если у вас уже стоит инструмент для технической чистки, например Clearfy Pro, проверьте, не отключена ли эта опция там. В таком случае не нужно дублировать логику кодом и плагином одновременно.

Пошаговое решение без побочных эффектов

Проверьте исходный код страницы и убедитесь, что emoji-скрипт реально присутствует.
Сделайте резервную копию или работайте на staging-копии.
Добавьте код отключения в functions.php дочерней темы или в mu-plugin.
Очистите кеш сайта, сервера и CDN, если они есть.
Повторно откройте страницу в режиме инкогнито и проверьте исходник.

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

Как проверить, что решение сработало

Проверка должна быть не визуальной, а технической.

В исходном коде страницы больше нет ссылок на emoji и s.w.org в контексте emoji-скрипта.
В Network не появляется отдельный запрос на emoji-файл.
Админка продолжает работать, редактор записей не ломается.
RSS-ленты и письма, если вы их используете, не получили неожиданных изменений в символах.

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

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

Удалили код не в том месте

Ошибка типовая: remove_action() вызывают слишком рано или слишком поздно. Если WordPress ещё не зарегистрировал нужные действия, удаление не сработает. В примере выше код обёрнут в init, и этого достаточно для стандартного сценария.

Отключили emoji через обрезку head в шаблоне

Иногда разработчики просто удаляют вызов wp_head() или вырезают часть шаблона. Это плохая идея: вместе с emoji исчезнут метатеги, стили плагинов, canonical и другие важные вещи. Так делать не стоит.

Сломали админку или письма

Если после правки в админке пропали стили или в письмах стали странно отображаться символы, значит вы отключили не только фронтенд. Проверьте, не убрали ли вы фильтры для RSS и email без необходимости.

Проверяли без очистки кеша

Это одна из самых частых причин ложных срабатываний. После изменения кода всегда чистите кеш страницы, объектный кеш, если он есть, и CDN.

Когда лучше не отключать emoji

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

Для большинства технически обслуживаемых сайтов отключение emoji — нормальная и безопасная оптимизация. Но она должна быть частью общей чистки, а не отдельной «магической» правкой. Если вы уже убираете лишнее из <head>, имеет смысл параллельно проверить дубли метатегов, лишние эмбед-скрипты и служебные подключения темы.

Практический чек-лист перед выкладкой в продакшен

Проверен исходный код до изменений.
Код добавлен в дочернюю тему или mu-plugin.
Очистен кеш WordPress, сервера и CDN.
Проверен фронтенд в инкогнито.
Проверена админка и редактор записей.
Проверены RSS и отправка писем, если они используются.

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