В WordPress до сих пор по умолчанию подключается небольшой набор скриптов для поддержки emoji в старых браузерах. На современных сайтах это часто лишняя нагрузка: дополнительные запросы, лишний код в <head> и еще один источник мусора в сборке фронтенда. Сам по себе эффект не драматичный, но на проектах, где уже вычищают дубли, отключают лишние эмбедды и сокращают количество запросов, этот кусок тоже имеет смысл убрать.
Важно понимать границу: речь не про «сломать emoji», а про отключение вспомогательных скриптов WordPress, которые нужны в основном для очень старых окружений. Если у вас нет требований поддерживать древние браузеры, это безопасная оптимизация.
Когда это действительно имеет смысл
Отключать emoji-скрипты стоит не «потому что так делают все», а когда есть конкретная задача:
- нужно уменьшить количество запросов на фронтенде;
- вы уже чистите
<head>от лишних тегов и автоподключений; - на проекте есть строгий контроль за производительностью и Core Web Vitals;
- вы хотите убрать один из стандартных WordPress-скриптов, который не нужен на сайте с современной аудиторией.
Если сайт обслуживает очень старые устройства или у вас есть корпоративные требования к совместимости, сначала проверьте, действительно ли отключение допустимо. Для большинства публичных сайтов это не проблема.
Диагностика: что именно подключает WordPress
Проверка простая. Откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или фильтры, связанные с emoji. Обычно WordPress добавляет:
- инлайн-скрипт в
<head>; - подключение
wp-emoji-release.min.js; - в некоторых случаях дополнительные стили для emoji.
Если у вас установлен плагин оптимизации, он может уже убирать этот код. Тогда повторное вмешательство в тему или functions.php даст дублирующий эффект и только усложнит отладку.
Что проверить перед изменениями
- нет ли уже активной оптимизации в плагине кеша или минификации;
- не отключены ли emoji ранее через
remove_actionили фильтры; - не собирается ли фронтенд в отдельный бандл, где этот код уже вырезан;
- не использует ли тема собственные обертки вокруг стандартных WordPress-хуков.
Как отключить emoji-скрипты кодом
Самый предсказуемый способ — добавить код в 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' );
} );Этот вариант убирает и фронтенд, и админку. Если вам нужно оставить emoji в админке, а чистить только публичную часть сайта, не трогайте admin_print_scripts и admin_print_styles.
Более точечный вариант только для фронтенда
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Такой подход удобен, если редакторы работают в админке и вы не хотите менять их интерфейс без необходимости.
Если нужен плагин вместо кода
Когда на проекте много людей и правки в коде проходят через ревью, иногда проще использовать плагин оптимизации, который умеет отключать emoji вместе с другими мелкими улучшениями. Но здесь важно не дублировать настройки: если плагин уже чистит wp-emoji-release.min.js, не добавляйте тот же код вручную.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или мини-плагине | Прозрачно, контролируемо, без лишних зависимостей | Нужно следить за обновлениями и переносом в дочернюю тему |
| Плагин оптимизации | Удобно, если уже используете его для других задач | Легко получить дублирующие настройки |
| Ничего не делать | Ноль рисков для совместимости | Лишние запросы и код остаются |
Если вам нужен не только этот пункт, а более широкая чистка WordPress от дублей и лишних элементов, имеет смысл смотреть в сторону комплексных решений вроде Clearfy Pro: Clearfy Pro. Но и в этом случае проверяйте, что именно отключено, а не полагайтесь на общий чекбокс.
Пошаговое решение без сюрпризов
- Сделайте резервную копию или подготовьте быстрый rollback через Git.
- Проверьте, не отключены ли emoji уже в плагине кеша или оптимизации.
- Добавьте код в дочернюю тему или мини-плагин.
- Очистите кеш страницы, объектный кеш и CDN, если он есть.
- Откройте главную страницу и любую внутреннюю страницу в режиме инкогнито.
- Проверьте исходный код и список сетевых запросов.
Как проверить, что решение сработало
Проверка должна быть не «на глаз», а по фактам. Смотрите на исходный код страницы и вкладку Network в DevTools.
- в исходнике больше нет
wp-emoji-release.min.js; - в
<head>не выводится инлайн-скрипт emoji; - в списке запросов не появляется отдельный файл emoji;
- страница открывается без ошибок JavaScript, связанных с удаленными хуками.
Если используете командную строку, можно быстро проверить HTML через curl:
curl -s https://example.com/ | grep -i emojiПустой вывод не гарантирует идеальную чистоту, но помогает быстро понять, остался ли явный след подключения.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить remove_action в обычный шаблонный файл, он может не сработать вовремя. Для таких правок нужен functions.php дочерней темы, мини-плагин или MU-plugin. Иначе WordPress уже успеет повесить нужные действия до вашего кода.
Отключили не только фронтенд, но и админку
Это не критично, но иногда мешает редакторам, если они работают со старыми браузерами или специфическими интерфейсами. Если админка должна остаться без изменений, уберите только фронтенд-хуки.
Плагин кеша вернул старую версию страницы
После правки кодом старый HTML может продолжать отдаваться из кеша. В этом случае очистите не только плагин кеша, но и серверный кеш, CDN и браузерный кеш. Иначе вы решите, что код не сработал, хотя на самом деле вы смотрите устаревшую копию.
Тема или плагин снова добавили emoji
Иногда сторонний код повторно подключает стандартные скрипты WordPress. Тогда нужно искать не только в ядре, но и в теме, и в плагинах. Практический способ — временно отключить плагины и проверить, кто именно возвращает скрипт.
Что еще можно вычистить рядом с emoji
Если вы уже занимаетесь технической чисткой, обычно рядом идут и другие мелкие оптимизации: отключение лишних эмбеддов, удаление версии WordPress из HTML, чистка wp_head от неиспользуемых тегов. Но здесь важно не превращать оптимизацию в набор случайных отключений. Каждый пункт должен иметь понятную причину и проверяемый результат.
Для редакционного сайта это особенно полезно: меньше шума в коде, проще отладка, меньше шансов, что очередное обновление темы принесет лишний скрипт обратно. Главное — после каждого изменения смотреть не только на «стало ли меньше строк», а на то, не сломалась ли совместимость и не вернулись ли старые запросы через кеш.