В WordPress поддержка emoji включена по умолчанию и тянет за собой отдельный скрипт и стили. На небольшом сайте это не катастрофа, но на проектах, где уже вычищают лишние запросы, собирают фронтенд по косточкам и следят за количеством подключений, этот хвост обычно убирают. Важно сделать это аккуратно: не сломать редактор, не задеть админку и не пытаться «оптимизировать» то, что уже отключено темой или плагином.
Когда отключение emoji действительно имеет смысл
Сценарий простой: вы открываете исходный код страницы и видите подключение wp-emoji-release.min.js или инлайн-скрипт, который проверяет поддержку emoji. Если сайт не использует старые браузеры, а контент не зависит от автозамены символов, это лишняя нагрузка. Обычно отключение имеет смысл на сайтах с жёсткой оптимизацией фронтенда, в связке с кешированием и минимизацией запросов.
Но если у вас нестандартный редакторский процесс, много внешних вставок или старые корпоративные устройства в аудитории, сначала проверьте, не завязан ли кто-то из плагинов на этот функционал. Сам WordPress от отключения emoji не ломается, но сторонние решения могут вести себя по-разному.
Диагностика: что именно подключается и откуда
Перед правкой не гадайте. Посмотрите, есть ли emoji-скрипт на фронтенде и в админке. На публичной странице откройте исходник или вкладку Network в DevTools и найдите запросы, связанные с emoji. В типичной установке это:
wp-emoji-release.min.js;- инлайн-скрипт с проверкой canvas;
- иногда стили, если их добавляет тема или плагин поверх ядра.
Если запросов нет, значит, отключение уже сделано раньше — повторно ничего добавлять не нужно. Это частая ошибка: люди вносят код «на всякий случай» и потом ищут, почему в админке исчезли нужные элементы или почему оптимизатор начал ругаться на дублирующиеся фильтры.
Что проверить до изменений
- Есть ли у вас плагин оптимизации, который уже отключает emoji.
- Не переопределяет ли тема
wp_headилиadmin_print_scripts. - Не подключён ли отдельный минификатор, который собирает ядровые скрипты в один файл.
Пошаговое решение через код
Самый надёжный вариант — убрать emoji через functions.php дочерней темы или через небольшой mu-plugin. Так вы контролируете поведение и не зависите от настроек стороннего плагина.
<?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' );
} );Этот вариант безопасен тем, что не трогает ядро и работает на уровне хуков. Если вы используете mu-plugin, код можно положить в отдельный файл в wp-content/mu-plugins/disable-emoji.php. Тогда он будет загружаться всегда и не потеряется при смене темы.
Если нужен более управляемый вариант
На проектах, где оптимизацией занимается не разработчик, а администратор, удобнее вынести отключение в плагин для обслуживания сайта. Например, в Clearfy Pro есть набор функций для чистки лишнего кода и дублей; если вы уже используете такой инструмент, проверьте, не включена ли там опция отключения emoji. Это не обязательный путь, но он удобен, когда нужно централизованно управлять техническими настройками без правки темы. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в mu-plugin | Надёжно, прозрачно, не зависит от темы | Нужен доступ к файлам и базовое понимание хуков |
| Код в functions.php | Быстро внедрить | Смените тему — настройка пропадёт |
| Плагин оптимизации | Удобно для неразработчика | Риск дублирования настроек, если emoji уже отключены в другом месте |
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по факту. После внедрения откройте главную страницу и любую внутреннюю страницу в режиме инкогнито, затем:
- Посмотрите исходный код и убедитесь, что
wp-emoji-release.min.jsбольше не подключается. - Проверьте вкладку Network: запросов, связанных с emoji, быть не должно.
- Откройте админку и редактор записей: интерфейс должен работать как обычно.
- Если у вас есть кеш-плагин или серверный кеш, очистите его и проверьте ещё раз без старых HTML-версий.
Если скрипт всё ещё есть, значит, его добавляет не ядро, а другой плагин или тема. В этом случае ищите подключение по имени файла или по функции print_emoji_detection_script в кодовой базе.
Частые ошибки и почему они возникают
Самая распространённая ошибка — отключить emoji только на фронтенде и забыть про админку. Это не критично, но создаёт ощущение, что «что-то не до конца убрали». Если задача — чистка всего сайта, убирайте оба источника.
Вторая ошибка — добавлять код в тему без дочерней темы. После обновления изменения исчезнут, и вы снова увидите лишний скрипт. Для технических правок лучше использовать mu-plugin или дочернюю тему.
Третья ошибка — отключать emoji через несколько плагинов сразу. Так легко получить конфликт фильтров: один плагин снимает скрипт, другой снова его возвращает, а третий минифицирует старую версию и ломает порядок загрузки. Если у вас уже есть оптимизатор, проверьте его настройки до ручной правки.
Что делать, если после отключения что-то сломалось
- Верните код обратно и проверьте, не было ли стороннего плагина, который ожидал emoji-функции.
- Отключайте изменения по одному, а не пачкой вместе с другими чистками.
- Сравните поведение на чистом шаблоне и на текущей теме.
Практические советы по безопасности и производительности
Если вы уже полезли в техническую оптимизацию, не ограничивайтесь emoji. Проверьте, не отключаете ли вы одновременно то, что нужно для нормальной работы редактора, REST API или предпросмотра записей. Любая чистка должна быть обратимой: храните изменения в отдельном файле, а не в случайном фрагменте темы.
После правки полезно пройтись по списку:
- сделать резервную копию перед изменениями;
- проверить сайт в инкогнито и в админке;
- очистить кеш страницы и браузера;
- сверить исходный код до и после;
- не дублировать отключение в нескольких местах.
Если вам нужен не только этот пункт, а системная чистка лишних подключений, удобнее собирать такие настройки в одном месте, а не размазывать по теме и нескольким плагинам. Тогда проще понять, что именно влияет на фронтенд и где искать регрессии.