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

Автор: Вадим Жуков | Опубликовано: 12.09.2026

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

Если задача не в том, чтобы «сломать эмодзи», а в том, чтобы убрать ненужные ресурсы аккуратно, лучше делать это точечно: отключить только фронтенд-часть, проверить админку и убедиться, что сторонние плагины не возвращают эти скрипты обратно.

Когда отключение emoji действительно имеет смысл

Сценарий простой: на сайте не используют emoji в контенте как отдельную функциональность, а в исходнике страницы видны подключения wp-emoji-release.min.js и связанных inline-скриптов. Обычно это не критичная проблема, но на проектах с жесткой оптимизацией фронтенда такие мелочи лучше убирать системно.

Особенно это полезно, если вы:

собираете сайт под строгий контроль количества запросов;
оптимизируете <head> и чистите лишние inline-скрипты;
работаете с кэшем и хотите уменьшить число ресурсов, которые нужно обслуживать;
поддерживаете старый проект, где накопилось много мелких оптимизаций.

Диагностика: как понять, что emoji-скрипты реально загружаются

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

wp-emoji-release.min.js;
inline-скрипт с проверкой поддержки canvas для emoji;
подключение через wp_print_styles или wp_head в HTML.

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

Еще один важный момент: отключение emoji на фронтенде не всегда означает полное отключение в админке. Это нормально. Редактор и панель управления могут продолжать использовать свои ресурсы, если они нужны для совместимости.

Пошаговое решение без плагинов

Самый предсказуемый способ — добавить код в functions.php дочерней темы или в собственный мини-плагин. Так вы не зависите от настроек стороннего плагина и точно понимаете, что именно отключаете.

1. Уберите 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' );
} );

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

2. Если нужен более мягкий вариант, отключайте только фронтенд

Иногда админку трогать не стоит, особенно если редакторы активно работают в блоковом редакторе и не хочется ловить побочные эффекты. Тогда можно убрать только фронтенд-подключение:

add_action( 'init', function () {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );

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

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

Подход	Что дает	Минус
Код в теме или мини-плагине	Полный контроль, минимум зависимости	Нужно не забыть про обновления темы и дочернюю тему
Плагин для оптимизации	Удобно, если уже используете набор оптимизаций	Еще одна точка конфигурации, возможны лишние функции
Ничего не делать	Ноль риска сломать совместимость	Лишние ресурсы в HTML и Network

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

Проверка результата после внедрения

После добавления кода не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что ресурсы исчезли именно там, где вы ожидали.

Откройте страницу в режиме инкогнито.
Посмотрите исходный код и убедитесь, что нет wp-emoji-release.min.js.
Проверьте вкладку Network и обновите страницу с отключенным кэшем браузера.
Если используете page cache или CDN, очистите кэш на всех уровнях.
Проверьте и фронтенд, и админку, если отключали скрипты глобально.

Дополнительно можно выполнить быстрый поиск по HTML-ответу через консоль:

curl -s https://example.com/ | grep -i emoji

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

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

Код добавили не туда

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

Очистили кэш не полностью

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

Отключили слишком много

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

Проверяли только визуально

То, что эмодзи отображаются в контенте, еще не означает, что скрипт исчез. Иногда браузер подставляет символы сам, а лишний JS все равно грузится. Проверяйте именно HTML и Network.

Практические советы по безопасности и производительности

Отключение emoji — мелкая оптимизация, но такие изменения лучше вносить по правилам:

не редактируйте functions.php основной темы на боевом сайте без бэкапа;
если используете мини-плагин, храните его в репозитории или хотя бы в отдельной папке с понятным названием;
после правки проверяйте не только главную, но и записи, страницы, архивы и админку;
не смешивайте эту оптимизацию с агрессивной минификацией, если не уверены, что именно ломает фронтенд;
фиксируйте изменения в changelog проекта, чтобы потом не искать, почему исчезли ресурсы из <head>.

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

В итоге проверка сводится к одному вопросу: исчез ли emoji-скрипт из публичной части без побочных эффектов. Если да — задача решена корректно. Если нет — ищите, кто именно возвращает его обратно: тема, плагин оптимизации, кэш-слой или кастомный код в wp_head.