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

Автор: Дмитрий Сорокин | Опубликовано: 22.09.2026

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

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

Когда отключение emoji действительно имеет смысл

Речь не о «ускорении на глаз», а о точечной чистке. Отключать emoji стоит, если вы:

хотите убрать лишние запросы и inline-код из фронтенда;
поддерживаете современную аудиторию, где старые браузеры не критичны;
не используете плагины или тему, которые завязаны на старую emoji-совместимость;
хотите сократить шум в исходном коде при аудите производительности.

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

Диагностика: что именно добавляет WordPress

Проверка начинается с исходного кода страницы. Откройте главную или любую запись и найдите в <head> подключение wp-emoji-release.min.js. Иногда рядом будет inline-функция, которая подготавливает загрузку emoji. Это и есть стандартная поддержка WordPress.

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

wp-emoji-release.min.js

Если строка есть, WordPress еще не отключен на уровне темы или плагинов.

Что важно проверить до изменений

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

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

Самый прозрачный вариант — добавить небольшой код в functions.php дочерней темы или в mu-plugin. Для продакшена mu-plugin даже удобнее: код не потеряется при смене темы.

Ниже рабочий вариант, который отключает стандартные emoji-скрипты, стили и фильтры:

<?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' );
    remove_filter( 'the_content', 'wp_staticize_emoji' );
    remove_filter( 'comment_text', 'wp_staticize_emoji' );
} );

Этот код отключает не только фронтенд, но и связанные преобразования в контенте, комментариях и письмах. Если вам нужно убрать только фронтенд-часть, а в админке оставить как есть, можно ограничиться wp_head и wp_print_styles.

Если нужен только фронтенд

<?php
add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );

Такой вариант подходит, если вы не хотите трогать поведение в админке и письмах. Но в большинстве случаев полный вариант чище и предсказуемее.

Альтернатива: отключение через плагин

Если на сайте уже есть плагин для технической чистки, удобнее держать такие настройки в одном месте. Например, в Clearfy Pro есть инструменты для удаления лишних элементов WordPress без ручного кода. Это полезно, когда вы ведете несколько сайтов и не хотите размазывать одинаковые сниппеты по темам.

Но у плагина есть компромисс: меньше ручной поддержки, больше зависимость от интерфейса и набора опций. Для разработчика, который контролирует код, mu-plugin обычно надежнее.

Подход	Плюсы	Минусы
Код в mu-plugin	Прозрачно, быстро, не зависит от темы	Нужно следить за обновлениями и конфликтами
functions.php	Просто внедрить на одном сайте	Потеряется при смене темы
Плагин	Удобно для нескольких сайтов и неразработчиков	Дополнительная зависимость и слой настроек

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

После внедрения не ограничивайтесь визуальной проверкой. Нужны три конкретных шага:

Откройте страницу в режиме инкогнито и посмотрите исходный код.
Убедитесь, что wp-emoji-release.min.js больше не загружается.
Очистите кэш страницы, кэш браузера и кэш CDN, если он есть.

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

Для быстрой проверки можно использовать поиск по исходнику:

wp-emoji-release.min.js
emoji

Если строка исчезла, а консоль чистая, задача выполнена.

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

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

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

Кэш не очищен

Это самая частая причина ложного вывода «не работает». WordPress уже отдал старую версию HTML, а вы смотрите на закэшированную страницу. Сбрасывайте кэш плагина, сервера и CDN.

Отключили не все фильтры

Если убрать только wp_head, но оставить статические emoji-фильтры, часть преобразований останется в письмах, RSS или комментариях. Для полного отключения используйте полный набор remove_action/remove_filter.

Конфликт с плагином оптимизации

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

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

Не редактируйте ядро WordPress. Любые изменения должны жить в теме, дочерней теме или mu-plugin. Так вы не потеряете правки после обновления.

Если на сайте много технических правок, держите их в отдельном mu-plugin-файле с понятным названием. Это проще сопровождать, чем разносить по шаблонам темы. Для сайтов, где уже используется набор оптимизаций, удобно собрать все подобные настройки в одном месте — так проще искать причину конфликта.

проверяйте изменения на staging-копии;
после правки смотрите HTML, а не только визуальный результат;
не отключайте то, что реально нужно внешним сервисам или старым клиентам;
фиксируйте изменения в репозитории, если сайт под Git.

Если задача не ограничивается emoji и вы регулярно чистите WordPress от лишнего технического шума, имеет смысл смотреть на комплексные инструменты вроде Clearfy Pro: там можно централизованно управлять несколькими подобными отключениями, а не держать десятки разрозненных сниппетов.