Если на сайте WordPress не нужен старый механизм emoji-поддержки, его можно отключить без риска для контента. На практике это полезно не ради «косметики», а чтобы убрать несколько лишних подключений из <head> и сократить шум в HTML. На небольшом сайте эффект не драматический, но для технически чистого фронтенда это нормальная правка, которую легко проверить и откатить.
Важно не путать отключение emoji-скриптов с отключением самих эмодзи в контенте. WordPress продолжит корректно сохранять и выводить символы Unicode, а вы просто уберёте старую совместимость для очень старых браузеров.
Когда это имеет смысл
Сценарий простой: вы открываете исходный код страницы и видите подключения вроде wp-emoji-release.min.js, а также инлайн-скрипт, который проверяет поддержку emoji. Если сайт не ориентирован на старые браузеры, эти элементы обычно не нужны. Их часто отключают вместе с другой чисткой head, когда наводят порядок в шаблоне и плагинах.
Отдельно это полезно, если вы:
- оптимизируете фронтенд и убираете лишние запросы;
- сравниваете HTML до и после правок в теме;
- чистите
headот неиспользуемых сервисных вставок; - хотите уменьшить количество inline-кода без изменения контента.
Диагностика: как понять, что emoji действительно грузятся
Проверка занимает минуту. Откройте любую публичную страницу сайта и посмотрите исходный код. Ищите два признака: подключение скрипта emoji и inline-обработчик в wp_head. Если тема или плагин уже отключили это раньше, повторно ничего делать не нужно.
Что искать в исходнике
wp-emoji-release.min.jsв списке скриптов;- инлайн-функцию, связанную с проверкой emoji в head;
- лишние вызовы, которые добавляются именно WordPress, а не темой.
Если вы не видите этих элементов, значит проблема уже решена на уровне темы, оптимизатора или MU-плагина.
Пошаговое решение через functions.php или MU-плагин
Самый прозрачный способ — добавить небольшой код в дочернюю тему или в собственный MU-плагин. Так вы не зависите от настроек стороннего плагина и точно понимаете, что именно отключили.
<?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. Он не трогает редактор, не ломает сохранение символов и не влияет на обычный текст в записях.
Если нужен более аккуратный вариант для фронтенда
Иногда имеет смысл убрать emoji только на публичной части сайта, а в админке ничего не менять. Тогда код можно ограничить фронтендом:
<?php
add_action( 'init', function () {
if ( is_admin() ) {
return;
}
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Такой подход удобен, если редакторы часто работают в админке и вы не хотите вмешиваться в служебные стили и скрипты там, где они могут быть полезны для совместимости.
Сравнение подходов
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в дочерней теме | Прозрачно, без лишних плагинов | Зависит от темы, при смене темы код нужно переносить |
| MU-плагин | Не слетает при обновлении темы, удобно для техподдержки | Нужно один раз создать файл вручную |
| Плагин оптимизации | Удобно, если уже используется для чистки фронтенда | Легко забыть, где именно включена настройка |
Если у вас уже стоит плагин для технической оптимизации, проверьте его настройки сначала. Но для точечной задачи код обычно надёжнее: он не зависит от интерфейса и не прячет логику в десятке галочек.
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по факту. Откройте HTML страницы и убедитесь, что в <head> больше нет emoji-скрипта и связанных inline-вставок. Затем проверьте несколько страниц: главную, запись, архив и страницу с комментариями, если они есть.
- в исходнике нет
wp-emoji-release.min.js; - в
headне выводится emoji detection script; - страницы открываются без ошибок в консоли;
- редактор записей и комментарии работают как раньше;
- эмодзи в тексте отображаются нормально.
Если вы используете кэш на уровне плагина или сервера, очистите его после правки. Иначе можно смотреть на старую версию HTML и сделать неверный вывод.
Частые ошибки и как их исправить
Код добавили, но скрипт остался
Чаще всего причина в том, что код вставили слишком поздно или не туда. remove_action() должен выполниться до того, как WordPress выведет head. Если вы добавили фрагмент в шаблон, который подключается после вывода хука, он не сработает. Перенесите код в functions.php дочерней темы или в MU-плагин.
Отключили всё подряд и сломали стили
Иногда вместе с emoji пытаются убрать вообще все стили из wp_head. Это плохая идея: можно задеть не только сервисные вставки, но и важные стили темы или плагинов. Убирайте только конкретные функции WordPress, а не весь хук целиком.
Проверяли без очистки кэша
Если сайт отдаётся через page cache, CDN или серверный кэш, старый HTML может сохраняться после правки. Очистите кэш на всех уровнях и сделайте повторную проверку в приватном окне.
Ожидали прирост скорости как от большой оптимизации
Отключение emoji — это точечная техническая чистка, а не магическая оптимизация. Она убирает лишний код, но не заменяет нормальную работу с изображениями, CSS, JS и кэшированием.
Что ещё можно почистить рядом с emoji
Если вы уже занялись технической гигиеной сайта, имеет смысл посмотреть на другие стандартные вставки WordPress, которые реально не нужны конкретному проекту. Но делать это нужно выборочно: сначала диагностировать, потом отключать, потом проверять.
- лишние версии скриптов и стилей, если тема их дублирует;
- ненужные мета-теги в
head; - служебные элементы, которые добавляют плагины без пользы для проекта;
- автоподключения, которые можно заменить точечным кодом.
Если нужен более широкий набор чисток без ручного кода, иногда удобнее использовать профильный инструмент вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wppartner.ru&utm_medium=article&utm_campaign=kak-otklyuchit-emojii-v-wordpress-i-ubrat-lishnie-skripty-iz-head. Но даже в этом случае полезно понимать, какой именно код вы отключаете и как это проверить вручную.
Практический чек-лист перед публикацией
- проверил исходный код страницы до правки;
- добавил код в дочернюю тему или MU-плагин;
- очистил кэш сайта и CDN;
- сверил HTML после правки;
- открыл несколько страниц и проверил консоль браузера;
- убедился, что эмодзи в контенте и комментариях отображаются нормально.
Если после этого emoji-скрипт всё ещё виден, значит отключение не дошло до нужного места или его переопределяет другой плагин. В таком случае ищите источник через список активных плагинов и проверку подключений в исходнике, а не добавляйте ещё один слой «оптимизации» поверх уже сломанной логики.