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

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

Важно понимать: речь не про «сломать эмодзи в контенте», а про отключение служебной проверки и подгрузки JS/CSS, которые WordPress вставляет автоматически. На современных браузерах это обычно не влияет на отображение символов, но может упростить фронтенд и убрать лишнюю работу на каждой странице.

Когда это действительно имеет смысл

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

Типичные сценарии

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

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

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

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

Что именно искать

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

Пошаговое решение через functions.php или мини-плагин

Самый надежный способ — убрать стандартные действия WordPress через remove_action(). Лучше делать это в дочерней теме или в небольшом mu-plugin, если вы не хотите зависеть от темы. Так решение не потеряется после обновления шаблона.

Ниже рабочий вариант, который отключает emoji-скрипты и связанные фильтры. Он подходит для большинства обычных сайтов на WordPress.

<?php
// Убираем emoji-скрипты и фильтры WordPress.
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' );
remove_filter( 'wp_staticize_emoji', 'wp_staticize_emoji' );

Если вы хотите оформить это как отдельный мини-плагин, создайте файл в wp-content/mu-plugins/disable-emojis.php. Это удобно для технической поддержки: код не зависит от активной темы и не исчезнет после редизайна.

<?php
/**
 * Plugin Name: Disable Emojis
 */

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' );
remove_filter( 'wp_staticize_emoji', 'wp_staticize_emoji' );

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

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

Подход	Плюсы	Минусы
Код в теме или mu-plugin	Контроль, минимум зависимостей, легко проверить	Нужно не забыть про обновления и место размещения
Оптимизирующий плагин	Удобно, если уже используется для других задач	Может конфликтовать с кешем или минификацией
Ничего не делать	Нет риска сломать что-то лишнее	Лишний код остается в `<head>` и на почте/RSS

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

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

Что должно измениться:

в <head> больше не должно быть emoji detection script;
в Network не должен грузиться wp-emoji-release.min.js;
RSS и письма не должны получать статическую подмену emoji через фильтры WordPress;
страница должна открываться без JS-ошибок, связанных с этим отключением.

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

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

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

Если вставить remove_action() в файл, который выполняется слишком поздно, WordPress уже успеет добавить emoji-скрипты. В таком случае код нужно перенести в functions.php дочерней темы или в mu-plugin, где он сработает на раннем этапе загрузки.

Кеш не очищен

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

Плагин оптимизации возвращает скрипт обратно

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

Отключили не то и сломали письма

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

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

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

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

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

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

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

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