Встроенная поддержка emoji в WordPress редко нужна на корпоративном сайте, блоге или проекте с контролем над фронтендом. При этом она добавляет лишние подключения и вставки в <head>, которые можно убрать без риска для контента, если делать это аккуратно. Ниже — рабочий сценарий: как понять, что именно отключать, чем отличается код от плагина и как проверить, что сайт не потерял нужную функциональность.
Что именно добавляет WordPress и почему это мешает
По умолчанию WordPress подключает скрипт wp-emoji-release.min.js и несколько фильтров, которые подменяют emoji в старых браузерах. Для большинства современных проектов это уже не критично. Проблема не в самом emoji, а в том, что код живёт в шаблоне всегда, даже если на сайте нет ни одного места, где эта совместимость реально нужна.
На практике это заметно в трёх сценариях:
- нужно сократить количество запросов и убрать лишние элементы из
head; - есть строгая политика по чистке фронтенда и минимизации стороннего JS;
- сайт проходит аудит производительности, и даже мелкие встроенные вещи хочется контролировать кодом.
Диагностика: как понять, что emoji-код действительно загружается
Перед изменениями проверьте исходный код страницы и список подключений. Это важно, чтобы не отключать вслепую и потом искать причину в другом месте.
Что искать в исходнике
Откройте главную страницу и посмотрите HTML в браузере. Обычно в <head> можно увидеть инлайн-скрипт, который создаёт объект wpemojiSettings, а также подключение файла wp-emoji-release.min.js. Если сайт использует кэш или оптимизацию, часть кода может быть объединена, но сам след обычно остаётся.
Что проверить в админке и теме
Иногда emoji отключают не только кодом, но и плагином оптимизации. Если у вас уже стоит инструмент для чистки фронтенда, например Clearfy Pro, проверьте, не дублируется ли настройка в двух местах. Двойное отключение обычно не ломает сайт, но усложняет диагностику: потом непонятно, что именно сработало.
Как отключить 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' );
} );Этот вариант убирает не только фронтенд-скрипт, но и связанные фильтры. Для обычного сайта этого достаточно. Если у вас есть редакторские письма, RSS или интеграции, которые завязаны на emoji-подстановку, сначала проверьте, действительно ли они используются.
Если нужен только фронтенд
Иногда достаточно убрать только загрузку на сайте, но оставить админку. Тогда можно ограничиться снятием действия из wp_head и стилей на фронтенде. Это полезно, если редакторы работают в старом окружении и вы не хотите трогать админскую часть без необходимости.
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Но такой вариант имеет смысл только если вы понимаете, зачем сохраняете часть логики. В большинстве случаев проще убрать всё сразу и не держать полумеры.
Отключение через плагин: когда это удобнее
Если на сайте уже есть плагин для технической оптимизации, отключение emoji можно сделать там же, чтобы не плодить код в теме. Это удобно для проектов, где доступ к functions.php ограничен или изменения вносят не разработчики, а контент-менеджеры.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в дочерней теме | Прозрачно, без лишних зависимостей | Нужно следить за деплоем |
| Плагин оптимизации | Удобно для админки, меньше ручной работы | Настройка может затеряться при смене плагина |
| Ничего не делать | Нулевой риск сломать что-то вручную | Лишний код остаётся в шаблоне |
Если вы используете Clearfy Pro, логично держать такие настройки в одном месте вместе с другими техническими правками. Это не обязательное условие, а просто способ не распылять оптимизацию по теме и нескольким плагинам одновременно.
Пошаговая схема внедрения без сюрпризов
- Сделайте резервную копию файлов темы или подготовьте staging-копию сайта.
- Проверьте, нет ли уже отключения emoji в плагине оптимизации.
- Добавьте код в дочернюю тему или свой мини-плагин.
- Очистите кэш страницы, серверный кэш и CDN, если они используются.
- Откройте страницу сайта в режиме просмотра исходного кода и убедитесь, что emoji-скрипт исчез.
Если у вас включена агрессивная оптимизация JS, проверяйте не только главную страницу, но и записи, страницы, архивы и шаблоны с комментариями. Иногда кэш отдаёт старую версию HTML, и кажется, что код не сработал.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по конкретным признакам. Смотрите на исходный HTML и на список сетевых запросов в DevTools.
Минимальный чек-лист
- в исходнике страницы нет
wpemojiSettings; - нет подключения
wp-emoji-release.min.js; - в
<head>не остаются связанные инлайн-скрипты emoji; - админка WordPress открывается без ошибок JavaScript;
- комментарии и RSS, если они используются, работают как раньше.
Для быстрой проверки можно открыть консоль браузера и поискать по исходнику страницы строку emoji. Если после очистки кэша она всё ещё есть, значит отключение не применилось или его перебивает другой плагин.
Частые ошибки и как их исправить
Код добавили в родительскую тему
Если правка внесена в родительскую тему, она исчезнет после обновления. Для технических изменений используйте дочернюю тему или отдельный мини-плагин. Это особенно важно для проекта, где тема обновляется регулярно.
Отключили только часть хуков
Иногда убирают только print_emoji_detection_script, но оставляют стили или фильтры. В результате код в head становится меньше, но не исчезает полностью. Если цель — именно чистка, отключайте связанный набор целиком.
Не очистили кэш
Это самая частая причина ложного вывода, что решение не работает. После изменения кода обязательно сбросьте кэш страницы, объектный кэш, если он есть, и CDN. Иначе вы будете смотреть на старую версию HTML.
Отключили через два разных инструмента
Если emoji выключен и кодом, и плагином, а потом один из способов убрали, можно получить путаницу в диагностике. Лучше выбрать один источник правды: либо код, либо настройку в плагине.
Когда лучше не трогать emoji
Есть редкие случаи, когда отключение не стоит делать без проверки. Например, если у вас старый корпоративный портал с очень старым браузерным парком, или если проект живёт в закрытой среде с нестандартными требованиями к совместимости. В таких сценариях сначала проверьте, есть ли вообще аудитория, которой нужен fallback для emoji.
Для большинства современных сайтов отключение безопасно. Но правило простое: если вы не уверены в составе аудитории и уже видите странности в старых браузерах, сначала тестируйте на staging, а не на боевом домене.
Практические советы по безопасности и производительности
Не вносите такие правки напрямую через редактор файлов в админке. Это неудобно для контроля версий и опасно при ошибке в коде. Лучше использовать Git, staging или хотя бы FTP/SFTP с нормальным бэкапом.
Если на сайте много технических оптимизаций, держите их в одном мини-плагине или в дочерней теме с понятной структурой. Так проще понять, что именно отключено, и не потерять правку при обновлении.
И ещё один практический момент: отключение emoji — это не замена полноценной оптимизации. Если цель — ускорение сайта, смотрите шире: кэш, изображения, критический CSS, лишние скрипты в теме и сторонние виджеты. Emoji-код — лишь один из мелких источников шума, который легко убрать без побочных эффектов.