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

Автор: Кирилл Карпов | Опубликовано: 28.09.2026

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

Ниже разберём, что именно отключать, как проверить, что изменения сработали, и где чаще всего ломают поведение сайта, когда пытаются «оптимизировать всё подряд».

Что именно мешает и как это выглядит в коде страницы

В WordPress emoji поддерживаются через набор скриптов и фильтров, которые добавляют в страницу дополнительные подключения. На практике это выглядит так:

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

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

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

Отключение уместно, если:

сайт работает на современном стеке и не ориентирован на очень старые браузеры;
вы хотите уменьшить количество лишних запросов и inline-кода;
в проекте важна аккуратная техническая гигиена: SEO, производительность, чистый head;
вы не используете кастомную логику, завязанную на emoji-поддержку WordPress.

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

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

Самый простой способ — открыть исходный код страницы и поискать wp-emoji-release.min.js или emoji в блоке <head>. Ещё один вариант — посмотреть список запросов в DevTools на вкладке Network и отфильтровать по слову emoji.

Если вы работаете на локальной копии или staging, можно проверить и через консоль браузера:

document.querySelectorAll('script[src*="wp-emoji-release"], style#wp-emoji-styles').length

Если результат больше нуля, значит WordPress всё ещё добавляет эти элементы на страницу.

Пошаговое решение: отключаем emoji без лишнего риска

Самый надёжный способ — добавить небольшой код в 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 только на публичной части сайта, не трогайте админские хуки.

Если нужен только фронтенд

add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_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' );
} );

Такой вариант безопаснее для админки, если вы не хотите вмешиваться в поведение панели управления без необходимости.

Что выбрать: код, плагин или пакетная оптимизация

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

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

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

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

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

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

Дополнительно можно проверить через консоль:

document.querySelectorAll('script[src*="wp-emoji-release"], style#wp-emoji-styles').length

Ноль означает, что подключение убрано с текущей страницы.

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

Отключили не там, где нужно

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

Сломали админку или email-вывод

Иногда пытаются удалить вообще все фильтры, не понимая, что часть из них влияет на письма и RSS. Если вам нужен только фронтенд, не трогайте admin_print_scripts и admin_print_styles.

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

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

Смешали несколько оптимизационных плагинов

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

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

Не вносите такие правки напрямую в functions.php активной темы на боевом сайте без резервной копии. Если код окажется с синтаксической ошибкой, можно получить недоступную админку. Безопаснее сначала проверить на staging.

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

Для проектов, где важна именно системная чистка WordPress, имеет смысл смотреть на инструменты, которые закрывают несколько задач сразу, а не только один косметический эффект. Но даже в этом случае сначала проверяйте, что конкретно отключается и не влияет ли это на нужные вам функции.

Короткий чек-лист перед публикацией

Код добавлен в дочернюю тему или мини-плагин.
Очистен кэш плагина, сервера и CDN.
В исходном коде страницы больше нет wp-emoji-release.min.js.
В админке не сломались редактор и комментарии.
Проверка выполнена в инкогнито и без старого кэша браузера.

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