Как отключить emoji в WordPress через code snippets и убрать лишние скрипты

WordPress по умолчанию подгружает небольшие скрипты и стили для поддержки emoji. На современных сайтах это часто не нужно: лишние запросы, лишний код в <head> и внизу страницы, а иногда — просто мусор в отчётах по производительности. Если задача именно в том, чтобы убрать эти элементы аккуратно, без правки ядра и без побочных эффектов, лучше сделать это через код, а не через случайный плагин «для оптимизации всего подряд».

Ниже разберём рабочий сценарий: как понять, что emoji-скрипты действительно загружаются, как отключить их безопасно, чем отличается решение через код от плагина, и как проверить результат после внедрения.

Когда это вообще имеет смысл

Отключать emoji-обвязку стоит не «ради галочки», а когда вы уже смотрите на технический хвост сайта и видите, что WordPress добавляет лишние подключения без пользы для проекта. Это особенно заметно на сайтах с жёсткой дисциплиной по фронтенду: минимальное число запросов, чистый <head>, контроль над тем, что реально грузится в публичной части.

Типичные признаки:

  • в исходном коде есть подключение wp-emoji-release.min.js;
  • в <head> или перед закрывающим </body> видны inline-скрипты, связанные с emoji;
  • в Lighthouse/Pagespeed это не главный провал, но код всё равно висит как лишний;
  • на сайте уже используется собственная политика оптимизации скриптов, и этот кусок нужно привести к общему стандарту.

Диагностика: как понять, что именно грузит WordPress

Сначала проверьте исходный код страницы. Откройте главную или любую публичную страницу и найдите по тексту emoji или wp-emoji-release. Если WordPress не отключал поддержку, вы увидите примерно такой фрагмент:

<script src="https://s.w.org/images/core/emoji/14.0.0/svg/"></script>

На разных версиях WordPress и в разных браузерах набор вставок может отличаться, но суть одна: ядро добавляет служебные куски для emoji-совместимости. Если вы видите их на всех страницах, значит отключение имеет смысл именно на уровне сайта, а не отдельной темы.

Дополнительно проверьте:

  • не подключает ли тему или плагин собственные emoji-скрипты отдельно от ядра;
  • не маскируется ли проблема под кэш: после правки старый HTML может ещё отдаваться из кеша;
  • не используете ли вы редактор или интеграцию, где emoji реально нужны в админке — публичную часть можно чистить, не ломая редактор.

Пошаговое решение через functions.php или mu-plugin

Самый надёжный вариант — отключить emoji-функции ядра через стандартные хуки WordPress. Это не требует стороннего плагина и не трогает ядро. Если у вас есть child theme, код можно положить в functions.php. Для более устойчивого решения лучше использовать mu-plugin, чтобы отключение не зависело от темы.

Вариант 1: код в 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' );
} );

Этот набор убирает не только фронтенд-часть, но и связанные фильтры. Для большинства сайтов этого достаточно. Важно: не вставляйте код в произвольный плагин оптимизации, если не понимаете, что он уже делает с wp_head и скриптами — можно получить дублирующее отключение или конфликт с другими фильтрами.

Вариант 2: mu-plugin, если нужно не зависеть от темы

Создайте файл, например wp-content/mu-plugins/disable-emojis.php. Если папки mu-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' );
} );

Плюс этого подхода в том, что отключение переживёт смену темы. Это удобно, если вы ведёте несколько сайтов с одинаковой технической политикой.

Плагин или код: что выбрать

Если у вас уже есть плагин, который умеет отключать emoji вместе с другими мелкими оптимизациями, это может быть удобнее. Но для точечной задачи код обычно надёжнее: меньше зависимостей, меньше риска, что обновление плагина поменяет поведение сайта.

ПодходПлюсыМинусыКогда брать
Код в functions.phpБыстро, прозрачно, без лишних зависимостейЗависит от темыЕсли у вас есть child theme и вы контролируете код
mu-pluginНе зависит от темы, легко переноситсяНужно один раз правильно развернуть файлЕсли отключение должно жить отдельно от темы
Плагин оптимизацииУдобно, если уже используется для других задачМожет тащить лишние функции и настройкиЕсли нужен не только emoji, но и другой технический тюнинг

Если вы уже используете комплексную оптимизацию, можно посмотреть на Clearfy Pro, но только если вам действительно нужны и другие функции чистки сайта. Для одной задачи код обычно проще и предсказуемее.

Как проверить, что решение сработало

Проверка должна быть не на глаз, а по факту в HTML и сетевых запросах.

  1. Откройте страницу сайта в браузере.
  2. Посмотрите исходный код страницы и найдите emoji или wp-emoji-release.
  3. Откройте DevTools → Network и обновите страницу с выключенным кэшем.
  4. Убедитесь, что запросов к emoji-скриптам больше нет.
  5. Если стоит кэш-плагин или серверный кэш, очистите его и проверьте ещё раз.

Если у вас есть доступ к WP-CLI, можно хотя бы быстро проверить, что код не сломал сайт после деплоя: откройте главную страницу и несколько типовых шаблонов, а затем сравните исходный HTML до и после. Для этой задачи важнее не «цифра в отчёте», а отсутствие конкретных вставок.

Частые ошибки и как их исправить

Код добавили не туда

Самая частая ошибка — вставить отключение в активную тему, а потом забыть, что после обновления или смены темы всё вернётся. Если решение должно жить долго, используйте child theme или mu-plugin.

Проверяли без очистки кэша

Если сайт отдаётся через page cache, старый HTML может ещё содержать emoji-скрипты. После правки всегда очищайте кэш плагина, серверный кэш и, если нужно, CDN.

Отключили всё подряд и сломали админку

Иногда пытаются вырезать emoji через грубые правки в wp_head или через фильтрацию HTML-вывода. Это плохая идея: можно задеть не только фронтенд, но и редактор, письма, RSS. Используйте штатные хуки WordPress, а не поиск-замену по HTML.

Смешали несколько оптимизационных плагинов

Если один плагин уже отключает emoji, а второй делает то же самое, это обычно не критично, но диагностику усложняет. В итоге непонятно, что именно сработало, а что нет. Для технической чистки лучше держать один ответственный слой оптимизации.

Практические советы по безопасности и поддержке

Не редактируйте ядро WordPress и не правьте файлы в wp-includes. Любое обновление всё перезатрёт, а вы получите нестабильный сайт. Для точечных изменений используйте только поддерживаемые точки расширения: хуки, mu-plugins, child theme.

Если на сайте несколько разработчиков, вынесите такие отключения в отдельный файл с коротким комментарием, зачем он нужен. Это экономит время на ревью и снижает шанс, что кто-то удалит код как «непонятный мусор».

И ещё один практический момент: отключение emoji — это мелкая оптимизация, а не универсальное ускорение. Если у вас тяжёлые изображения, лишние шрифты, неагрессивный кэш или перегруженная тема, эффект от этой правки будет ограниченным. Но как часть общей чистки сайта она вполне оправдана.

Если нужно убрать не только emoji, но и другие мелкие дубли

Когда задача выходит за рамки одной функции и вы хотите системно чистить WordPress от лишних скриптов, мета-тегов и дублей, удобнее собирать это в одном месте, а не разбрасывать по теме и нескольким плагинам. В таких сценариях полезно сначала зафиксировать список того, что реально нужно сайту, а потом уже отключать лишнее по одному пункту и проверять результат после каждого изменения.

⭐⭐⭐⭐⭐