WordPress до сих пор может подключать отдельные скрипты и стили для поддержки emoji. На небольшом сайте это редко заметно, но на проекте с жесткой оптимизацией фронтенда лишние запросы лучше убрать: меньше HTTP-запросов, чище head, проще контролировать сборку ассетов. Важно делать это аккуратно, потому что речь не о «ускорении в вакууме», а об отключении конкретного набора действий ядра.
Когда это вообще имеет смысл
Отключать emoji-скрипты стоит не потому, что это модно, а если вы уже вычищаете фронтенд: собираете критический CSS, режете лишние подключения, следите за количеством запросов и хотите убрать то, что не влияет на основной сценарий чтения сайта. Если аудит Lighthouse или ручная проверка показывает, что в <head> есть подключение wp-emoji-release.min.js, а вам оно не нужно, это нормальный кандидат на отключение.
Если сайт работает в закрытой среде или аудитория не использует старые браузеры, практическая ценность emoji-поллифа еще ниже. Но если у вас есть нестандартные требования к совместимости, сначала проверьте, не ломаете ли вы контент в старых клиентах почты, админке или на очень старых устройствах.
Диагностика: как понять, что emoji действительно грузятся
Проверка начинается не с кода, а с факта. Откройте исходный код страницы и найдите подключение wp-emoji-release.min.js или inline-скрипт, который WordPress вставляет для проверки поддержки emoji. Второй способ — DevTools в браузере: на вкладке Network отфильтруйте запросы по слову emoji.
Если вы используете кэш-плагин или CDN, убедитесь, что смотрите не только главную страницу из кэша. Иногда оптимизация уже частично скрывает проблему, и кажется, что все отключено, хотя на чистом HTML запрос еще есть.
Что проверить перед изменениями
- есть ли в исходнике
wp-emoji-release.min.js; - не добавляет ли тему собственную обработку emoji поверх ядра;
- не используется ли старый плагин, который дублирует отключение через свои настройки;
- не подключен ли минификатор, который объединяет скрипты и скрывает источник запроса.
Пошаговое решение через functions.php или mu-plugin
Самый надежный способ — снять стандартные действия WordPress на init. Лучше делать это в дочерней теме или в mu-plugin, если настройка должна переживать смену темы.
<?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' );
} );Этот код убирает emoji-скрипт и стили и на фронтенде, и в админке. Если вам нужно оставить поведение в панели управления, удалите только фронтенд-варианты. Но на практике чаще отключают все, чтобы не держать лишний код и в админке тоже.
Если вы предпочитаете не трогать тему, создайте mu-plugin в wp-content/mu-plugins/. Это удобно для технических правок, которые не должны зависеть от активной темы.
<?php
/**
* Plugin Name: Disable Emoji Assets
*/
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' );
} );Альтернативы: плагин, код или оптимизатор
Если у вас уже стоит плагин для технической чистки сайта, иногда проще использовать его, чем плодить еще один сниппет. Но у каждого варианта есть компромисс.
| Подход | Плюсы | Минусы |
|---|---|---|
Код в functions.php или mu-plugin | Прозрачно, без лишних зависимостей, легко проверить | Нужно следить за обновлениями и местом размещения |
| Плагин оптимизации | Удобно, если уже используется для других правок | Легко потерять контроль, если настроек много |
| Ничего не делать | Нет риска сломать совместимость | Лишние запросы остаются на фронтенде |
Если у вас уже используется Clearfy Pro для технической чистки WordPress, отключение emoji можно держать в одном месте вместе с другими правками по удалению дублей и лишних подключений: Clearfy Pro. Но если задача точечная, кодовый вариант обычно проще и предсказуемее.
Проверка результата после внедрения
После добавления кода очистите весь кэш: плагин кэширования, серверный кэш, CDN, если он есть. Затем откройте страницу в режиме инкогнито и проверьте исходный код. В идеале не должно быть:
wp-emoji-release.min.js;- inline-скрипта с проверкой поддержки emoji;
- подключенных emoji-стилей в
<head>.
Дополнительно проверьте Network: при загрузке страницы не должно быть отдельного запроса к emoji-скрипту. Если запрос остался, значит код не выполнился, был закэширован старый HTML или его переопределяет другой плагин.
Для быстрой валидации можно временно вывести список подключенных скриптов через отладочный хук, но на боевом сайте это делать не стоит. Лучше использовать стандартные инструменты браузера и сравнить исходник до и после.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить сниппет в файл, который не загружается на всех страницах, эффект будет частичным. Для постоянной технической правки безопаснее mu-plugin или дочерняя тема.
Очистили только один уровень кэша
После изменения кода старый HTML может продолжать отдаваться из кэша. Очистите кэш плагина, серверный кэш и CDN, иначе вы будете смотреть на старую версию страницы и решите, что правка не работает.
Отключили emoji через несколько плагинов сразу
Когда один и тот же эффект достигается через код, оптимизатор и еще один плагин, потом сложно понять, что именно сломало поведение. Оставьте один источник правды. Если используете технический плагин, проверьте, не дублирует ли он уже существующий сниппет.
Проверяли только главную страницу
На части сайтов шаблон главной отличается от внутренних страниц. Сравните исходник хотя бы на одной записи, одной странице и архиве, чтобы убедиться, что отключение работает везде одинаково.
Безопасность и поддерживаемость
Само отключение emoji-ассетов безопасно, если вы понимаете, зачем это делаете. Риск здесь не в коде как таковом, а в хаотичном наборе правок. Не складывайте в functions.php десятки несвязанных сниппетов без комментариев: через полгода будет сложно понять, что и почему отключено.
Для поддержки лучше:
- хранить такие правки в одном
mu-pluginили отдельном техническом плагине; - комментировать, зачем отключение сделано;
- после обновления темы и ядра повторно проверять исходник страницы;
- не отключать то, что вы не проверили на реальном контенте.
Если задача шире, чем просто emoji, и вы регулярно чистите WordPress от дублей, лишних мета-тегов и технического мусора, удобнее собрать это в одном инструменте, а не распылять по нескольким файлам. Но для точечной правки достаточно и короткого сниппета, который легко удалить или вернуть назад.