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