Если сайт на WordPress давно живёт в продакшене, в шапке часто остаются мелкие, но лишние подключения: emoji-скрипты, DNS-prefetch, embed-скрипт, иногда ещё и автоподгрузка oEmbed. По отдельности это не катастрофа, но на длинной дистанции такие вещи засоряют HTML, мешают контролировать фронтенд и усложняют аудит производительности.
Ниже разберём конкретный сценарий: как отключить emoji в WordPress, убрать связанные с ними скрипты и проверить, что ничего не сломалось в редакторе, комментариях и админке.
Когда это вообще нужно
Отключать emoji имеет смысл, если вы хотите сократить количество запросов и убрать лишний inline-код из <head>. На современных браузерах emoji и так отображаются без помощи WordPress, а старый fallback-скрипт чаще всего уже не нужен.
Но есть важная оговорка: отключать нужно только фронтенд-часть. В админке и редакторе лучше не трогать то, что отвечает за совместимость интерфейса, если вы не уверены в последствиях. На практике достаточно убрать стандартные подключения WordPress на публичной части сайта.
Диагностика: что именно подключается лишним
Перед правкой кода откройте исходный HTML страницы и проверьте, есть ли там типичные следы emoji-механизма WordPress:
wp-emoji-release.min.jsв<head>;- inline-скрипт с проверкой поддержки canvas;
- дополнительные фильтры на
emojiв HTML-выводе; - лишние DNS-prefetch, если вы чистите шапку комплексно.
Проверять удобнее не глазами в браузере, а через просмотр исходника или DevTools. Если у вас включён кеш, очистите его перед проверкой, иначе можно смотреть на старую версию страницы и сделать неверный вывод.
Что искать в исходнике
Откройте страницу и найдите по строке wp-emoji-release. Если скрипт есть, значит WordPress по умолчанию всё ещё добавляет emoji-поддержку. Это нормальное поведение, но для части проектов оно лишнее.
Решение: отключаем emoji через functions.php или мини-плагин
Самый безопасный способ — добавить код в дочернюю тему или в небольшой 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 на фронтенде и часть связанных фильтров. Если вам нужно отключить только шапку сайта, а админку оставить как есть, можно ограничиться удалением действий из wp_head и стилей на фронте. Но в большинстве случаев проще и чище убрать всё стандартное поведение, если проект не зависит от старых браузеров.
Если нужен более точечный вариант
Иногда полезно отключить 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' );
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' );
} );Такой подход удобен, если редакторы работают в админке на старых корпоративных устройствах или если вы не хотите вмешиваться в интерфейс больше, чем нужно.
Сравнение подходов: плагин, код, компромисс
| Подход | Что даёт | Минус |
|---|---|---|
| Код в теме или mu-plugin | Полный контроль, минимум лишнего | Нужно аккуратно сопровождать при обновлениях |
| Оптимизационный плагин | Можно отключить несколько мелких вещей сразу | Легко переборщить и сломать совместимость |
| Ничего не делать | Ноль риска для текущей конфигурации | Лишний код остаётся в шапке и в RSS |
Если у вас уже стоит плагин для чистки WordPress, например Clearfy Pro, проверьте, не дублируете ли вы одну и ту же настройку кодом и интерфейсом плагина. Двойное отключение обычно не ломает сайт, но потом сложнее понять, откуда именно пришёл эффект.
Как проверить результат после внедрения
После добавления кода сделайте проверку по шагам:
- Очистите кеш сайта, серверный кеш и кеш браузера.
- Откройте исходный код главной страницы и любой внутренней страницы.
- Убедитесь, что
wp-emoji-release.min.jsбольше не выводится. - Проверьте админку: редактор записей, комментарии, экран медиафайлов.
- Откройте RSS-ленту, если она используется, и посмотрите, не изменилось ли отображение текста.
Если после отключения emoji в тексте всё ещё появляются странные символы, проблема, скорее всего, не в WordPress emoji-механизме. Тогда нужно смотреть кодировку базы, шаблон темы или источник контента.
Быстрая проверка через поиск по исходнику
Можно просто открыть страницу и выполнить поиск по строке emoji. Если ничего не найдено, но в шапке всё ещё есть лишние скрипты, значит вы убрали только часть проблемы и стоит проверить другие подключения, например wp-embed или DNS-prefetch.
Частые ошибки и как их исправить
- Удалили код из темы, а не из дочерней темы или mu-plugin. После обновления всё вернётся обратно. Перенесите правку в место, которое не перезаписывается.
- Отключили emoji через плагин и через код одновременно. Это не критично, но мешает диагностике. Оставьте один источник правды.
- Проверили только главную страницу. На внутренних страницах и в RSS могут быть другие условия вывода. Тестируйте несколько шаблонов.
- Сразу начали отключать всё подряд в
wp_head. Так легко задеть важные вещи: canonical, стили темы, oEmbed, REST API discovery. Убирайте только то, что понимаете.
Что ещё можно убрать рядом, если цель — чистая шапка
Если задача не ограничивается emoji, обычно рядом смотрят и на другие стандартные подключения WordPress: wp-embed, лишние rel=shortlink, некоторые meta-теги и автоподгрузку ресурсов, которые не нужны конкретному проекту. Но здесь важно не превращать оптимизацию в «выключим всё». Любое удаление из wp_head должно быть проверяемым: сначала нашли, потом отключили, потом сравнили исходник и поведение сайта.
Практичный порядок такой: сначала убрать очевидно лишнее, затем прогнать страницу через PageSpeed или WebPageTest, а уже потом решать, есть ли смысл в более глубокой чистке. Если нужен более широкий набор настроек без ручной возни, иногда удобнее использовать специализированный плагин для технической оптимизации, но только если вы понимаете, какие опции он меняет.
Безопасность и производительность: на что смотреть после правки
Отключение emoji само по себе не ускорит сайт радикально, но это хороший тест на дисциплину фронтенда. Если вы уже полезли в functions.php, проверьте рядом ещё три вещи:
- нет ли дублирующихся подключений скриптов от темы и плагинов;
- не выводится ли в шапке лишний inline-CSS;
- не ломается ли кеширование из-за динамических вставок в
head.
Для безопасности важно не вставлять такой код в случайный сниппет-плагин без понимания, как он хранит изменения и кто имеет к нему доступ. Если на сайте несколько администраторов, лучше держать технические правки в отдельном mu-plugin с понятным названием и комментарием, что именно отключено и зачем.
В итоге задача сводится не к «выключить emoji ради галочки», а к контролируемой чистке стандартных подключений WordPress. Это маленькая правка, но она хорошо показывает, насколько у вас управляем фронтенд и насколько аккуратно вы работаете с базовыми хуками.