WordPress до сих пор по умолчанию подгружает небольшой набор скриптов и стилей для поддержки emoji. На современных сайтах это часто лишняя нагрузка: дополнительные запросы в <head>, лишний JS в админке и фронтенде, а иногда — конфликт с оптимизацией, когда вы уже вручную собираете критический CSS и сокращаете количество подключений.
Если задача не в «косметике», а в технической чистке сайта, emoji — один из тех компонентов, которые можно отключить без заметного риска. Но делать это лучше осознанно: проверить, где именно они подключаются, и убедиться, что после правки не сломались редактор, комментарии и сторонние виджеты.
Когда отключение emoji действительно имеет смысл
Сценарий простой: сайт работает на русском языке, emoji в контенте используются редко или вообще не используются, а в отчётах по производительности вы видите лишние запросы к wp-emoji-release.min.js. Иногда это не критично само по себе, но на сайтах с агрессивной оптимизацией даже такие мелочи мешают держать фронтенд чистым.
Отключение особенно уместно, если:
- вы собираете сайт без лишних подключений в
<head>; - используете кеширование и минификацию, но хотите убрать ненужные ресурсы ещё на уровне WordPress;
- на сайте много страниц, и вы контролируете каждый внешний запрос;
- в админке и на фронтенде не нужны старые fallback-механизмы для emoji.
Диагностика: где именно WordPress подключает emoji
Перед изменениями проверьте, что именно загружается. Обычно в исходном коде страницы можно найти такие фрагменты: wp-emoji-release.min.js, inline-скрипт с настройками emoji и иногда подключение в админке. Если у вас включён кеш или CDN, проверяйте не только HTML, но и фактический ответ сервера после очистки кеша.
Быстрый способ диагностики:
- Откройте главную страницу и любую внутреннюю страницу в режиме просмотра исходника.
- Найдите
emojiилиwp-emoji-release. - Проверьте админку: иногда скрипт отключают на фронтенде, но забывают про редактор.
- Сравните страницу до и после очистки кеша, чтобы не спутать старый HTML с актуальным.
Что именно нужно убрать
В стандартной конфигурации WordPress emoji-логика подключается через набор действий и фильтров. На практике обычно отключают:
- скрипт emoji в
wp_headиadmin_print_scripts; - стили emoji;
- DNS-prefetch для домена
s.w.org, если он добавляется только ради emoji; - ненужный inline-код, который остаётся после частичной оптимизации.
Пошаговое решение через functions.php или мини-плагин
Самый надёжный вариант — вынести код в мини-плагин или в functions.php дочерней темы. Если тема обновляется часто, мини-плагин безопаснее: правка не потеряется.
Ниже рабочий вариант, который отключает emoji в фронтенде и админке. Код не трогает контент пользователя, а только убирает стандартные подключения WordPress:
<?php
/**
* Disable WordPress emoji scripts and styles.
*/
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-подсказки из TinyMCE в старом редакторе, обычно этого достаточно. В Gutenberg и на современных версиях WordPress отдельной настройки для emoji не требуется: стандартные подключения уже будут сняты этим кодом.
Если нужен более аккуратный вариант для фронтенда
Иногда emoji хотят оставить в админке, но убрать только на сайте. Тогда не трогайте админские хуки и снимайте только фронтенд-подключения:
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_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 в тексты, а вы не хотите менять их рабочее окружение в админке.
Сравнение подходов: плагин, код, оптимизатор
| Подход | Что даёт | Минус |
|---|---|---|
| Код в теме или мини-плагине | Полный контроль, минимум лишних зависимостей | Нужно не забыть про обновления и место подключения |
| Оптимизирующий плагин | Удобно, если уже используете плагин для чистки сайта | Часть настроек может быть спрятана, а логика — шире, чем нужно |
| Ничего не делать | Ноль риска для конфигурации | Остаются лишние подключения и шум в исходнике |
Если у вас уже стоит плагин для технической чистки сайта, например Clearfy Pro, проверьте, нет ли там отдельной опции для отключения emoji и других стандартных подключений WordPress. Это удобнее, чем держать отдельный фрагмент кода, если вы централизуете оптимизацию в одном месте. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
Как проверить, что отключение сработало
После внедрения не ограничивайтесь визуальной проверкой. Emoji-скрипт может быть убран из HTML, но кеш или CDN покажут старую версию страницы. Проверяйте результат по шагам:
- очистите кеш плагина, сервера и CDN;
- откройте страницу в режиме инкогнито;
- посмотрите исходный код и убедитесь, что
wp-emoji-release.min.jsбольше не выводится; - проверьте консоль браузера на предмет ошибок, связанных с emoji;
- откройте админку и редактор записей, если вы отключали и админские подключения.
Дополнительно можно проверить Network в DevTools: на странице не должно быть запроса к emoji-скрипту. Если запрос остался, значит код не загрузился, был подключён не в той теме или его переопределяет другой плагин.
Частые ошибки и как их исправить
Код добавили в родительскую тему
Если вы правите functions.php родительской темы, обновление может затереть изменения. Для постоянной правки используйте дочернюю тему или мини-плагин.
Проверили только главную страницу
На некоторых сайтах главная страница кэшируется отдельно, а внутренние страницы — по другому правилу. Проверяйте хотя бы одну запись, одну страницу и архив, если он у вас открыт.
Отключили emoji частично
Иногда убирают только print_emoji_detection_script, но забывают про стили или RSS-фильтры. В результате часть подключений остаётся, а в отчётах по исходнику всё ещё видно следы emoji-логики.
Сломали старый редактор или письмо из WordPress
Если у вас есть плагины, которые завязаны на старый TinyMCE или отправку писем с emoji-статикой, не снимайте фильтры вслепую. Для таких сайтов лучше сначала отключить только фронтенд, а потом отдельно проверить админку и почтовые уведомления.
Практические советы по безопасности и производительности
Отключение emoji — это не про «ускорить сайт в два раза», а про аккуратную уборку стандартных подключений. Чтобы эффект не потерялся, держите рядом ещё несколько проверок:
- не подключайте один и тот же код в нескольких местах;
- после правки всегда очищайте кеш;
- если используете оптимизатор JS/CSS, проверьте, не дублирует ли он отключение emoji;
- не удаляйте файлы ядра WordPress вручную — это ломает обновления и не решает задачу;
- если сайт обслуживает несколько редакторов, зафиксируйте изменение в репозитории или в changelog.
Для технически чистых проектов лучше собирать такие правки в одном месте: мини-плагин для системных отключений, отдельный файл для оптимизаций и понятная схема тестирования после обновлений. Тогда отключение emoji не превратится в случайную правку, которую никто не помнит через месяц.