В WordPress до сих пор можно встретить лишние подключения для emoji: отдельные скрипты и стили, которые не нужны большинству сайтов, но всё равно грузятся в <head> и в админке. На небольшом проекте это не критично, но если вы уже чистите сайт от дублей и лишних запросов, этот хвост имеет смысл убрать аккуратно — без поломки редактора, комментариев и сторонних плагинов.
Задача здесь не в том, чтобы «выжать максимум скорости любой ценой», а в том, чтобы отключить именно ненужное поведение и проверить, что после правки не появились ошибки в консоли и не сломалась вставка emoji там, где она реально нужна.
Когда это вообще имеет смысл
Отключать emoji-скрипты стоит, если вы видите в исходнике страницы подключение wp-emoji-release.min.js и хотите убрать один из лишних запросов. Обычно это разумно на сайтах, где:
- нет задачи поддерживать старые браузеры с проблемным отображением emoji;
- вы уже оптимизируете фронтенд и считаете каждый лишний запрос;
- на сайте много страниц, и даже мелкие оптимизации дают заметный эффект в сумме;
- вы следите за чистотой HTML и не хотите лишних inline-обработчиков в
head.
Если сайт живёт на тяжёлой теме или с большим количеством плагинов, отключение emoji не решит проблему производительности само по себе. Но как часть общей чистки — это нормальная и безопасная правка.
Диагностика: что именно грузится и откуда
Сначала проверьте, есть ли подключение emoji в исходном коде. Откройте страницу сайта, посмотрите HTML и найдите упоминания wp-emoji-release.min.js или inline-скрипта, который создаёт тестовые элементы для emoji. Если используете DevTools, удобнее смотреть вкладку Network и фильтровать по emoji.
Ещё один практический способ — временно открыть исходник главной страницы и поискать emoji. Если подключение есть, значит WordPress или плагин не убрал его на уровне хуков.
Что важно не перепутать
Иногда за emoji принимают совсем другие вещи: иконки из темы, SVG-спрайты, скрипты для реакций в комментариях или сторонние виджеты. Их отключать этим способом нельзя — это уже другая задача. Ниже речь только о стандартном emoji-поведение WordPress.
Пошаговое решение через functions.php или мини-плагин
Самый надёжный вариант — добавить код в дочернюю тему или в небольшой 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' );
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_svg_url и вернуть false. Это не всегда заменяет все отключения, но помогает убрать часть логики, связанной с emoji:
<?php
add_filter( 'emoji_svg_url', '__return_false' );На практике я бы оставлял первый вариант как основной. Он понятнее, предсказуемее и проще проверяется.
Что выбрать: код, плагин или набор оптимизаций
Если у вас уже стоит плагин для технической чистки, возможно, проще включить опцию отключения emoji там. Но если нужна точечная правка без лишнего интерфейса, код обычно лучше.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме / mu-plugin | Точно понятно, что отключено; нет лишних зависимостей | Нужно аккуратно обновлять и хранить правку |
| Плагин оптимизации | Удобно для редактора и контент-менеджера; настройка через UI | Часть функций может быть скрыта за общими переключателями |
| Ничего не делать | Нулевая вероятность сломать что-то руками | Лишние запросы и мусор в head остаются |
Если вы уже используете инструмент для чистки дублей и технических хвостов, например Clearfy Pro, проверьте, нет ли там готового переключателя для emoji. Но если задача узкая, код всё равно остаётся самым прозрачным вариантом.
Проверка результата после внедрения
После сохранения правки не ограничивайтесь обновлением страницы в браузере. Проверка должна быть в три шага.
- Откройте исходный код страницы и убедитесь, что
wp-emoji-release.min.jsбольше не выводится. - Проверьте Network в DevTools и обновите страницу с отключённым кэшем, чтобы увидеть реальные запросы.
- Откройте админку, редактор записей и форму комментариев, если они используются, и убедитесь, что нет JS-ошибок.
Если используете кэш-плагин или серверный кэш, после правки очистите кэш. Иначе вы можете смотреть на старую версию HTML и решить, что код не сработал.
Что считать нормальным результатом
Нормально, если:
- в исходнике нет подключения emoji-скрипта;
- в консоли браузера нет ошибок, связанных с emoji;
- редактор Gutenberg открывается без проблем;
- комментарии и письма продолжают работать как раньше.
Если на сайте есть старые письма или RSS-ленты, проверьте и их. Иногда отключение emoji влияет не на сам фронтенд, а на статическую замену emoji в feed и email-уведомлениях.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить правку в файл темы, который не загружается на всех страницах, часть запросов останется. Для такой настройки лучше использовать functions.php дочерней темы или mu-plugin в wp-content/mu-plugins.
Отключили не только emoji, но и нужные стили
Иногда копируют чужой сниппет без понимания, что он делает. В результате убирают не только emoji, но и связанные стили, которые могли использоваться плагином или темой. Если после правки сломалась верстка в админке, откатите изменения и проверьте, не удалили ли вы лишние хуки.
Проверяли только главную страницу
На главной всё может быть нормально, а на странице записи или в админке — нет. Проверяйте несколько шаблонов: запись, страница, архив, редактор, комментарии. Это особенно важно, если тема использует собственные обёртки для wp_head и wp_footer.
Смотрели без очистки кэша
Классическая ошибка: правка уже работает, но в браузере и на сервере осталась старая версия. После любых изменений в технических хуках очищайте кэш плагина, CDN и, если нужно, OPcache.
Если нужна более широкая чистка, а не только emoji
Отключение emoji — это точечная оптимизация. Если вы параллельно хотите убрать лишние архивы, дубли, сервисные страницы и технический мусор, лучше собирать такие изменения в одну понятную политику, а не размазывать их по десятку сниппетов.
В этом случае удобно держать список того, что уже отключено:
- emoji-скрипты и стили;
- лишние эмодзи-замены в RSS и письмах, если они не нужны;
- ненужные встроенные элементы, которые дублируют функциональность плагинов;
- старые технические хвосты после миграций и обновлений темы.
Так проще поддерживать сайт и быстрее находить причину, если после обновления ядра или темы что-то изменилось.
Безопасность и производительность: что учесть
Любая правка через functions.php должна быть обратимой. Перед внедрением сделайте резервную копию файла или храните сниппет в отдельном мини-плагине. Это особенно важно, если сайт обновляется автоматически и вы не хотите ловить белый экран из-за случайной ошибки в PHP.
С точки зрения производительности отключение emoji не даст чудес, но уберёт один лишний запрос и немного сократит объём HTML. На сайтах с большим количеством страниц это полезно именно как часть общей зачистки фронтенда.
Если у вас есть staging, сначала проверьте правку там. Это самый дешёвый способ убедиться, что редактор, комментарии и письма не пострадали.
Итоговая логика простая: отключайте только то, что действительно не используете, проверяйте результат в исходнике и в консоли, а не по ощущениям, и не смешивайте эту настройку с другими оптимизациями в одном непонятном сниппете.