WordPress до сих пор по умолчанию подгружает поддержку Emojis через отдельный скрипт и стили. На небольшом сайте это не выглядит критично, но в техническом аудите такие запросы часто всплывают как лишние: они не нужны, если редакторы не вставляют эмодзи из старых браузерных сценариев, а фронтенд получает дополнительный JS и один лишний HTTP-запрос.
Если задача — немного подчистить загрузку страницы без риска сломать контент, отключение Emoji-поддержки как раз из этой категории. Ниже — как понять, что именно у вас грузится, какие есть варианты отключения и как проверить, что ничего не сломалось.
Что именно отключаем и где это видно
В стандартной установке WordPress Emoji-поддержка добавляет на сайт скрипт wp-emoji-release.min.js и связанные с ним фильтры. Обычно это видно в исходном коде страницы или в DevTools на вкладке Network. На практике запрос может приходить с домена сайта и появляться даже там, где эмодзи не используются вообще.
Когда отключение уместно
- сайт работает на современных браузерах, и поддержка старых сценариев не нужна;
- вы хотите убрать один-два лишних запроса из фронтенда;
- на сайте есть строгие требования к чистоте HTML и минимизации подключаемых ресурсов;
- вы уже используете оптимизацию через кеширование и хотите убрать совсем очевидный «шум».
Когда лучше не трогать
- если редакторы массово вставляют эмодзи через старые интерфейсы и вы не уверены, как это отразится на отображении;
- если сайт обслуживает очень старые браузеры или корпоративные среды с ограничениями;
- если вы не можете быстро проверить результат на staging.
Диагностика: как убедиться, что Emoji-поддержка реально грузится
Перед изменениями посмотрите исходник страницы. Ищите упоминания wp-emoji-release.min.js или инлайн-скрипта, который добавляет классы и проверяет поддержку эмодзи. Удобнее всего делать это в браузере через просмотр кода страницы или через DevTools.
Если нужен быстрый технический способ, откройте страницу и выполните в консоли:
performance.getEntriesByType('resource').filter(r => r.name.includes('wp-emoji'))Если массив не пустой, ресурс действительно загружается. Это полезно до и после правки: сравнение будет честным, без догадок.
Пошаговое решение: отключаем Emojis кодом
Самый надежный вариант — убрать стандартные действия WordPress через remove_action() и фильтр emoji_svg_url. Такой способ не зависит от интерфейса плагина и прозрачен для поддержки.
<?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' );
add_filter( 'emoji_svg_url', '__return_false' );
} );Код можно добавить в дочернюю тему или в собственный мини-плагин. Если вы правите тему, не кладите это в родительскую тему: при обновлении изменения потеряются.
Если нужен более безопасный вариант для проекта с несколькими сайтами
Когда у вас сеть сайтов или несколько окружений, лучше вынести отключение в маленький must-use плагин. Тогда логика не зависит от темы и не исчезнет после редизайна.
<?php
/**
* Plugin Name: Disable Emojis
*/
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' );
} );Альтернатива через плагин: когда код трогать не хочется
Если на сайте уже используется плагин для технической чистки, отключение Emojis часто есть в его настройках. Это удобно для редакторов и владельцев проекта, но важно понимать компромисс: вы зависите от интерфейса плагина и его обновлений.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или MU-плагине | Прозрачно, предсказуемо, не зависит от UI | Нужен доступ к файлам и базовое понимание WordPress |
| Настройка в плагине | Быстро, без правки кода | Зависимость от стороннего плагина и его логики |
| Ничего не делать | Ноль риска для текущей конфигурации | Лишний запрос и лишний JS остаются |
Если у вас уже стоит технический плагин для чистки сайта, имеет смысл проверить, не решает ли он эту задачу вместе с другими мелкими оптимизациями. Например, в Clearfy Pro есть набор настроек для отключения лишних функций WordPress; это удобно, когда вы хотите собрать такие правки в одном месте. Ссылку на продукт лучше открывать с UTM-метками: Clearfy Pro.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что скрипт действительно исчез, а контент не изменился.
- Откройте страницу в режиме инкогнито.
- Проверьте исходный код на наличие
wp-emoji-release.min.js. - Сравните список ресурсов в Network до и после.
- Проверьте записи и комментарии, где есть эмодзи, если они используются на сайте.
- Посмотрите, не осталось ли старого кеша страницы.
Для быстрой проверки в консоли можно снова выполнить:
performance.getEntriesByType('resource').filter(r => r.name.includes('wp-emoji'))Если массив пустой, а в исходнике нет упоминаний Emoji-скрипта, задача выполнена. Если ресурс всё ещё есть, чаще всего причина в кеширующем плагине, CDN или в том, что код добавлен не в тот хук.
Частые ошибки и как их исправить
Код добавили слишком поздно
Если remove_action() вызывается не на init, а позже, WordPress уже успевает зарегистрировать вывод Emoji-скрипта. В таком случае отключение не сработает. Перенесите код на ранний хук.
Правят родительскую тему
После обновления темы все изменения пропадут. Для таких правок используйте дочернюю тему или MU-плагин.
Проверяют без очистки кеша
Кеш страницы, объектный кеш или CDN могут отдавать старую версию HTML. После внедрения очистите кеш на всех уровнях, иначе вы увидите старый результат и решите, что код не работает.
Отключают не только Emojis, но и лишнее по цепочке
Иногда вместе с Emoji-скриптом случайно удаляют другие действия из wp_head. Это уже риск для темы и плагинов. Не трогайте чужие хуки без необходимости.
Безопасность и производительность: что учесть на практике
Отключение Emojis — это не «ускорение в разы», а точечная уборка. Смысл в том, чтобы убрать ненужный код и не плодить мелкие запросы. На проектах с жесткой оптимизацией такие правки важны именно в сумме.
- делайте изменения сначала на staging;
- сохраняйте код в отдельном мини-плагине, если правка нужна надолго;
- после внедрения прогоняйте страницу через DevTools и проверяйте список ресурсов;
- не используйте сомнительные «оптимизаторы», которые отключают всё подряд без разбора.
Если на сайте уже идет системная чистка технического мусора, удобнее держать такие настройки в одном месте, а не разносить по functions.php и случайным сниппетам. Это снижает риск забыть, где именно лежит правка, и упрощает поддержку проекта.
В итоге отключение Emojis — это простая и проверяемая техническая задача: нашли лишний запрос, убрали его штатными хуками WordPress, очистили кеш и подтвердили результат в исходнике и Network. Именно такой подход безопаснее, чем ручное редактирование шаблонов и бессистемная оптимизация «на глаз».