WordPress до сих пор по умолчанию подгружает поддержку emoji через дополнительные скрипты и стили. На небольшом сайте это не выглядит критичной проблемой, но на проектах, где уже вычищают лишние запросы и считают каждый ресурс, такие мелочи быстро накапливаются. Если задача простая — убрать этот функционал без плагина и без побочных эффектов — лучше сделать это кодом и сразу проверить результат.
Когда отключение emoji действительно имеет смысл
Речь не про «ускорить сайт в два раза», а про аккуратную техническую чистку. Отключать emoji имеет смысл, если вы:
- оптимизируете фронтенд и убираете лишние подключения из
<head>; - не используете старые браузеры, которым нужна отдельная подмена emoji;
- хотите сократить количество HTTP-запросов и упростить разметку;
- поддерживаете проект, где важна предсказуемость ядра и минимальный набор автоподключений.
Если сайт активно редактируют через классический редактор или в контенте много эмодзи, отключение не сломает их отображение в современных браузерах. Но если у вас есть специфические требования к старым клиентам, это нужно проверить отдельно.
Диагностика: что именно грузит WordPress
По умолчанию WordPress добавляет на фронтенде и в админке скрипт wp-emoji-release.min.js, а также inline-логику для подмены emoji. Это можно увидеть в исходном коде страницы или через DevTools.
Как быстро проверить наличие emoji-скрипта
- Откройте любую страницу сайта в браузере.
- Посмотрите исходный код и найдите
wp-emoji-release.min.js. - Вкладка Network покажет отдельный запрос к этому файлу.
- Если используете кеширующий плагин или CDN, проверьте и очищенную, и неочищенную версию страницы.
Если скрипт есть, значит WordPress не был очищен от стандартной emoji-логики. Это нормальная ситуация для большинства установок.
Пошаговое решение без плагина
Самый безопасный путь — добавить код в functions.php дочерней темы или в собственный мини-плагин. Для продакшена мини-плагин обычно предпочтительнее: он не зависит от темы и не исчезнет после смены шаблона.
Вариант через functions.php
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 применяет к контенту и письмам. Для большинства сайтов этого достаточно.
Вариант через мини-плагин
Если не хотите привязываться к теме, создайте файл, например disable-emojis.php, в каталоге wp-content/plugins/ и активируйте его как обычный плагин.
<?php
/**
* Plugin Name: Disable Emojis
*/
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' );
} );Для поддержки на нескольких проектах это удобнее: код лежит отдельно, его проще включать и отключать, а тема остаётся чистой.
Сравнение подходов: плагин, код, компромисс
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме | Быстро, без лишних зависимостей | Сломается при смене темы | Если нужен быстрый фикс на одном сайте |
| Мини-плагин | Не зависит от темы, удобно переносить | Нужно один раз создать файл | Если сайт живёт долго и его поддерживают |
| Оптимизационный плагин | Можно собрать несколько чисток в одном месте | Легко переборщить с отключениями | Если уже используете плагин для техоптимизации |
Если у вас уже стоит инструмент для чистки WordPress, например Clearfy Pro, проверьте, не отключается ли emoji там. В этом случае не дублируйте логику в теме, иначе потом будет сложнее искать источник поведения.
Проверка результата после внедрения
После добавления кода важно не ограничиваться визуальной проверкой. Нужно убедиться, что WordPress действительно перестал печатать emoji-ресурсы.
- Откройте исходный код страницы и найдите
wp-emoji-release.min.js— его быть не должно. - Проверьте
<head>на наличие emoji-стилей. - Откройте админку и убедитесь, что редактор и форма комментариев работают штатно.
- Проверьте письмо от сайта, если у вас есть тестовая отправка: эмодзи в теме письма и тексте должны отображаться корректно в современных почтовых клиентах.
Если используете кеш, очистите его после изменений. Иначе вы можете смотреть на старую версию страницы и решить, что код не сработал.
Что смотреть в DevTools
Во вкладке Network не должно быть запроса к emoji-скрипту. Если запрос остаётся, значит код не выполняется, либо его перебивает другой плагин, либо вы смотрите не ту среду — например, кешированную страницу через CDN.
Частые ошибки и как их исправить
На практике проблемы обычно не в самом коде, а в том, куда и как его вставили.
- Добавили код в файл темы, который потом обновили. Решение: перенести в дочернюю тему или мини-плагин.
- Вставили код в неправильный хук. Для удаления emoji-логики используйте
init, а не случайные хуки рендера. - Не очистили кеш. После правки проверьте и серверный кеш, и кеш CDN, и кеш браузера.
- Отключили emoji, но оставили дублирующий плагин. Если оптимизационный плагин тоже управляет этой настройкой, не держите два источника правды.
- Сломали письмо или RSS. Это бывает, если удалить только часть фильтров и не проверить каналы вывода контента.
Безопасность и производительность: что учесть дополнительно
Отключение emoji — это мелкая оптимизация, но она хорошо ложится в общий аудит сайта. Если вы уже чистите WordPress, заодно проверьте:
- не подключаются ли лишние стили и скрипты в
wp_head; - нет ли дублирующихся SEO-метаданных;
- не грузятся ли на каждой странице ресурсы, которые нужны только в админке;
- не остались ли старые плагины, которые дублируют функции ядра.
Если нужен более широкий набор технической чистки без ручного кода, имеет смысл смотреть в сторону инструментов вроде Clearfy Pro: там можно собрать несколько типовых отключений в одном месте и не держать их в теме. Но для одной точечной задачи код обычно надёжнее и прозрачнее.
Когда лучше не отключать emoji
Есть сценарии, где лучше не трогать стандартное поведение без необходимости. Например, если сайт обслуживает очень старые устройства, или если вы не контролируете весь стек и не можете быстро откатить изменения. В таком случае сначала протестируйте правку на staging-копии, а уже потом переносите в продакшен.
Если задача именно в уменьшении количества запросов, отключение emoji — нормальный и безопасный шаг. Главное — делать его осознанно: через код, с проверкой исходника, с очисткой кеша и с пониманием, кто ещё в проекте может управлять тем же поведением.