На небольших сайтах это редко заметно, но на проектах с аккуратной оптимизацией каждый лишний запрос и подключаемый файл начинают раздражать. WordPress по умолчанию добавляет поддержку emoji через скрипты и стили, даже если на сайте они не нужны. Это не критическая проблема, но если вы уже чистите фронтенд от лишнего кода, отключение emoji — один из самых безопасных и предсказуемых шагов.
Здесь важно не просто «вырубить что-то в functions.php», а понять, какие именно элементы отключаются, что останется работать и как быстро проверить, что сайт не потерял нужные функции в админке и на фронтенде.
Когда отключение emoji действительно имеет смысл
Отключать emoji стоит не ради абстрактной «оптимизации», а если вы видите конкретные признаки:
- в исходном коде страницы подключаются
wp-emoji-release.min.jsи inline-скрипт для emoji; - вы сознательно минимизируете количество запросов на фронтенде;
- сайт работает в корпоративной среде, где emoji в контенте не используются;
- вы хотите убрать лишние inline-обработчики из
<head>и редактора.
Если на сайте активно используют emoji в комментариях, постах или в редакторе, отключение на фронтенде обычно безопасно. Но полностью удалять поддержку без проверки не стоит: в некоторых сценариях редактор и админка могут вести себя по-разному, особенно если тема или плагин рассчитывают на стандартные скрипты WordPress.
Диагностика: что именно загружается сейчас
Перед изменениями откройте исходный код страницы и найдите упоминания emoji. Обычно это:
wp-emoji-release.min.js;- inline-блок с проверкой поддержки emoji;
- иногда дополнительные стили или фильтры, если их добавляет тема или плагин.
Проверить можно и через DevTools: вкладка Network покажет, есть ли запрос к скрипту emoji. Если сайт уже использует кеширование, сравнивайте не только «живую» страницу, но и очищенную от кеша версию.
Полезно также посмотреть, не отключал ли кто-то часть функциональности раньше. Если в теме уже есть кастомный код, повторное вмешательство может дать дублирующиеся фильтры или лишние вызовы.
Пошаговое решение через functions.php или мини-плагин
Самый практичный вариант — вынести код в мини-плагин или в functions.php дочерней темы. Для боевого сайта мини-плагин предпочтительнее: он не исчезнет при смене темы.
Код для отключения emoji на фронтенде и в админке
<?php
/**
* Plugin Name: Disable WordPress Emoji
*/
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-скрипты и стили WordPress. Он не трогает сами символы emoji в тексте: если браузер и шрифт их поддерживают, они будут отображаться как обычные Unicode-символы.
Если вы добавляете код в functions.php, используйте дочернюю тему. Иначе после обновления темы настройка исчезнет.
Если нужен более аккуратный вариант только для фронтенда
Иногда админку лучше не трогать, особенно если редакторы работают с контентом и вы не хотите менять привычное поведение. Тогда отключайте только фронтенд-часть:
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Такой вариант обычно достаточно безопасен для большинства сайтов. Админка продолжит работать как раньше, а лишние запросы на публичной части исчезнут.
Сравнение подходов: код, плагин или ничего не делать
| Подход | Что даёт | Минус |
|---|---|---|
| Код в мини-плагине | Контроль, предсказуемость, не зависит от темы | Нужно один раз аккуратно внедрить |
| Код в дочерней теме | Быстрое внедрение без отдельного плагина | Привязка к теме |
| Ничего не менять | Ноль риска для текущей конфигурации | Лишние скрипты остаются |
Если у вас уже есть плагин для технической чистки сайта, например Clearfy Pro, подобные вещи удобнее собирать в одном месте. Но если задача точечная, отдельный мини-плагин часто проще и прозрачнее, чем ещё один слой настроек.
Проверка результата после внедрения
После добавления кода проверьте не «на глаз», а по фактам:
- Откройте исходный код страницы и убедитесь, что
wp-emoji-release.min.jsбольше не подключается. - Проверьте вкладку Network в браузере: запросов к emoji-скрипту быть не должно.
- Откройте админку и редактор записей: убедитесь, что ввод текста и сохранение контента работают штатно.
- Проверьте комментарии и письма, если на сайте они активно используются.
Если на сайте включён кеш, очистите его после правки. Иначе вы можете смотреть на старую версию страницы и решить, что код не сработал.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить код в активную тему без дочерней темы, он пропадёт после обновления. Для постоянной настройки используйте мини-плагин или child theme.
Отключили не тот хук
Иногда пытаются удалить только wp_head-часть и забывают про стили. В результате часть emoji-логики остаётся в разметке. Для чистого отключения убирайте и скрипт, и стили.
Сломали совместимость с плагином
Редко, но бывает: плагин сам рассчитывает на стандартные emoji-функции WordPress в письмах или RSS. Если после отключения появились странности в рассылке или фидах, верните фильтры, связанные с wp_staticize_emoji, и проверьте поведение ещё раз.
Проверяли без очистки кеша
Это самая частая причина ложного вывода «не работает». После изменения кода очищайте серверный кеш, кеш плагина и кеш браузера.
Чек-лист перед выкладкой на продакшен
- Код добавлен в мини-плагин или дочернюю тему.
- Проверено, что emoji-скрипт исчез из исходного кода.
- Открыта админка и протестирован редактор.
- Очищен кеш сайта и CDN, если он есть.
- Проверены комментарии, RSS и письма, если они используются.
Что ещё можно сделать для чистки фронтенда
Если вы уже занимаетесь технической оптимизацией, отключение emoji логично идёт рядом с другими точечными правками: удалением лишних эмодзи-скриптов, чисткой дублей в <head>, отключением неиспользуемых встроенных функций WordPress. Но важно не превращать это в «массовое отключение всего подряд»: каждая правка должна быть проверяема и обратима.
Для сайтов, где техническая чистка делается регулярно, полезно держать список изменений и проверять их после обновлений ядра, темы и ключевых плагинов. WordPress меняется, и то, что было безопасно в одной версии, лучше перепроверить после апдейта.