WordPress до сих пор подгружает небольшой набор скриптов и стилей для emoji. На современном сайте это часто лишняя нагрузка: дополнительный запрос, лишний код в HTML и ещё один источник шума в Lighthouse. Если сайт не рассчитан на старые браузеры и вы не хотите тащить этот функционал на фронтенд, emoji-скрипты можно отключить без риска для контента.
Ниже разберём, как понять, что именно грузится, чем отличается отключение через код от плагина, и как проверить, что после правки ничего не сломалось.
Когда emoji-скрипты действительно мешают
Проблема обычно заметна не по одному признаку, а по набору мелочей: в исходном коде страницы есть wp-emoji-release.min.js, в Network виден запрос к этому файлу, а в отчётах по производительности всплывает лишний JavaScript. На небольшом сайте это не катастрофа, но если вы уже вычищаете всё лишнее, такие детали имеют смысл.
Отключать emoji-скрипты имеет смысл, если:
- сайт рассчитан на актуальные версии браузеров;
- вы не используете старые корпоративные окружения с древним WebView;
- важно сократить число запросов и лишний JS на фронтенде;
- вы уже чистите head и убираете неиспользуемые ресурсы.
Если аудитория сидит на очень старых устройствах, полностью вырезать поддержку emoji на фронтенде не всегда разумно. Тогда лучше ограничиться аккуратной проверкой, а не отключать всё без теста.
Диагностика: как понять, что emoji-скрипты загружаются
Самый простой способ — открыть исходный код страницы и найти wp-emoji-release.min.js. Ещё удобнее посмотреть вкладку Network в DevTools и отфильтровать запросы по слову emoji. Если файл грузится, значит WordPress вставляет стандартный набор emoji-поддержки.
Что именно искать в коде страницы
Обычно встречаются такие признаки:
- скрипт
/wp-includes/js/wp-emoji-release.min.js; - inline-скрипт с проверкой поддержки canvas и emoji;
- дополнительные вызовы в
wp_headиwp_print_styles.
Если у вас установлен плагин оптимизации, он может уже убирать часть этого кода. Поэтому сначала проверьте реальное состояние страницы, а не полагайтесь на настройки в админке.
Пошаговое решение через functions.php или мини-плагин
Самый надёжный способ — добавить небольшой код в functions.php дочерней темы или оформить это как мини-плагин. Для рабочих сайтов я предпочитаю второй вариант: он не зависит от темы и не потеряется при обновлении.
Вот рабочий пример, который отключает emoji-скрипты и связанные стили на фронтенде:
<?php
/**
* Disable WordPress emoji scripts/styles on the front end.
*/
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, но на практике это редко нужно.
Если нужен более точный контроль
Иногда лучше не удалять всё на уровне хуков, а отключить только фронтенд. Тогда код будет таким:
<?php
add_action( 'init', function () {
if ( ! is_admin() ) {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
}
} );Такой вариант полезен, если редакторы работают в админке с контентом, где emoji иногда вставляют вручную, а на публичной части сайта вы хотите убрать лишнее.
Плагин или код: что выбрать
Если у вас уже стоит плагин для технической оптимизации, возможно, там есть галочка для отключения emoji. Но если задача точечная, код обычно чище: вы точно знаете, что именно выключили, и не тащите лишний функционал ради одной настройки.
| Подход | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| Код в теме/мини-плагине | Прозрачно, без лишних зависимостей | Нужно не забыть про обновления темы | Если нужен точечный контроль |
| Плагин оптимизации | Удобно для нескольких правок сразу | Может быть избыточным ради одной функции | Если уже используете такой плагин |
| Ничего не делать | Ноль риска от правки | Лишний JS и стили остаются | Если приоритет — совместимость, а не чистота |
Если вы уже используете Clearfy Pro, там есть инструменты для отключения части системных функций WordPress. Это не обязательное решение, но в проектах, где чистят head и убирают дубли, такой подход бывает удобен. Смотрите только на реальные настройки, а не на маркетинговое описание: включайте ровно то, что вам нужно.
Проверка результата после внедрения
После добавления кода не ограничивайтесь обновлением страницы в браузере. Проверьте три вещи: исходный код, сетевые запросы и поведение редактора.
- Откройте страницу в режиме просмотра исходника и убедитесь, что
wp-emoji-release.min.jsбольше не выводится. - В DevTools на вкладке Network обновите страницу и проверьте, что запросов к emoji-скрипту нет.
- Зайдите в админку и откройте редактор записи: он должен работать как раньше.
Если вы используете кэш-плагин или серверный кэш, очистите кэш после правки. Иначе вы можете смотреть на старую версию HTML и решить, что код не сработал.
Мини-чек-лист проверки
- скрипт
wp-emoji-release.min.jsотсутствует в HTML; - в Network нет запроса к emoji-файлу;
- редактор записей открывается без ошибок;
- на сайте не появилось JS-ошибок в консоли;
- после очистки кэша изменения видны на публичной странице.
Частые ошибки и как их исправить
Ошибка 1: код вставили в родительскую тему. После обновления темы правка исчезнет. Для постоянного решения используйте дочернюю тему или мини-плагин.
Ошибка 2: проверили страницу без очистки кэша. Кэш-плагин, CDN или серверный кэш могут отдавать старый HTML. Сначала очищайте кэш, потом тестируйте.
Ошибка 3: отключили не те хуки. Иногда пытаются удалить только print_emoji_detection_script, но забывают про стили. В итоге часть обвязки остаётся, и лишний код всё ещё присутствует.
Ошибка 4: сломали админку слишком агрессивной оптимизацией. Если вместе с emoji вырезали ещё и другие системные скрипты, проблема может быть не в этом коде, а в наборе отключений. Откатывайте изменения по одному.
Ошибка 5: ориентируются только на PageSpeed. Если скрипт уже не грузится, а отчёт всё равно ругается на старый ресурс, проверьте актуальность теста и кэш отчёта. Не стоит чинить то, чего уже нет.
Что ещё можно убрать рядом с emoji, если вы чистите фронтенд
Если вы уже занимаетесь технической оптимизацией, emoji-скрипты — только один из мелких элементов. Дальше обычно смотрят на лишние стили плагинов, дубли в head, ненужные эмодзи-обвязки, oEmbed и автоподгрузку некоторых системных ресурсов. Но здесь важно не идти по пути «выключить всё подряд».
Хорошая практика — менять один параметр за раз и сразу проверять результат. Тогда вы быстро поймёте, что реально даёт эффект, а что только создаёт риск поломки.
Практический совет по безопасности и поддержке
Если вы вносите такие правки на клиентском проекте, храните их отдельно от темы: в мини-плагине или в MU-plugin. Это упрощает перенос между окружениями и снижает риск потерять настройку при смене темы. Для команды это ещё и понятнее: одна маленькая техническая правка не размазана по шаблонам.
Когда задача шире, чем отключение одного скрипта, имеет смысл собрать набор оптимизаций в одном месте и документировать, что именно выключено. Иначе через полгода никто не вспомнит, почему в проекте пропали системные ресурсы WordPress.