WordPress до сих пор по умолчанию подгружает скрипт для emoji, даже если сайт не использует их активно. На небольших проектах это обычно незаметно, но на технически аккуратных сборках лишние подключения лучше убрать: меньше запросов, чище head, меньше поводов для вопросов в аудите производительности.
Важно понимать, что речь не о «ускорении в разы», а о точечной чистке фронтенда. Если у вас уже настроен кеш, минификация и нормальная тема, эффект будет скромным, но предсказуемым. И именно это обычно и нужно.
Когда отключение emoji действительно имеет смысл
Сценарий простой: сайт не использует старые браузерные fallback-механизмы для emoji, а в HTML все равно присутствуют подключения, связанные с wp-emoji-release.min.js. Это не критическая проблема, но она часто всплывает в Lighthouse, WebPageTest или при ручном просмотре исходника страницы.
Отключать emoji имеет смысл, если:
- сайт работает на современной аудитории и не ориентирован на очень старые браузеры;
- вы хотите убрать лишний JavaScript из
<head>; - проект проходит технический аудит и нужно сократить шум в исходнике;
- вы поддерживаете кастомную тему или набор плагинов и следите за минимализмом фронтенда.
Что именно добавляет WordPress
По умолчанию WordPress подключает набор фильтров и скрипт, который помогает отображать emoji в старых окружениях. На практике это означает дополнительные inline-скрипты и внешний файл, который не нужен большинству современных сайтов. Убирать это лучше штатно, а не через правку ядра или темы.
Диагностика: как понять, что emoji реально грузятся
Перед правкой проверьте исходник страницы. Откройте главную или любую внутреннюю страницу и найдите в HTML упоминания wp-emoji-release.min.js, emoji или inline-скрипт, который вызывает wpEmojiSettingsSupports. Если они есть, значит WordPress действительно добавляет этот блок.
Еще один быстрый способ — DevTools в браузере. На вкладке Network отфильтруйте запросы по слову emoji и обновите страницу. Если видите отдельный JS-запрос, его можно убрать штатным способом.
Что проверить до изменений
- Есть ли у вас кастомный код в
functions.php, который уже отключает emoji. - Не использует ли тема сторонние библиотеки, завязанные на стандартные скрипты WordPress.
- Нет ли плагина оптимизации, который сам удаляет 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-скрипт и стили в фронтенде и админке, а также убирает преобразование emoji в RSS и письмах. Для большинства сайтов этого достаточно.
Если вам нужно убрать только фронтенд, а в админке оставить стандартное поведение, можно ограничиться удалением только wp_head и фронтенд-стилей. Но обычно проще и чище использовать полный вариант выше, если у вас нет особых требований к старым окружениям.
Альтернатива через плагин
Если вы не хотите держать такой код вручную, можно использовать плагин оптимизации, который умеет отключать emoji вместе с другими мелкими настройками чистки. Например, в Clearfy Pro это относится к типичным задачам технической оптимизации и отключения лишнего мусора в WordPress. Смысл не в самом плагине, а в том, чтобы не разбрасывать десяток мелких правок по разным местам.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в дочерней теме / мини-плагине | Прозрачно, без лишних зависимостей | Нужно не забыть при миграции |
| Плагин оптимизации | Удобно для нескольких задач сразу | Лишний слой настроек |
| Правка ядра | Быстро на первый взгляд | Сломается при обновлении, так делать не стоит |
Проверка результата после внедрения
После добавления кода откройте страницу в режиме инкогнито и проверьте исходник. В HTML больше не должно быть wp-emoji-release.min.js и inline-блока с настройками emoji. Затем откройте DevTools → Network и обновите страницу: отдельного запроса к emoji-скрипту быть не должно.
Если используете кеш-плагин или серверный кеш, очистите его перед проверкой. Иначе вы можете смотреть на старую версию страницы и сделать ложный вывод, что код не сработал.
Что считать нормальным результатом
- в исходнике нет emoji-скрипта;
- в Network не появляется отдельный JS-запрос, связанный с emoji;
- админка продолжает работать как обычно;
- комментарии, RSS и письма не показывают странные артефакты.
Если сайт использует только современную аудиторию, визуально ничего не изменится. Это и есть ожидаемый результат: убрать лишнее без побочных эффектов.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить фрагмент в файл темы, который не загружается на всех страницах, отключение сработает частично. Надежнее использовать functions.php дочерней темы или отдельный мини-плагин.
Очистили кеш, но видите старый HTML
Частая причина — кеш на стороне плагина, сервера или CDN. После изменений нужно сбросить все уровни кеширования, иначе проверка будет некорректной.
Плагин оптимизации уже делает то же самое
Если у вас включена аналогичная опция в плагине, повторное отключение через код не нужно. Два одинаковых решения не дают двойного эффекта, зато усложняют диагностику, когда что-то идет не так.
Сломали админку из-за агрессивной чистки
Такое бывает, если вместе с emoji начинают отключать слишком много штатных скриптов WordPress. Не смешивайте эту задачу с удалением jquery, wp-embed или других зависимостей, если не понимаете цепочку влияния.
Чек-лист перед публикацией изменений
- Сделали бэкап или хотя бы внесли правку в версионно контролируемый файл.
- Проверили, что код подключается на всех нужных страницах.
- Очистили кеш WordPress, сервера и CDN.
- Сравнили исходник страницы до и после.
- Открыли сайт в инкогнито и убедились, что фронтенд работает без ошибок.
Практические советы по безопасности и поддержке
Не правьте ядро WordPress и не вносите изменения напрямую в файлы плагинов. Любое обновление сотрет такие правки, а восстановление потом занимает больше времени, чем нормальная реализация через тему или мини-плагин.
Если у вас несколько сайтов на одном шаблоне, вынесите отключение emoji в общий mu-plugin. Это удобнее для поддержки, чем копировать один и тот же код по разным установкам. Но если проект маленький, не усложняйте архитектуру без причины: дочерней темы обычно достаточно.
Для сайтов, где важна полная техническая чистота, отключение emoji лучше рассматривать вместе с другими мелкими оптимизациями: удалением лишних эмбедов, ревизий, неиспользуемых скриптов и мусора в head. Но каждую правку проверяйте отдельно, иначе потом сложно понять, что именно дало эффект или вызвало проблему.