WordPress по умолчанию подгружает поддержку emojis через отдельный скрипт и набор фильтров. На небольших сайтах это часто лишняя нагрузка: лишний запрос, лишний код в <head> и в админке, а иногда еще и конфликт с жестко настроенным кэшем или CSP. Если задача — убрать именно штатную emoji-поддержку WordPress, а не «сломать смайлики в контенте», делать это лучше точечно.
Когда отключение Emojis действительно имеет смысл
Отключать emojis стоит не ради абстрактной «оптимизации всего подряд», а когда есть конкретная причина. Например, вы смотрите исходный код страниц и видите подключение wp-emoji-release.min.js, а сайт работает на строгом наборе скриптов. Или у вас уже есть политика по сокращению лишних запросов, и вы хотите убрать то, что не влияет на контент.
Важно понимать: WordPress emojis — это не «смайлики в тексте», а встроенная механика, которая добавляет поддержку старых браузеров и некоторых символов. Если вы отключите ее, обычный Unicode-контент останется на месте. Но если у вас есть старые письма, формы или интеграции, где кто-то рассчитывал на автозамену, это нужно проверить отдельно.
Диагностика: что именно загружается сейчас
Перед изменениями проверьте, есть ли на сайте emoji-скрипт и стили. Это делается без плагинов, прямо в браузере и в коде темы.
Что искать в исходном коде страницы
wp-emoji-release.min.jsв<head>или внизу страницы;- инлайн-скрипт с проверкой canvas для emojis;
- подключение через
print_emoji_detection_scriptиprint_emoji_styles; - дублирующиеся подключения, если тему или плагин уже пытались «оптимизировать» вручную.
Если вы используете DevTools, откройте вкладку Network и отфильтруйте по emoji. На типичном сайте будет видно, грузится ли отдельный JS-файл и есть ли связанные стили.
Проверка через код темы
Если есть доступ к файлам, можно быстро понять, не отключал ли кто-то emojis раньше. Ищите в functions.php или в mu-плагинах такие строки:
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' );Если эти вызовы уже есть, а скрипт все равно подгружается, значит отключение сделано не полностью или его возвращает другой плагин.
Как отключить Emojis правильно
Есть три рабочих подхода: через код, через плагин оптимизации или через комбинацию с очисткой кэша. Для технически аккуратного сайта обычно достаточно кода в дочерней теме или в небольшом mu-плагине.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-плагине | Прозрачно, без лишних зависимостей | Нужно не забыть про обновления и место размещения |
| Плагин оптимизации | Быстро, без правки файлов | Легко получить дублирующие настройки |
| Комбинация с кэшем | Сразу видно эффект на фронтенде | Нужно очистить кэш и проверить CDN |
Вариант 1: отключить emojis кодом
Самый предсказуемый способ — добавить небольшой фрагмент в functions.php дочерней темы или в собственный mu-плагин:
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' );
} );Этот вариант убирает не только фронтенд, но и часть административной нагрузки, а также фильтры для RSS и писем. Если вам нужно отключить только публичную часть сайта, можно оставить только wp_head и стили, но на практике чаще убирают все штатные emoji-хуки.
Вариант 2: использовать плагин оптимизации
Если на сайте уже стоит плагин для чистки WordPress, проверьте, нет ли в нем отдельной опции отключения emojis. Это удобно, когда вы не хотите держать кастомный код в теме. Но важно не включать ту же оптимизацию дважды: если плагин уже снимает emoji-хуки, ручной код не даст пользы, а только усложнит поддержку.
Если вы используете Clearfy Pro, подобные настройки обычно логичнее держать в одном месте вместе с другими техничными отключениями. Это не обязательное условие, но на проектах с несколькими оптимизациями такой подход проще сопровождать.
Проверка результата после внедрения
После отключения не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что WordPress действительно перестал добавлять emoji-ассеты и что ничего не сломалось в админке.
Что проверить вручную
- откройте исходный код главной страницы и нескольких внутренних страниц;
- убедитесь, что
wp-emoji-release.min.jsбольше не присутствует; - проверьте админку: редактор записей, комментарии, экран настроек;
- отправьте тестовое письмо из сайта, если у вас есть формы уведомлений;
- очистите серверный кэш, плагин-кэш и CDN, если он используется.
Быстрая проверка через браузер
В консоли DevTools можно проверить наличие emoji-скрипта по сетевым запросам. Если вы видите, что файл больше не запрашивается, значит отключение сработало на уровне фронтенда. Но если страница отдается из кэша, сначала очистите его, иначе вы будете смотреть старую версию HTML.
// В консоли браузера можно быстро проверить наличие emoji-скрипта в DOM
Array.from(document.scripts).some(function (script) {
return script.src && script.src.indexOf('wp-emoji-release') !== -1;
});Если результат false, а в исходнике файла тоже нет, значит отключение применилось корректно.
Частые ошибки и как их исправить
Отключили только фронтенд, но не админку
Так бывает, когда убирают только wp_head, а admin_print_scripts и admin_print_styles оставляют. В итоге на сайте все чисто, но в панели управления скрипт продолжает грузиться. Если цель — полное отключение, снимайте все связанные действия.
Сделали правку в родительской теме
После обновления темы изменения пропадут. Для таких задач лучше использовать дочернюю тему или mu-плагин. Если проект уже живет на кастомной сборке, отдельный mu-плагин часто даже удобнее: он не зависит от активной темы.
Не очистили кэш
Это самая частая причина ложного вывода «не работает». WordPress уже не добавляет emoji-скрипт, но CDN или плагин кэширования отдает старую HTML-версию. После правки очищайте все уровни кэша, включая браузерный, если тестируете на локальной машине через старую вкладку.
Отключили не то, что нужно
Иногда под «убрать emojis» имеют в виду вообще все смайлики в контенте. Это другая задача: Unicode-символы в записях не зависят от штатных emoji-хуков WordPress. Если в тексте есть эмодзи, они останутся, пока их не режет тема, редактор или внешний фильтр.
Безопасность и производительность: что учитывать
Само по себе отключение emojis безопасно, если вы не правите ядро и не вставляете код в случайный плагин. Но есть несколько практических моментов.
- не редактируйте
functions.phpпрямо на продакшене без резервной копии; - если используете mu-плагин, храните его в репозитории вместе с проектом;
- проверяйте, не дублирует ли оптимизацию плагин кеширования или минификации;
- после изменения сравните HTML до и после, чтобы убедиться, что вы убрали только emoji-часть, а не другие скрипты.
Если на сайте уже есть строгая политика по чистке WordPress, отключение emojis обычно хорошо ложится в общую схему: меньше лишних подключений, меньше точек для конфликтов и проще диагностика. Но это не «ускоритель в один клик» — эффект стоит оценивать в контексте всего фронтенда, а не по одному файлу.
Когда лучше не отключать
Если сайт обслуживает старую аудиторию с очень специфичными браузерами, либо у вас есть интеграции, которые завязаны на штатные фильтры WordPress для писем и RSS, сначала проверьте поведение на тестовой копии. В обычных современных проектах это редкость, но на старых корпоративных сайтах такие зависимости встречаются.
Практический ориентир простой: если вы не видите реальной пользы от emoji-поддержки, ее можно убрать. Если же вы не уверены, сначала проверьте, кто именно использует эти фильтры, и только потом отключайте их точечно.