В WordPress поддержка emoji включена по умолчанию и тянет за собой дополнительный JavaScript и CSS. На небольших сайтах это часто незаметно, но в техничных проектах лишние запросы лучше убирать осознанно: меньше ресурсов в <head>, меньше стороннего кода, проще контролировать фронтенд.
Речь не о «ускорении на глаз», а о конкретной задаче: отключить emoji там, где они не нужны, и не сломать редактор, комментарии или вставки из внешних источников. Ниже — рабочие способы, как это сделать в теме, через плагин и как проверить, что отключение реально сработало.
Что именно отключаем и где это видно
В WordPress emoji-логика состоит из нескольких частей: скрипт проверки поддержки в браузере, стили для отображения, а также фильтры, которые подменяют текстовые смайлы в контенте. В большинстве случаев на фронтенде достаточно убрать подключение скрипта и стилей. Если этого не сделать, в исходном коде страницы останутся запросы к wp-emoji-release.min.js и inline-инициализация.
Проверять нужно не только главную страницу. Часто тема или плагин подключают лишнее на отдельных шаблонах, в архиве, в комментариях или в админке. Поэтому сначала смотрим, где именно грузится код, а потом уже отключаем.
Быстрая диагностика в браузере
- Откройте страницу сайта и посмотрите исходный код.
- Найдите
wp-emoji-release.min.jsи связанные inline-скрипты. - Проверьте вкладку Network: есть ли запросы к emoji-скрипту.
- Сравните главную, запись и архив — иногда подключение отличается.
Если у вас включён кэш, после изменений обязательно очищайте не только страницу, но и серверный/плагинный кэш, иначе можно сделать неправильный вывод.
Как отключить emoji через код
Самый прозрачный вариант — убрать стандартные действия WordPress на init и wp_print_styles. Это не выдуманный трюк, а штатный способ отключить встроенные подключения, если они не нужны.
<?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' );
} );
Код можно добавить в functions.php дочерней темы или в свой небольшой mu-plugin. Для проекта, где код должен переживать смену темы, mu-plugin обычно надёжнее.
Если нужен только фронтенд
Иногда в админке emoji лучше оставить, а на публичной части убрать. Тогда можно ограничить отключение фронтендом:
<?php
add_action( 'init', function () {
if ( is_admin() ) {
return;
}
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );
Такой вариант полезен, если редакторы часто вставляют emoji в записи и вы не хотите менять поведение в админке без необходимости.
Как отключить emoji через плагин
Если не хочется трогать код темы, можно использовать плагин оптимизации, который умеет отключать встроенные функции WordPress. Например, в Clearfy Pro есть набор настроек для чистки лишнего кода и отключения отдельных встроенных возможностей. Это удобно, когда вы уже управляете техоптимизацией из одного места.
Плюс плагина в том, что изменения можно включать и выключать без правки файлов темы. Минус — появляется ещё одна точка конфигурации, которую нужно документировать для команды.
| Способ | Когда подходит | Компромисс |
|---|---|---|
| Код в теме или mu-plugin | Нужен контроль и минимальная зависимость | Надо следить за обновлениями и местом хранения кода |
| Плагин оптимизации | Уже используете централизованные настройки | Добавляется ещё один слой конфигурации |
| Ничего не делать | Emoji реально нужны в контенте и приоритет не в чистке | Остаются лишние подключения на фронтенде |
Пошаговое решение без лишних рисков
- Сделайте резервную копию файлов и базы или хотя бы снимите staging-копию.
- Определите, нужен ли emoji в админке. Если да, отключайте только фронтенд.
- Добавьте код в дочернюю тему или mu-plugin.
- Очистите кэш страницы, серверный кэш и кэш CDN, если он есть.
- Проверьте исходный код и Network после очистки кэша.
Если вы работаете с кастомной темой, не вставляйте код в основной файл темы без необходимости. При обновлении темы изменения потеряются. Для постоянных технических правок mu-plugin обычно практичнее.
Как проверить, что отключение сработало
Проверка должна быть не «страница открылась», а конкретной. Смотрите на три признака:
- в исходном коде больше нет
wp-emoji-release.min.js; - в
<head>не выводится emoji detection script; - в Network нет запроса к emoji-скрипту при загрузке страницы.
Дополнительно можно открыть страницу в режиме инкогнито, чтобы исключить влияние локального кэша браузера. Если используете PageSpeed Insights или Lighthouse, не ждите от этого шага драматического прироста — задача здесь в первую очередь в чистоте фронтенда, а не в магическом росте метрик.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить snippet в файл, который не загружается на фронтенде, ничего не изменится. Для темы это обычно functions.php активной дочерней темы, для независимого решения — mu-plugin.
Отключили не все хуки
Иногда убирают только wp_print_styles, но оставляют detection script в wp_head. В результате часть кода остаётся в HTML, и цель не достигается. Отключать нужно оба направления, если задача — убрать emoji полностью на фронтенде.
Не очистили кэш
Это самая частая причина ложного вывода. После правки кода старый HTML может продолжать отдаваться из кэша. Сначала очищайте кэш, потом проверяйте исходник.
Сломали админку без необходимости
Если у вас в редакторе или в комментариях есть зависимость от emoji-подсказок, не отключайте всё подряд. Ограничьте отключение фронтендом через is_admin() или используйте плагин с точечной настройкой.
Что ещё стоит проверить вместе с emoji
Если вы уже чистите фронтенд, имеет смысл посмотреть и другие встроенные вещи, которые не нужны на конкретном проекте: лишние эмодзи-скрипты, oEmbed, неиспользуемые стили темы, дублирующиеся библиотеки. Но отключать всё подряд без проверки не стоит: один и тот же код может быть полезен на контентном сайте и лишним на лендинге.
Для проектов, где техническая чистка идёт регулярно, удобно вести короткий чек-лист изменений. Тогда при обновлении ядра, темы или плагинов проще понять, что именно было отключено и почему.
- Проверить, нужен ли emoji в админке.
- Отключить только фронтенд или весь стек, если это оправдано.
- Очистить все уровни кэша.
- Сравнить исходный код до и после.
- Зафиксировать изменение в документации проекта.
Если вам важнее не ручная правка, а централизованная техчистка, можно рассмотреть плагин вроде Clearfy Pro как часть общей настройки сайта. Но даже в этом случае полезно понимать, какие именно хуки он отключает, чтобы не искать проблему вслепую после обновления.
