Встроенная поддержка emoji в WordPress часто не нужна на сайте, где уже используется современный браузерный стек и нет требований к старым клиентам. На практике она добавляет лишние подключения и скрипты, а иногда мешает чистке фронтенда, если вы выжимаете из темы и плагинов максимум по скорости.
Задача здесь не в том, чтобы «выключить что-нибудь лишнее», а в том, чтобы убрать именно механизм emoji WordPress и не задеть редактор, админку и сторонние интеграции. Ниже — рабочие способы, как это сделать, где смотреть результат и какие ошибки обычно ломают ожидания.
Когда отключение emoji действительно имеет смысл
Если открыть исходный код страницы, WordPress может подгружать wp-emoji-release.min.js и добавлять фильтры, которые подменяют символы emoji на картинку-спрайт для старых окружений. Для большинства проектов это уже не нужно. Особенно если:
- сайт рассчитан на современные браузеры;
- вы следите за количеством запросов на главной и в шаблонах;
- используете строгую оптимизацию фронтенда и хотите убрать лишние inline-скрипты;
- нужно привести код к более предсказуемому виду перед аудитом производительности.
Но отключать emoji стоит только после проверки, что у вас нет специфической аудитории со старыми браузерами или нестандартными клиентами, где эта поддержка еще важна.
Диагностика: что именно загружает WordPress
Сначала проверьте, есть ли emoji-скрипт на странице. Проще всего посмотреть исходный HTML или вкладку Network в DevTools. Ищите такие признаки:
- подключение
wp-emoji-release.min.js; - inline-скрипт с настройками emoji в
<head>; - дополнительные фильтры в HTML, которые WordPress добавляет для старых клиентов.
Если на сайте стоит плагин оптимизации, он может уже частично убирать эти элементы. Поэтому сначала смотрите не на «ощущение», а на фактический код страницы.
Проверка через исходник
<script src="https://example.com/wp-includes/js/wp-emoji-release.min.js?ver=6.5.3" defer></script>Если такой строки нет, возможно, emoji уже отключены темой, плагином или оптимизатором. Тогда повторно добавлять код не нужно.
Пошаговое решение: отключаем emoji штатным способом
Самый надежный вариант — снять стандартные действия WordPress через remove_action() и фильтр wp_resource_hints. Добавлять код лучше в дочернюю тему или в небольшой mu-plugin, если вы не хотите зависеть от темы.
Вариант через functions.php
<?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' );
remove_filter( 'the_content', 'wp_staticize_emoji' );
remove_filter( 'comment_text', 'wp_staticize_emoji' );
} );
add_filter( 'emoji_svg_url', '__return_false' );Этот код убирает фронтенд-скрипт, стили и часть фильтров, связанных с преобразованием emoji. На большинстве сайтов этого достаточно.
Если нужно убрать и dns-prefetch для emoji
Иногда в <head> остается ресурсный hint на домен emoji. Его тоже можно убрать:
<?php
add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
if ( 'dns-prefetch' === $relation_type ) {
$urls = array_diff( $urls, array( 'https://s.w.org/images/core/emoji/' ) );
}
return $urls;
}, 10, 2 );На практике этот шаг нужен не всегда. Если вы не видите соответствующий hint в исходнике, не усложняйте код.
Сравнение подходов: код, плагин, оптимизатор
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен точечный контроль | Прозрачно, без лишней логики | Нужно не забыть при миграции темы |
| Плагин оптимизации | Уже используется для чистки фронтенда | Удобно управлять из админки | Может отключать больше, чем нужно |
| Ничего не делать | Emoji реально нужны или сайт не оптимизируется | Ноль риска для совместимости | Лишние запросы и код остаются |
Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, не отключена ли emoji-функция там. Тогда дублировать код в теме не нужно: двойное отключение обычно не ломает сайт, но усложняет поддержку.
Как проверить, что решение сработало
После внедрения откройте главную страницу и любую запись в режиме инкогнито. Дальше проверьте три вещи:
- в исходнике нет
wp-emoji-release.min.js; - в
<head>нет лишних emoji-related inline-скриптов; - в админке редактор и комментарии работают как раньше.
Если нужен более строгий контроль, сравните количество запросов до и после через DevTools или веб-метрики. Но не ждите большой разницы по времени загрузки на каждом проекте: иногда эффект минимален, зато кодовая база становится чище.
Частые ошибки и как их исправить
Код вставили, но emoji-скрипт остался
Чаще всего причина в том, что код добавили слишком поздно или не туда. Проверьте, что он выполняется на фронтенде, а не только в админке. Для темы лучше использовать functions.php дочерней темы или mu-plugin.
Отключили emoji, а в письмах пропали символы
Если вы убрали фильтр wp_staticize_emoji_for_email, проверьте шаблоны почтовых уведомлений и интеграции с SMTP-плагинами. Обычно это не критично, но в письмах с emoji лучше сделать тестовую отправку.
Сломалась совместимость со старым браузером
Это редкий, но реальный сценарий для корпоративных или закрытых проектов. Если аудитория использует старые устройства, не отключайте поддержку без проверки. В таком случае лучше оставить штатный механизм или ограничить отключение только фронтендом, не трогая админку.
Появился конфликт с плагином оптимизации
Некоторые плагины уже снимают emoji-скрипт автоматически. Если вы добавили свой код поверх, конфликт обычно не критичен, но поддержка становится сложнее. Оставьте один источник правды: либо код в теме, либо настройка в оптимизаторе.
Практические советы по безопасности и производительности
Не разбрасывайте такой код по нескольким файлам. Для технических отключений лучше держать отдельный mu-plugin или единый файл в дочерней теме, чтобы быстро понять, что именно влияет на фронтенд. Это особенно полезно, если сайт передается между разработчиками.
- проверяйте изменения на staging-копии;
- не отключайте то, что уже убирает ваш оптимизатор;
- после обновления темы повторно проверьте, не потерялся ли код;
- если используете кеш, очищайте его после правок;
- не трогайте админку без необходимости, если редакторы активно работают в блоковом редакторе.
Если ваша цель — именно техническая чистка WordPress, а не точечный хак, удобнее держать такие настройки в одном месте. Тогда проще контролировать, что отключено, и не ловить регрессии после обновлений.