В WordPress emoji-поддержка подключается автоматически и тянет за собой лишние скрипты и стили в <head>. На небольших сайтах это не критично, но на проектах, где важны чистый HTML, контроль над запросами и минимизация фронтенда, такие мелочи лучше убрать. Особенно если вы уже вычищаете дубли, отключаете лишние функции ядра и следите за количеством запросов на каждой странице.
Сценарий обычно один и тот же: в исходнике страницы появляются wp-emoji-release.min.js и инлайн-инициализация, хотя сайт не использует emoji как отдельную функцию. После этого возникает вопрос — можно ли отключить это безопасно, не ломая редактор и контент. Да, можно, если делать это точечно и проверять результат после каждого шага.
Как понять, что emoji действительно грузятся лишними
Сначала стоит не гадать, а посмотреть на факты. Откройте исходный код страницы или вкладку Network в DevTools и найдите запросы, связанные с emoji. В классическом случае вы увидите подключение скрипта из wp-includes/js/wp-emoji-release.min.js и inline-код, который добавляет классы в <html>. На части сайтов это тянется даже тогда, когда в контенте нет ни одного emoji.
Если вы используете плагин для оптимизации фронтенда, проверьте, не отключает ли он emoji уже сам. Иначе получится двойная настройка: часть кода убрана, часть остаётся, а потом сложно понять, что именно сработало. Для диагностики полезно сравнить исходник страницы до и после изменений и проверить не только главную, но и записи, страницы и архивы.
Что именно искать в исходнике
wp-emoji-release.min.jsв<head>или внизу страницы;- инлайн-скрипт с проверкой поддержки emoji;
- подключение стилей, если тема или плагин добавляют их отдельно;
- ошибки в консоли после отключения, если какой-то старый скрипт ожидает emoji-функции.
Пошаговое отключение emoji через код
Самый надёжный способ — убрать стандартные действия WordPress через хук init. Это не требует стороннего плагина и легко откатывается. Код лучше добавлять в дочернюю тему или в небольшой mu-plugin, если вы ведёте несколько сайтов и хотите сохранить настройку при смене темы.
<?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-скрипт и стили из фронтенда и админки. Если вам важно оставить emoji в админке, можно не трогать admin_print_scripts и admin_print_styles, но на практике это редко нужно. Для большинства сайтов безопаснее отключить всё единообразно и не плодить исключения.
Если вы не хотите править тему, можно оформить это как мини-плагин. Это удобнее для поддержки: код не потеряется после обновления шаблона и не смешается с кастомными функциями темы.
<?php
/**
* Plugin Name: Disable Emoji Support
*/
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );Когда лучше использовать плагин, а когда код
Если задача разовая и у вас нет доступа к коду темы, можно использовать плагин оптимизации, который умеет отключать emoji. Но если вы уже ведёте техническую чистку сайта, код обычно надёжнее: он прозрачен, не зависит от интерфейса плагина и не создаёт лишнюю точку отказа.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль, предсказуемость, нет лишних зависимостей | Нужно аккуратно вносить изменения и хранить код в репозитории |
| Плагин оптимизации | Быстро включить без правки файлов | Настройка может сбиться после обновления или миграции |
| Ничего не делать | Нет риска сломать конфигурацию | Лишние запросы и шум в head остаются |
Если у вас уже стоит плагин вроде Clearfy Pro и в нём есть опция отключения emoji, это нормальный вариант для типового сайта. Но всё равно проверьте, не конфликтует ли он с другими оптимизаторами, которые тоже вмешиваются в wp_head. Два плагина, которые удаляют одни и те же хуки, часто создают путаницу при отладке.
Как проверить, что отключение сработало
Проверка должна быть не визуальной, а технической. Откройте страницу в режиме инкогнито, посмотрите исходный код и убедитесь, что строк с wp-emoji-release.min.js больше нет. Затем откройте DevTools и обновите страницу с отключённым кэшем. В Network не должно быть запроса к emoji-скрипту, а в <head> не должно остаться инлайн-инициализации.
Дополнительно проверьте админку: редактор записей, экран комментариев, форму входа. Если вы отключали emoji через код, а не через плагин, убедитесь, что в консоли нет ошибок JavaScript. На практике это редкость, но проверка занимает минуту и экономит время на поиске побочных эффектов.
Мини-чек-лист после внедрения
- в исходнике страницы нет
wp-emoji-release.min.js; - в
<head>отсутствует emoji-инициализация; - страницы открываются без ошибок в консоли;
- редактор и админка работают как обычно;
- кэш очищен, иначе вы можете смотреть старую версию HTML.
Частые ошибки и как их исправить
Ошибка 1: код добавили в неправильное место. Если вставить его в файл, который не загружается на фронтенде, ничего не изменится. Для темы используйте functions.php дочерней темы или mu-plugin. Для проверки можно временно добавить логирование или просто убедиться, что файл действительно подключается.
Ошибка 2: отключили emoji, но смотрите старый HTML из кэша. Это частая причина ложных выводов. Очистите серверный кэш, кэш плагина, CDN и браузер. Иначе кажется, что код не работает, хотя на самом деле вы видите старую версию страницы.
Ошибка 3: конфликт с плагином оптимизации. Если один плагин удаляет emoji, а другой заново добавляет часть скриптов через собственные фильтры, результат будет непредсказуемым. В таком случае оставьте только один источник оптимизации и проверьте порядок загрузки плагинов.
Ошибка 4: отключили всё подряд в админке. Иногда после агрессивной чистки начинают ломаться мелкие элементы интерфейса, особенно если сайт старый и на нём есть кастомный JS. Если это произошло, верните отключение только на фронтенде и проверьте, какие именно экраны админки зависят от старого кода.
Что ещё можно убрать вместе с emoji, если цель — чистый head
Если вы уже занимаетесь технической чисткой WordPress, emoji обычно идут в одном списке с другими необязательными элементами: лишними мета-тегами, REST-ссылками, oEmbed, RSD и прочими стандартными вставками ядра. Но удалять их стоит по одному, с проверкой после каждого изменения. Иначе сложно понять, что именно вызвало проблему.
Хорошая практика — вести отдельный файл с техническими отключениями и комментировать каждое действие. Тогда при обновлении сайта или передаче проекта другому разработчику не придётся вспоминать, почему из head исчез тот или иной фрагмент. Для production-сайта это важнее, чем кажется: такие мелкие настройки быстро забываются, а потом всплывают в самый неудобный момент.
Если нужен более широкий набор точечных отключений без ручной сборки, можно смотреть в сторону инструментов, которые закрывают именно техническую чистку WordPress, а не «ускорение всего подряд». Но даже в этом случае базовую проверку исходника и Network лучше делать вручную — это самый надёжный способ понять, что реально изменилось.