Как отключить Emoji в WordPress без плагинов: код, диагностика и проверка результата

Встроенная поддержка Emoji в WordPress часто остаётся включённой по умолчанию, даже если на сайте она не нужна. На небольших проектах это не критично, но на технически аккуратных сайтах лишние скрипты, стили и DNS-запросы лучше убрать. Особенно если вы уже чистите head, сокращаете количество запросов и следите за тем, что реально используется на фронтенде.

Ниже — рабочий способ отключить Emoji без плагинов, понять, что именно было загружено, и проверить результат после изменений. Подход подходит для темы, дочерней темы или небольшого must-use плагина.

Что именно отключаем и откуда берётся нагрузка

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

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

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

Перед отключением полезно проверить, есть ли они в текущей сборке. Это занимает пару минут и помогает не гадать, а смотреть на факты.

Проверка в исходном коде страницы

Откройте любую страницу сайта и найдите в исходнике:

• wp-emoji-release.min.js;
• строки с emoji в <head>;
• подключения из wp-includes/js/wp-emoji-release.min.js.

Если скрипт есть, значит WordPress всё ещё добавляет поддержку Emoji на фронтенде.

Проверка в DevTools

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

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

Самый безопасный вариант — добавить код в functions.php дочерней темы или в собственный мини-плагин. Для проекта с несколькими правками я бы предпочёл отдельный mu-plugin: так код не потеряется при смене темы.

Вариант 1: отключить Emoji через хуки WordPress

<?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 в контенте и письмах.

Вариант 2: отключить Emoji через mu-plugin

Если не хотите держать такую правку в теме, создайте файл wp-content/mu-plugins/disable-emoji.php. Если папки mu-plugins нет, создайте её вручную.

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

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

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

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

<?php
add_action( 'init', function () {
    if ( ! is_admin() ) {
        remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
        remove_action( 'wp_print_styles', 'print_emoji_styles' );
    }
} );

Такой вариант не трогает админку, но убирает лишнее на публичной части сайта.

Сравнение подходов

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

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

После добавления кода откройте сайт в режиме инкогнито и проверьте три вещи:

• в исходном коде страницы больше нет wp-emoji-release.min.js;
• в <head> не осталось emoji-стилей;
• в Network не появляется отдельный запрос на emoji-скрипт.

Дополнительно проверьте письма WordPress, если сайт отправляет уведомления. В редких случаях Emoji в email могут быть полезны для визуального оформления, но на большинстве технических проектов это не требуется.

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

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

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

Если вставить правку в файл, который не загружается на фронтенде, результата не будет. Для темы это должен быть активный functions.php, для стабильного варианта — mu-plugins.

Отключили только один хук

Иногда убирают только print_emoji_detection_script, но оставляют стили или фильтры для RSS и email. В итоге часть функциональности остаётся, а лишний код всё ещё висит в системе. Лучше отключать набором, как в примере выше.

Не очистили кеш

Если сайт стоит за серверным кешем, CDN или плагином кеширования, старый HTML может показываться ещё какое-то время. После правки очистите все уровни кеша.

Сломали письмо или RSS

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

Что ещё стоит проверить вместе с отключением Emoji

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

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

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

• Код добавлен в functions.php дочерней темы или в mu-plugins.
• Проверен исходный код страницы на наличие wp-emoji-release.min.js.
• Очищен кеш сайта, сервера и CDN.
• Проверены письма и RSS, если они используются.
• Отключение не продублировано другим плагином оптимизации.

Если задача — именно убрать лишнюю техническую нагрузку, а не просто «почистить код», такой сценарий даёт предсказуемый результат и не требует вмешательства в ядро WordPress.