Как отключить emoji в WordPress без лишнего кода и побочных эффектов

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

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

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

Если у вас обычный сайт на актуальной версии WordPress, emoji-поддержка почти всегда не критична. Но она становится лишней, когда:

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

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

Диагностика: что именно загружает WordPress

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

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

вкладка Network — ищите запрос к wp-emoji-release.min.js;
вкладка Elements — проверьте, есть ли inline-скрипт, связанный с emoji;
если у вас кэш-плагин, сравните исходник страницы до и после очистки кэша.

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

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

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

Вариант 1: отключить emoji на фронтенде и в админке

Этот вариант убирает стандартные действия WordPress, которые подключают 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' );
} );

Код рабочий, но есть нюанс: он убирает только стандартную загрузку emoji. Если какой-то плагин отдельно подключает похожий скрипт, его нужно искать уже по месту.

Вариант 2: мини-плагин для аккуратного отключения

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

Для небольших правок это удобнее, чем держать код в functions.php, особенно если тема часто обновляется или вы работаете с несколькими сайтами.

Сравнение подходов: плагин, код, компромисс

Подход	Плюсы	Минусы	Когда брать
Код в дочерней теме	Просто, прозрачно, без лишних зависимостей	Слетит при смене темы, если забыть про child theme	Если у вас уже есть дочерняя тема и доступ к коду
mu-plugin	Не зависит от темы, легко переносится	Нужно один раз правильно создать файл	Если ведёте несколько сайтов или хотите стабильность
Плагин оптимизации	Можно отключить рядом с другими мелкими оптимизациями	Легко потерять контроль, если настроек слишком много	Если у вас уже стоит плагин для чистки фронтенда

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

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

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

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

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

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

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

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

Отключили только фронтенд

Иногда убирают emoji только через wp_head, но забывают про админку. В результате в панели управления скрипт остаётся, а в отчётах по оптимизации вы видите неполную картину. Если цель — полная чистка, удаляйте и admin_print_scripts, и стили.

Не очистили кэш

После правки страница может продолжать отдавать старый HTML из кэша. Это особенно заметно на сайтах с CDN. Сначала очищайте кэш, потом проверяйте исходник.

Путают emoji и шрифты

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

Безопасность и производительность: что учесть

С точки зрения безопасности отключение emoji нейтрально. Но любая правка через код требует аккуратности: одна лишняя скобка в functions.php может сломать сайт. Поэтому для продакшена лучше использовать mu-plugin или хотя бы делать изменения через staging.

С точки зрения производительности эффект небольшой, но предсказуемый: вы убираете лишний JS и CSS, а значит уменьшаете шум в исходнике. На больших проектах такие мелкие правки полезны именно в сумме, когда вы последовательно убираете всё ненужное.

Практический чек-лист перед публикацией

Проверить, нужен ли emoji-скрипт именно вашему проекту.
Добавить код в дочернюю тему или mu-plugin.
Очистить кэш на сайте и в CDN.
Сравнить исходный код страницы до и после.
Проверить админку и редактор записей.
Убедиться, что другие плагины не возвращают emoji обратно.

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