Emoji в WordPress — это не «тяжёлая» проблема сама по себе, но на проектах, где важна чистота фронтенда и контроль над лишними запросами, этот функционал часто отключают. Обычно речь не про драматический прирост скорости, а про аккуратную оптимизацию: убрать один скрипт, несколько фильтров и лишнюю обработку в <head>.
Если у вас уже настроены кэш, минификация и нормальная тема, отключение Emoji — это скорее гигиена кода, чем магическая оптимизация. Но в реальных проектах такие мелочи складываются: меньше лишних подключений, проще аудит, меньше шансов на конфликт с оптимизаторами.
Когда отключать Emoji действительно имеет смысл
Отключать Emoji стоит, если вы:
- делаете технически чистую сборку сайта и контролируете каждый внешний скрипт;
- используете строгую оптимизацию фронтенда и хотите убрать всё необязательное;
- видите, что оптимизатор или CSP-политика ругается на лишние подключения;
- поддерживаете корпоративный сайт, где Emoji в интерфейсе не нужны.
Если сайт живёт на контенте, комментариях и пользовательском общении, отключение Emoji обычно не ломает ничего критичного. Но перед изменением лучше проверить, не завязана ли тема или плагин на встроенный WordPress-скрипт.
Диагностика: что именно добавляет WordPress
По умолчанию WordPress может подключать скрипт wp-emoji-release.min.js и добавлять небольшие inline-обработчики в head. Это можно увидеть в исходном коде страницы или через DevTools.
Как проверить наличие Emoji-скрипта
Откройте главную страницу сайта, затем:
- посмотрите исходный код страницы;
- найдите
wp-emoji-release.min.js; - проверьте, есть ли дополнительные inline-скрипты, связанные с Emoji;
- сравните страницу до и после изменений.
Если вы используете кэш-плагин или CDN, проверяйте именно очищенную версию страницы, а не только админку.
Пошаговое решение: отключаем 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' );
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 и письмах. Если вам нужно оставить Emoji в админке, не удаляйте соответствующие действия для admin_print_scripts и admin_print_styles.
Если нужен только фронтенд
Иногда разумнее убрать Emoji только на публичной части сайта. Тогда код будет мягче:
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 в админке, а на сайте вы хотите оставить фронтенд максимально чистым.
Сравнение подходов: плагин, код, компромисс
| Подход | Что даёт | Минус |
|---|---|---|
| Код в теме или мини-плагине | Полный контроль, минимум зависимостей | Нужно не забыть про обновления и место размещения кода |
| Плагин для оптимизации | Быстро включить без правки файлов | Ещё одна зависимость, не всегда понятно, что именно отключено |
| Не отключать | Ничего не ломаете, поведение стандартное | Остаётся лишний фронтенд-код |
Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, не отключается ли Emoji там через встроенную опцию. Это удобнее, чем держать отдельный фрагмент кода, если вы и так централизуете оптимизацию.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой. Нужно убедиться, что WordPress действительно перестал выводить Emoji-скрипты.
- очистите кэш сайта и браузера;
- откройте страницу в режиме инкогнито;
- проверьте исходный код на наличие
wp-emoji-release.min.js; - посмотрите, исчезли ли связанные inline-скрипты из
head; - если используете PageSpeed или WebPageTest, сравните список запросов до и после.
Дополнительно можно проверить RSS-ленту и тестовое письмо, если у вас есть сценарии, где Emoji могли попадать в контент автоматически.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить фрагмент в файл активной темы, он может пропасть после обновления. Надёжнее использовать дочернюю тему или собственный плагин для технических правок.
Проверяют только админку
В админке скрипт может вести себя иначе, чем на фронтенде. Всегда смотрите публичную страницу и исходный код, а не только редактор записей.
Не очищают кэш
После отключения Emoji старый HTML может продолжать отдаваться из кэша. Если изменения не видны, сначала очистите серверный кэш, кэш-плагин и CDN.
Отключают слишком агрессивно
Если удалить больше действий, чем нужно, можно задеть вывод стилей или обработку контента в письмах. Начинайте с фронтенда, а потом расширяйте отключение только если это действительно нужно.
Практические советы по безопасности и производительности
Отключение Emoji не заменяет нормальную оптимизацию, но хорошо работает как часть общей чистки сайта. Если вы уже наводите порядок в техническом слое, проверьте и другие лишние элементы: неиспользуемые скрипты темы, дублирующиеся стили, старые плагины, которые добавляют фронтенд без необходимости.
Для проектов, где важна повторяемость настроек, удобнее держать такие изменения в одном месте: мини-плагин, mu-plugin или плагин для технической оптимизации. Тогда при смене темы вы не потеряете правки и не будете искать, почему снова появился лишний скрипт.
Если хотите идти дальше, после отключения Emoji имеет смысл посмотреть на другие «мелкие» источники шума: XML-RPC, лишние эмодзи-стили в теме, автозагрузку ненужных опций и дубли в <head>. Именно из таких деталей обычно и собирается аккуратный WordPress-проект.