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

Автор: София Николаева | Опубликовано: 07.09.2026

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

Важно понимать: речь не о «запрете смайликов» как таковых. WordPress просто перестаёт подгружать скрипт и стили для старой совместимости с браузерами, а сам контент с Emoji продолжает работать, потому что современные браузеры и так умеют их отображать.

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

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

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

Диагностика: что именно добавляет WordPress

Перед изменениями посмотрите исходный код страницы. Обычно в <head> можно увидеть подключение скрипта wp-emoji-release.min.js и связанных inline-обработчиков. На фронтенде это видно и в DevTools на вкладке Network.

Проверить наличие можно и без браузера:

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

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

Что не стоит путать с проблемой Emoji

Иногда лишние запросы в <head> появляются не из-за Emoji, а из-за:

плагинов аналитики и маркетинга;
встроенных шрифтов и иконок темы;
лишних preconnect/dns-prefetch;
скриптов редактора, которые подключаются только в админке, но попали на фронтенд из-за ошибки темы.

Поэтому сначала убедитесь, что вы отключаете именно Emoji, а не пытаетесь лечить этим все проблемы производительности сразу.

Пошаговое решение: отключаем Emoji через functions.php

Самый прозрачный способ — снять стандартные действия WordPress на init и wp_print_styles. Это удобно, если вы контролируете тему или дочернюю тему и хотите видеть код в репозитории.

<?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' );
} );

Код лучше добавлять в дочернюю тему или в небольшой mu-plugin, если вы не хотите зависеть от обновлений темы. Для production-проекта mu-plugin часто практичнее: он не отключится случайно после смены темы.

Альтернатива: мини-плагин для отключения Emoji

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

<?php
/**
 * Plugin Name: Disable Emoji Support
 */

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' );
} );

Файл можно положить в отдельную папку в wp-content/plugins/disable-emoji-support/ и активировать как обычный плагин. Для такой задачи это честнее, чем ставить тяжёлый оптимизатор ради одной функции.

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

Подход	Когда подходит	Плюсы	Минусы
Код в дочерней теме	Вы ведёте тему и контролируете деплой	Просто, прозрачно, без лишних зависимостей	Сломается при смене темы, если забыть перенести код
Мини-плагин / mu-plugin	Нужно отделить техправки от темы	Не зависит от дизайна, легко переносится	Нужно следить за структурой плагинов
Оптимизатор с чекбоксом	Уже используется на сайте для других задач	Быстро включить без кода	Лишняя зависимость, иногда больше настроек, чем нужно

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

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

После изменения откройте главную страницу и проверьте исходный код. В <head> не должно быть wp-emoji-release.min.js и связанных стилей. Это базовая проверка, но её недостаточно.

Дальше сделайте три шага:

Откройте страницу в режиме инкогнито и убедитесь, что визуально ничего не сломалось.
Проверьте консоль браузера на ошибки JavaScript.
Посмотрите Network: лишний запрос на emoji-скрипт должен исчезнуть.

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

Быстрая проверка через WP-CLI

Если на сервере доступен WP-CLI, можно убедиться, что код не вернулся через кэш или старую тему, но сам факт отключения удобнее проверять по HTML. Для автоматизации достаточно простого запроса:

wp option get blogname

Это не проверка Emoji напрямую, а лишь способ убедиться, что WP-CLI и доступ к сайту работают. Для реальной валидации лучше использовать curl и поиск по HTML, как показано выше.

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

Код добавили не туда. Если вставить его в файл, который не загружается на фронтенде, ничего не изменится. Для темы используйте functions.php дочерней темы, для независимого решения — mu-plugin или обычный плагин.
Проверяют только админку. Emoji-скрипт может быть убран с фронтенда, но в редакторе или админке вы увидите старое поведение из-за кэша или потому, что смотрите не ту страницу.
Не очищают кэш. После правки HTML часто остаётся старым в плагине кэша, CDN или серверном кеше.
Смешивают с другими оптимизациями. Если одновременно отключить Emoji, jQuery Migrate и ещё несколько скриптов, потом сложно понять, что именно сломало страницу.
Ожидают заметного прироста скорости. Это точечная чистка, а не магическая оптимизация. Эффект обычно небольшой, но он измеряемый и полезен в рамках общей гигиены фронтенда.

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

Не удаляйте встроенные функции WordPress «в лоб» через правку ядра. После обновления всё вернётся, а вы потеряете контроль над изменениями. Используйте только код на уровне темы, mu-plugin или отдельного плагина.

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

Для проектов с жёсткими требованиями к скорости полезно вести короткий чек-лист технической чистки:

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

Если вам нужен более широкий набор инструментов для чистки WordPress, отключения дублей и технических хвостов, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но для одной задачи с Emoji отдельный код обычно проще и надёжнее.

В итоге проверка сводится к двум вещам: в HTML больше нет emoji-скрипта, а сайт продолжает нормально работать в редакторе и на фронтенде. Если оба условия выполнены, правка сделана корректно.