Как отключить Emojis в WordPress без поломки верстки и лишних запросов

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

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

Когда отключение Emojis вообще имеет смысл

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

Отключение имеет смысл, если:

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

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

Диагностика: как понять, что WordPress действительно грузит emoji

Самый простой способ — открыть исходный код страницы и поискать wp-emoji-release.min.js или строку с emoji в подключениях. Второй вариант — посмотреть вкладку Network в DevTools и отфильтровать запросы по слову emoji.

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

Что именно искать в коде страницы

• wp-emoji-release.min.js в списке скриптов;
• inline-скрипт с проверкой поддержки emoji;
• подключение emoji-стилей, если они добавлены темой или плагином;
• следы фильтров в wp_head и admin_print_scripts.

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

Самый надежный способ — отключить emoji-функции через remove_action() и remove_filter(). Лучше не править ядро и не удалять файлы вручную: после обновления WordPress всё вернется обратно.

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

<?php
/**
 * Disable WordPress 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-скрипты и стили в публичной части и убирает преобразование emoji в RSS и email. Для большинства сайтов этого достаточно.

Если нужно оставить emoji в админке, а убрать только на фронтенде, код можно упростить:

<?php
add_action('init', function () {
    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');
});

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

Если удобнее через плагин: когда это оправдано

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

Если у вас уже есть плагин для технической чистки сайта, не стоит ставить отдельный мини-плагин только ради одной опции. Но если проект живет на кастомном коде, кодовый вариант обычно чище.

Проверка результата после внедрения

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

1. Откройте страницу сайта в режиме инкогнито.
2. Посмотрите исходный код и найдите wp-emoji-release.min.js.
3. Проверьте вкладку Network: запросов с emoji быть не должно.
4. Откройте админку и убедитесь, что редактор работает штатно.
5. Если на сайте есть RSS-лента или email-уведомления, проверьте их на тестовом примере.

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

Что считать нормальным результатом

• в исходнике нет emoji-скрипта;
• в Network не появляется отдельный запрос на emoji-файл;
• контент с обычными символами отображается без изменений;
• админка не теряет базовую функциональность редактора.

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

Ошибка 1: код вставили в тему, а потом обновили или сменили её. В результате отключение пропадает. Решение — перенести код в дочернюю тему или mu-plugin.

Ошибка 2: удалили только один remove_action() и забыли про фильтры RSS/email. Тогда часть emoji-логики остается в системе, и вы получаете неполное отключение. Проверьте весь набор хуков, а не только фронтенд.

Ошибка 3: очистили не тот кэш. На сайте с несколькими уровнями кэширования изменения могут не проявиться сразу. Сначала сбросьте кэш плагина, потом серверный кэш, потом CDN, если он есть.

Ошибка 4: отключили emoji в админке и получили неожиданные проблемы в редакторе. Такое бывает редко, но если у вас нестандартная сборка плагинов или старый стек, лучше оставить админку нетронутой и убрать только фронтенд.

Ошибка 5: проверяют только визуально. Страница может выглядеть одинаково, но лишний скрипт всё еще грузится. Проверяйте именно исходник и Network.

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

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

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

И главное: не отключайте то, что не проверяли на своем стеке. Если проект старый, с нестандартной темой или набором плагинов, сначала прогоните изменения на staging-копии. Это дешевле, чем потом искать, почему перестали работать письма или редактор.