В WordPress поддержка emoji включена по умолчанию уже много лет. На современных браузерах она обычно не нужна, но сайт всё равно может грузить лишний inline-скрипт, а в некоторых конфигурациях — ещё и дополнительные стили. Это не катастрофа, но на проектах, где считают каждый запрос и чистят фронтенд от лишнего кода, такую мелочь имеет смысл убрать.
Ниже — рабочие способы отключить emoji без поломки контента, как проверить результат и где чаще всего ошибаются.
Когда отключение emoji действительно имеет смысл
Если сайт живёт на актуальных браузерах и вы не рассчитываете на старые клиенты, emoji-обвязка WordPress обычно не даёт практической пользы. Она может быть заметна в таких сценариях:
- нужно уменьшить количество запросов и размер HTML;
- вы приводите фронтенд к минимальному набору скриптов;
- на сайте есть строгая политика по сторонним вставкам и лишним inline-скриптам;
- вы чистите админку и фронтенд от неиспользуемых возможностей ядра.
Если у вас аудитория со старыми браузерами или специфическими устройствами, отключать поддержку стоит осознанно. Для большинства обычных сайтов это безопасно, но лучше понимать, что именно убираете.
Диагностика: что именно добавляет WordPress
Проверка простая: откройте исходный код страницы и найдите упоминания wp-emoji-release.min.js. В стандартной установке WordPress обычно подключает небольшой inline-скрипт, который проверяет поддержку emoji и при необходимости подгружает полифилл.
Ещё один способ — посмотреть список подключённых скриптов через инструменты разработчика в браузере или через плагины для анализа ассетов. Если на странице присутствует emoji-обвязка, вы увидите её в head или в списке JS-файлов.
Для быстрой проверки после отключения важно смотреть не только главную страницу, но и:
- записи и страницы с визуальным редактором;
- архивы и шаблоны таксономий;
- страницы с комментариями, если они включены;
- админку, если вы отключаете скрипт глобально.
Способ 1: отключить emoji кодом
Самый надёжный вариант — убрать стандартные действия WordPress через remove_action(). Этот способ не зависит от плагинов и подходит для дочерней темы или небольшого mu-plugin.
<?php
/**
* Отключает emoji в WordPress.
*/
function wpbit_disable_emojis() {
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' );
}
add_action( 'init', 'wpbit_disable_emojis' );Код можно добавить в functions.php дочерней темы. Если не хотите зависеть от темы, лучше оформить это как маленький mu-plugin в wp-content/mu-plugins/.
Если нужен более аккуратный вариант для mu-plugin
Создайте файл, например wp-content/mu-plugins/disable-emojis.php, и положите туда тот же код. Так настройка не исчезнет после смены темы и не потеряется при обновлении.
<?php
/**
* Plugin Name: Disable Emojis
*/
function wpbit_disable_emojis() {
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' );
}
add_action( 'init', 'wpbit_disable_emojis' );Способ 2: отключить через плагин чистки сайта
Если вы не хотите лезть в код, удобнее использовать плагин, который умеет отключать лишние функции ядра. Например, в Clearfy Pro есть настройки для чистки WordPress, где можно убрать emoji и другие необязательные элементы.
Плюс такого подхода — всё в одном интерфейсе. Минус — ещё один слой настроек и зависимость от плагина. Если у вас уже есть плагин для оптимизации, это нормально. Если нет, для одной задачи код обычно проще и прозрачнее.
| Подход | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Минимум зависимостей, предсказуемое поведение | Нужно аккуратно вносить изменения |
| Плагин оптимизации | Удобно для нескольких задач сразу | Дополнительный плагин и свои настройки |
Проверка результата после внедрения
После отключения emoji не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что WordPress действительно перестал выводить лишний код.
- Откройте исходный код страницы и найдите
wp-emoji-release.min.js. - Проверьте, что в
<head>больше нет emoji detection script. - Сравните количество запросов до и после в DevTools.
- Проверьте админку, если отключали скрипт и стили глобально.
Если используете кэш-плагин или серверный кэш, очистите его перед проверкой. Иначе можно смотреть на старую версию HTML и сделать ложный вывод, что ничего не изменилось.
Частые ошибки и как их исправить
Код добавили не туда
Если вставить решение в файл активной темы, оно может исчезнуть после обновления. Для постоянной настройки лучше использовать дочернюю тему или mu-plugin.
Отключили только один хук
Иногда убирают только wp_head, а админские стили или скрипты остаются. В результате emoji частично продолжают грузиться. Нужны все четыре удаления из примера выше.
Смотрят на страницу из кэша
После изменений браузер или серверный кэш может отдавать старую версию. Очистите кэш и проверьте страницу в режиме инкогнито или с отключённым кэшем DevTools.
Путают отключение emoji с отключением символов Unicode
Этот приём не ломает обычные символы и не запрещает вставлять emoji в контент. Он убирает только штатную поддержку старого механизма WordPress, который нужен не всем.
Что ещё имеет смысл проверить рядом с emoji
Если вы уже занимаетесь чисткой фронтенда, посмотрите и на другие стандартные элементы WordPress, которые могут быть не нужны конкретному проекту: wp-embed, лишние стили темы, неиспользуемые блоки редактора, тяжёлые иконки и дублирующиеся библиотеки. Но отключать всё подряд не стоит: сначала измерьте, потом меняйте.
- проверьте, не нужен ли
wp-embedдля встраивания контента; - сравните HTML до и после изменений;
- не удаляйте скрипты, если они используются сторонними плагинами;
- держите изменения в одном месте, чтобы было проще откатить.
Если задача — не просто убрать emoji, а системно почистить сайт от лишнего технического мусора, удобнее делать это по чек-листу: сначала диагностика, потом точечное отключение, затем повторная проверка исходника и запросов. Так проще не сломать то, что реально используется на сайте.