Встроенная поддержка emoji в WordPress редко нужна на обычном сайте, но её скрипты и стили всё равно могут грузиться на фронтенде и в админке. На небольшом проекте это не критично, а вот на сайте с жёсткой оптимизацией каждый лишний запрос и лишний блок кода в <head> уже заметен. Проблема в том, что отключать emoji нужно аккуратно: убрать только то, что действительно относится к этой функции, и не задеть редактор, комментарии или кастомные скрипты темы.
Что именно отключаем и где это видно
WordPress добавляет emoji-поддержку через набор скриптов и фильтров. На фронтенде это обычно проявляется как дополнительные подключения в <head> и иногда как отдельный inline-скрипт. В админке часть логики может оставаться, потому что редактор и панель управления используют свои зависимости. Если задача — ускорить публичную часть сайта, обычно достаточно убрать фронтенд-обвязку и проверить, не тянет ли тема или плагин emoji отдельно.
Когда отключение действительно уместно
Имеет смысл трогать emoji, если вы:
- оптимизируете сайт под PageSpeed и хотите убрать ненужные запросы;
- используете строгую CSP-политику и контролируете все внешние и встроенные скрипты;
- поддерживаете сайт, где emoji не используются в контенте;
- наследуете старую тему с лишними подключениями в
wp_headиadmin_print_scripts.
Если сайт активно редактируют через блоковый редактор и команда часто вставляет эмодзи в тексты, отключение не даст заметной пользы и только добавит точку для поддержки.
Диагностика проблемы: как понять, что emoji реально грузятся
Сначала проверьте исходный код страницы. Откройте фронтенд, посмотрите <head> и найдите упоминания wp-emoji-release.min.js или inline-скрипта с проверкой canvas. В DevTools на вкладке Network можно отфильтровать запросы по слову emoji и увидеть, есть ли отдельная загрузка.
Ещё один практичный способ — временно открыть страницу в режиме инкогнито и сравнить исходник до и после отключения. Если у вас кэш на уровне плагина или сервера, чистите его перед проверкой, иначе можно смотреть на старую версию HTML и сделать ложный вывод.
Что проверить до правки кода
- не подключает ли тему свой собственный emoji-скрипт;
- нет ли оптимизатора, который уже удаляет emoji автоматически;
- не используется ли плагин для комментариев или редактора, завязанный на стандартные скрипты WordPress;
- не стоит ли у вас CDN или кэш, который отдаёт старый
<head>.
Пошаговое решение через functions.php или mu-plugin
Самый надёжный способ — убрать стандартные действия WordPress через remove_action и фильтры. Лучше делать это не в теме, если сайт живёт долго: для таких правок удобнее mu-plugin, чтобы код не исчез при смене темы.
Вариант 1: отключить emoji на фронтенде и в админке
<?php
/**
* Plugin Name: Disable Emoji Support
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
function wppolls_disable_emojis() {
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' );
}
add_action( 'init', 'wppolls_disable_emojis' );Этот вариант убирает стандартную emoji-обвязку WordPress. Если после этого в исходнике всё ещё есть emoji-скрипт, значит его добавляет не ядро, а тема или плагин.
Вариант 2: отключить только на фронтенде
Если вы не хотите трогать админку, можно ограничиться публичной частью сайта. Это безопаснее для редакторов и меньше риск сломать сторонние плагины, которые ожидают стандартные скрипты в панели управления.
<?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' );
} );Если у вас есть отдельная интеграция для почты или RSS, проверьте, не рассчитывает ли она на преобразование emoji в текстовые сущности. Обычно это не проблема, но на старых проектах лучше убедиться.
Что выбрать: код, плагин или оптимизатор
Если задача разовая и вы ведёте проект как разработчик, код в mu-plugin обычно предпочтительнее. Если сайт поддерживает редактор без доступа к FTP, удобнее взять плагин для чистки лишнего кода. В некоторых случаях emoji уже отключаются вместе с другими оптимизациями в одном инструменте.
| Подход | Плюсы | Минусы |
|---|---|---|
Код в mu-plugin |
Контроль, предсказуемость, не зависит от темы | Нужен доступ к файлам и базовое понимание WordPress |
| Плагин оптимизации | Быстро включить, часто есть рядом другие полезные настройки | Лишняя зависимость, возможны конфликты с уже установленными оптимизаторами |
| Оставить как есть | Ничего не ломаете | Лишние запросы и шум в исходнике остаются |
Если у вас уже стоит плагин для удаления дублей и технической чистки сайта, например Clearfy Pro, проверьте, не отключает ли он emoji отдельно. Тогда не нужно дублировать ту же настройку кодом.
Проверка результата после внедрения
После правки очистите все уровни кэша: плагин, сервер, CDN, браузер. Затем откройте главную страницу и любую внутреннюю запись, посмотрите исходный код и убедитесь, что в <head> больше нет wp-emoji-release.min.js и связанных стилей. На вкладке Network проверьте, что запросы с emoji исчезли.
Полезно сделать ещё две проверки:
- открыть страницу в режиме инкогнито и сравнить HTML до и после;
- проверить RSS-ленту и письмо, если сайт использует рассылки из WordPress;
- зайти в админку и убедиться, что редактор и медиа-библиотека работают как раньше.
Если вы используете автоматические тесты или мониторинг, добавьте контрольный просмотр HTML-фрагмента. Это проще, чем искать регрессию уже после обновления ядра или плагинов.
Частые ошибки и как их исправить
Удалили не тот хук
Иногда пытаются убрать emoji через несуществующие или устаревшие вызовы, а потом удивляются, что ничего не изменилось. Используйте именно стандартные функции WordPress: print_emoji_detection_script, print_emoji_styles, wp_staticize_emoji и wp_staticize_emoji_for_email.
Проверили без очистки кэша
Это самая частая причина ложного результата. Если кэш не сброшен, вы смотрите старую версию страницы и думаете, что код не сработал. Перед диагностикой очищайте кэш плагина, сервера и CDN.
Отключили emoji, но скрипт остался
Значит, его добавляет тема или другой плагин. Ищите по проекту строку wp-emoji-release или вызовы, связанные с emoji. На практике это часто встречается в кастомных шаблонах, где кто-то вручную вставил старый код оптимизации.
Сломали почту или RSS
Если вы слишком агрессивно вырезали фильтры, проверьте, не затронули ли преобразование emoji в письмах и лентах. Для обычного сайта это редко критично, но на проекте с автоматическими рассылками лучше протестировать отправку тестового письма и открыть RSS в браузере.
Практические советы по безопасности и производительности
Не правьте functions.php на живом сайте через админку, если у вас нет нормального бэкапа и доступа к файлам. Ошибка в PHP легко положит сайт. Для таких мелких оптимизаций безопаснее использовать mu-plugin или отдельный мини-плагин, который можно быстро отключить.
Если вы ведёте несколько сайтов, держите такие правки в отдельном репозитории. Тогда отключение emoji, удаление лишних тегов из <head> и другие технические настройки можно переносить между проектами без ручного копирования.
И ещё один практический момент: не пытайтесь «ускорить всё сразу» одним большим оптимизатором, если уже есть кэш, минификация и отдельные правки в теме. Сначала проверьте, что именно даёт эффект, иначе потом сложно понять, какая настройка сломала фронтенд.