WordPress до сих пор добавляет в <head> и в админку служебные скрипты для поддержки emoji. На современных сайтах это часто лишняя нагрузка: отдельный JS-файл, дополнительные DNS-запросы, лишний код в шапке и еще один источник шума при аудите производительности. Если сайт работает на обычной русскоязычной аудитории и вы не рассчитываете на старые браузеры, этот функционал обычно можно отключить без заметных побочных эффектов.
Важно не путать отключение emoji с удалением всех скриптов из head. Здесь задача точечная: убрать именно встроенную поддержку emoji WordPress, не ломая редактор, комментарии и фронтенд.
Когда отключение emoji действительно имеет смысл
Сценарий простой: вы открываете исходный код страницы или отчет Lighthouse и видите wp-emoji-release.min.js, а также inline-скрипт, который проверяет поддержку emoji в браузере. Если сайт не использует старые браузеры и не зависит от этой совместимости, код можно убрать. Это особенно полезно на проектах, где уже вычищают лишние метатеги, отключают XML-RPC и приводят фронтенд к более предсказуемому виду.
Отключение оправдано, если:
- сайт ориентирован на современные браузеры;
- вы хотите уменьшить количество запросов на каждой странице;
- нужно убрать лишний inline-код из
headдля более чистой разметки; - вы ведете техническую оптимизацию и проверяете каждый внешний или встроенный ресурс.
Диагностика: где именно подключается emoji
Перед правкой лучше убедиться, что проблема действительно есть. Откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js или emoji-release.min.js. Еще один способ — посмотреть вкладку Network в DevTools и обновить страницу с отключенным кэшем.
Если emoji подключаются, вы обычно увидите:
- inline-скрипт в
headс проверкой canvas; - подключение
/wp-includes/js/wp-emoji-release.min.js; - аналогичный код в админке и редакторе.
На этом этапе полезно понять, где именно вы хотите убрать emoji: только на фронтенде или также в админке. Для большинства сайтов достаточно отключить их на публичной части, а в админке оставить стандартное поведение WordPress, если вы не хотите вмешиваться глубже.
Пошаговое решение без плагина
Самый надежный способ — добавить небольшой код в дочернюю тему или в собственный мини-плагин. Так вы не зависите от настроек темы и не теряете изменения при обновлении.
1. Отключите стандартные действия WordPress
Добавьте код в functions.php дочерней темы или в отдельный плагин:
<?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 применяет к контенту и письмам. Для большинства проектов этого достаточно.
2. Если нужен только фронтенд
Иногда админку трогать не хочется. Тогда можно ограничиться фронтендом:
<?php
add_action( 'init', function () {
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );Это более мягкий вариант. Он оставляет служебный код в админке, но убирает его с публичных страниц.
Плагин или код: что выбрать
Если у вас уже есть плагин для технической чистки сайта, можно использовать его настройки. Но если задача точечная и вы не хотите тащить лишнюю зависимость, код обычно надежнее. Ниже — практическое сравнение.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в дочерней теме | Контроль, минимум зависимостей, легко проверить | Нужно не забыть про обновления темы и резервную копию |
| Мини-плагин | Не зависит от темы, удобно переносить между сайтами | Нужен отдельный файл и базовая дисциплина в деплое |
| Плагин для оптимизации | Быстро включить без кода | Риск получить лишние функции вместе с одной нужной |
Если вы уже используете инструменты для чистки WordPress, например Clearfy Pro, проверьте, нет ли в нем отдельной опции отключения emoji. Но даже в этом случае полезно понимать, какой именно код убирается и как это проверить вручную.
Как проверить, что решение сработало
После внедрения откройте главную страницу и любую внутреннюю страницу в режиме инкогнито. Затем проверьте три вещи.
- В исходном коде больше нет
wp-emoji-release.min.js. - В
<head>исчез inline-скрипт emoji detection. - В Network не загружается файл
/wp-includes/js/wp-emoji-release.min.js.
Дополнительно можно проверить через консоль браузера, что на странице нет лишних запросов к этому файлу. Если используете кэш-плагин или серверный кэш, не забудьте очистить кэш перед проверкой — иначе вы увидите старую версию страницы и решите, что код не сработал.
Проверка в админке
Если вы отключали emoji и в админке, откройте редактор записей и убедитесь, что интерфейс не сломался. В современных версиях WordPress редактор Gutenberg работает нормально и без этой поддержки. Если же у вас старый сайт с нестандартными плагинами, проверьте комментарии, письма и формы, где могут использоваться символы emoji.
Частые ошибки и как их исправить
- Код добавили не туда. Если вставить его в файл темы, который не загружается на фронтенде, ничего не изменится. Надежнее использовать
functions.phpдочерней темы или мини-плагин. - Ожидали эффект без очистки кэша. Кэш страницы, CDN или плагин оптимизации могут отдавать старую версию HTML.
- Удалили слишком много. Если вместе с emoji отключили лишние фильтры вручную и задели другие хуки, могут пострадать письма или RSS.
- Смотрели только визуально. Скрипт может быть скрыт минификацией или объединением файлов. Проверяйте исходный код и Network, а не только внешний вид страницы.
Безопасность и производительность
С точки зрения безопасности отключение emoji не является защитной мерой. Это именно техническая оптимизация и чистка фронтенда. Но у нее есть практический плюс: меньше встроенного кода, проще аудит страницы, меньше шансов, что какой-то плагин или тема будут конфликтовать с лишними inline-скриптами.
Если вы ведете системную оптимизацию сайта, имеет смысл смотреть на такие вещи в связке: убрать дублирующиеся метаданные, отключить ненужные сервисные скрипты, проверить кэширование и только потом переходить к более тяжелым мерам. Так проще понять, что реально влияет на сайт, а что просто создает шум в отчетах.
Когда лучше не отключать emoji
Если сайт рассчитан на очень старые браузеры, корпоративные устройства с ограниченной средой или вы не контролируете фронтенд-код, лучше сначала протестировать отключение на staging. В редких случаях сторонняя тема или плагин могут неявно рассчитывать на стандартные скрипты WordPress. Это нечасто, но на старых проектах лучше проверить вручную.
Практика здесь простая: сначала отключение на тестовой копии, затем проверка страниц, комментариев, форм и редактора, и только после этого перенос на боевой сайт. Такой подход дешевле, чем откатывать изменения после того, как что-то сломалось на проде.