WordPress до сих пор может добавлять на сайт служебные скрипты и стили для emoji. На современных проектах это часто лишняя нагрузка: несколько дополнительных подключений в <head>, один внешний DNS-запрос в старых сценариях и небольшой, но ненужный шум в HTML. Сам по себе этот код обычно не ломает сайт, но на технически аккуратных проектах его имеет смысл убрать.
Важно не путать отключение emoji-скриптов с отключением поддержки emoji вообще. Речь о фронтенд-обвязке WordPress, а не о том, чтобы запретить пользователям вставлять символы. В админке и редакторе блоков ничего критичного трогать не нужно.
Когда это реально имеет смысл
Отключать emoji-скрипты стоит не ради «магической оптимизации», а когда вы уже чистите фронтенд от мелких лишних подключений. Обычно это оправдано, если:
- вы смотрите на HTML и видите
wp-emoji-release.min.jsв шапке; - нужно сократить число запросов на страницах с высокой посещаемостью;
- вы используете строгую политику по внешним ресурсам и хотите убрать старые служебные подключения;
- сайт проходит аудит производительности, и вы убираете всё, что не влияет на контент.
Если у вас старый проект с кастомной темой, сначала проверьте, не завязан ли кто-то из скриптов темы на порядок загрузки в wp_head. В нормальной установке отключение emoji не вызывает проблем.
Диагностика: где именно WordPress добавляет emoji
По умолчанию WordPress подключает emoji через набор действий и фильтров в ядре. На фронтенде это обычно видно в исходном коде страницы. Ищите такие признаки:
wp-emoji-release.min.js;- инлайн-скрипт с проверкой поддержки canvas;
- подключение
wp-emoji-settingsв HTML; - лишние строки в
<head>, которые не нужны для контента.
Проверить можно прямо в браузере: откройте исходный код страницы и найдите emoji. Если подключение есть, а вы его не хотите, переходите к отключению через код.
Пошаговое решение через functions.php или мини-плагин
Самый безопасный вариант — не править ядро и не лезть в файлы WordPress, а добавить небольшой код в дочернюю тему или в свой mu-plugin. Так вы не потеряете изменения после обновления темы.
Вариант 1: код в 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 в служебных каналах. Для большинства сайтов этого достаточно.
Вариант 2: отдельный mu-plugin
Если вы не хотите зависеть от темы, создайте файл, например wp-content/mu-plugins/disable-emoji.php:
<?php
/**
* Plugin Name: Disable Emoji Scripts
*/
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 удобен тем, что он не отключится случайно после смены темы или обновления шаблона.
Сравнение подходов: код, плагин, ничего не делать
| Подход | Что даёт | Минус |
|---|---|---|
| Код в дочерней теме | Быстро и прозрачно | Зависит от темы |
| mu-plugin | Не слетает при смене темы | Нужно один раз настроить доступ к файлам |
| Ничего не делать | Ноль риска для админки | Лишние служебные подключения остаются |
Если у вас уже есть технический плагин для чистки WordPress, например Clearfy Pro, проверьте, не отключает ли он emoji через готовую настройку. В таком случае отдельный код может быть не нужен.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой. Сделайте три шага:
- Откройте главную страницу и несколько внутренних страниц в режиме просмотра исходника.
- Найдите
wp-emoji-release.min.jsи связанные инлайн-скрипты. - Проверьте, что в
<head>больше нет emoji-обвязки.
Если используете инструменты разработчика, посмотрите вкладку Network. На чистом фронтенде запрос к emoji-скрипту исчезает. На части сайтов он может не быть внешним, а генерироваться локально — тогда ориентируйтесь именно на отсутствие подключения в HTML.
Дополнительно проверьте:
- открывается ли редактор записей в админке;
- не пропали ли emoji в комментариях и письмах, если они вам нужны;
- не ругаются ли кэш-плагины на изменившийся HTML.
Частые ошибки и как их исправить
Код добавили, но emoji-скрипт остался
Чаще всего причина в том, что код вставили слишком поздно или не туда. Если тема уже вывела часть head-кода, а вы пытаетесь снять действия после этого, результат будет неполным. Используйте init или mu-plugin, а не случайный хук в шаблоне.
Отключили не только фронтенд, но и нужную обработку в письмах
Если вы убрали фильтры wp_staticize_emoji_for_email и потом увидели странное поведение в уведомлениях, верните этот фильтр обратно. Для большинства сайтов он не критичен, но если у вас есть интеграции с почтой и шаблонами писем, лучше тестировать отдельно.
Сломали кэш или минификацию
Некоторые оптимизаторы собирают HTML и ожидают определённый порядок скриптов. После отключения emoji очистите кэш страницы, кэш плагина и, если нужно, CDN. Иначе вы будете смотреть на старую версию HTML и решите, что код не работает.
Чек-лист перед публикацией изменений
- Код добавлен в дочернюю тему или mu-plugin, а не в ядро WordPress.
- Проверен исходный код страницы.
wp-emoji-release.min.jsбольше не выводится на фронтенде.- Админка и редактор открываются без ошибок.
- Кэш сайта очищен после правки.
- Если есть письма и RSS, проверено, что нужная обработка не сломалась.
Что ещё можно убрать рядом с emoji, если вы чистите фронтенд
Если задача не ограничивается emoji, обычно рядом смотрят и другие служебные вещи: wp-embed, лишние стили темы, неиспользуемые блоки, дублирующиеся подключения шрифтов. Но убирать всё подряд не стоит. Сначала измерьте, что реально грузится на страницах, и только потом отключайте конкретный код.
Для аккуратной технической чистки удобно использовать либо собственный мини-плагин, либо набор настроек в специализированном плагине. Главное — не превращать оптимизацию в набор случайных отключений без проверки результата.