WordPress до сих пор по умолчанию добавляет поддержку emoji через отдельные скрипты и стили. На современном сайте это часто лишняя нагрузка: дополнительные запросы, лишний JavaScript в <head> и еще один источник мусора в сборке фронтенда. Если сайт работает на обычной кириллице и вы не рассчитываете на старые браузеры, emoji-обвязку обычно можно убрать без заметных побочных эффектов.
Но отключать ее «вслепую» не стоит. Сначала полезно понять, что именно подключается, где это лежит и не ломает ли это контент в админке, если редакторы вставляют символы из внешних источников.
Что именно добавляет WordPress и где это видно
По умолчанию ядро подмешивает обработчик wp-emoji-release.min.js и связанные фильтры. На фронтенде это проявляется как отдельный запрос к скрипту и иногда как инлайн-обработчики в разметке. В большинстве случаев это не критично, но на проектах, где вы выжимаете каждый лишний запрос, такой хвост лучше убрать.
Как быстро проверить наличие emoji-обвязки
Откройте исходный код страницы и найдите упоминания wp-emoji-release. Если используете DevTools, посмотрите вкладку Network и отфильтруйте по слову emoji. Еще один вариант — проверить HTML через консоль:
curl -s https://example.com/ | grep -i emojiЕсли в ответе есть ссылки на wp-emoji-release.min.js или связанные inline-блоки, значит отключение даст реальный эффект, а не просто косметическую правку.
Диагностика: когда отключение уместно, а когда нет
Сценарий простой: если сайт не использует специфические emoji-фоллбеки для старых браузеров и вы не видите зависимостей от этой логики в теме или плагинах, отключение безопасно. Если же у вас корпоративный портал с жесткими требованиями к совместимости или старый кастомный фронтенд, сначала проверьте, не рассчитывает ли тема на стандартные фильтры ядра.
- Проверьте исходный код главной и типовой внутренней страницы.
- Сравните количество запросов до и после правки.
- Откройте редактор записей и убедитесь, что вставка символов не ломает отображение.
- Если стоит кэш-плагин, очистите кэш после изменений.
Пошаговое решение через functions.php или mu-plugin
Самый предсказуемый способ — убрать стандартные действия и фильтры через remove_action и remove_filter. Лучше делать это в дочерней теме или в отдельном mu-plugin, чтобы правка не потерялась при обновлении темы.
<?php
// Убираем emoji-скрипты и связанные фильтры.
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' );Если хотите сделать это аккуратнее и не трогать админку, можно отключить только фронтенд-часть. Тогда редакторы в консоли не заметят изменений, а публичная часть станет чуть чище:
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Для большинства сайтов этого достаточно. Но если тема или плагин добавляют emoji-логики поверх ядра, проверьте исходники через поиск по wp-emoji в каталоге wp-content.
Сравнение подходов: плагин, код, компромисс
| Подход | Что дает | Минус |
|---|---|---|
| Код в дочерней теме | Контроль без лишних зависимостей | Нужно не забыть при смене темы |
| mu-plugin | Не зависит от темы, удобно для техподдержки | Нужен доступ к файловой системе |
| Оптимизирующий плагин | Можно отключить рядом с другими мелкими оптимизациями | Еще одна точка отказа и лишняя админка |
Если у вас уже стоит плагин для технической чистки сайта, имеет смысл проверить, не умеет ли он отключать emoji вместе с другими стандартными хвостами. Например, в Clearfy Pro есть набор опций для удаления лишнего кода ядра и оптимизации фронтенда: https://wpshop.ru/plugins/clearfy?utm_source=wpcourse.ru&utm_medium=article&utm_campaign=otklyuchit-emoji-skripty-v-wordpress. Но если задача точечная, код обычно проще и прозрачнее.
Как проверить, что решение сработало
После внедрения откройте страницу в режиме инкогнито и проверьте три вещи.
- В исходном коде больше нет
wp-emoji-release.min.js. - В Network не появляется отдельный запрос к emoji-скрипту.
- В админке и на фронтенде не сломалась вставка обычных символов и смайлов.
Если используете кэширование на уровне плагина, сервера или CDN, очистите все слои. Иначе вы можете смотреть на старую версию страницы и решить, что код не сработал.
Полезно сравнить размер HTML до и после. Иногда отключение emoji не меняет «вес» страницы драматически, но убирает лишний блок в <head> и упрощает дальнейшую оптимизацию.
Частые ошибки и как их исправить
Правка сделана в родительской теме
Это самая частая проблема. После обновления тема перезапишется, и отключение исчезнет. Перенесите код в дочернюю тему или mu-plugin.
Код добавлен слишком поздно
Если вы вызываете remove_action после того, как ядро уже вывело нужный хук, эффект будет нулевой. Для фронтенда безопасно вешать отключение на init или выполнять его в файле, который загружается до вывода шаблона.
Отключили только фронтенд, но проверяли админку
Это не ошибка, а просто несоответствие ожиданий. Если вы оставили emoji в админке, там он и останется. Сравнивайте именно ту область, которую меняли.
Не очистили кэш
После правки старый HTML может лежать в кэше страницы, на сервере или в CDN. Очистка нужна на всех уровнях, иначе проверка результата будет ложной.
Практические советы по безопасности и производительности
Не ставьте отдельный плагин только ради одной мелкой оптимизации, если ту же задачу можно решить кодом. Чем меньше сторонних зависимостей, тем проще сопровождать сайт. Если же вы уже используете плагин для технической чистки, проверьте, не отключает ли он лишние эмодзи вместе с другими стандартными скриптами, но не включайте все подряд без понимания последствий.
На высоконагруженных проектах такие мелкие правки лучше собирать в один mu-plugin с понятными комментариями. Это удобнее, чем размазывать отключения по нескольким файлам темы. И еще один практический момент: если у вас есть CI или staging, прогоните правку там, а не сразу на боевом сайте.
Если после отключения emoji у вас внезапно ломается какой-то старый виджет или кастомный блок, почти наверняка проблема не в emoji как таковом, а в стороннем коде, который не должен был зависеть от ядрового скрипта. В таком случае откатите правку и ищите конкретный конфликт по файлам темы и плагинов.