На живом сайте WordPress часто остаются мелкие технические хвосты, которые не дают заметного выигрыша по отдельности, но в сумме засоряют HTML и создают лишние запросы. Один из таких хвостов — встроенная поддержка emoji. Она добавляет в страницу дополнительные скрипты и стили, хотя большинству проектов это не нужно.
Если задача стоит практично — уменьшить количество лишних подключений без риска сломать админку и редактор, — лучше отключать emoji точечно и сразу проверить, что именно изменилось в исходнике страницы.
Когда отключение emoji действительно уместно
Эта настройка имеет смысл, если вы оптимизируете фронтенд и хотите убрать из кода страницы то, что не используется. В WordPress emoji-поддержка нужна в основном для старых браузеров и совместимости с некоторыми сценариями ввода. На большинстве современных сайтов она не критична.
Отключать её стоит, если:
- вы видите в
<head>подключениеwp-emoji-release.min.jsи лишний inline-скрипт; - нужно сократить количество запросов на страницах с высокой нагрузкой;
- вы чистите фронтенд после миграции темы или сборки кастомного шаблона;
- сайт работает в закрытой корпоративной среде, где поддержка старых браузеров не нужна.
Не стоит отключать emoji «на всякий случай», если у вас нет контроля над тем, как сайт используют редакторы и посетители. Это не опасная настройка, но её лучше делать осознанно и с проверкой результата.
Диагностика: что именно добавляет WordPress
Перед правкой полезно посмотреть исходный код страницы и убедиться, что проблема действительно в emoji, а не в теме или плагине оптимизации. Откройте главную страницу, найдите в HTML такие фрагменты:
<script type='text/javascript' src='https://example.com/wp-includes/js/wp-emoji-release.min.js?ver=6.x'></script>Иногда рядом есть и inline-блок, который подготавливает проверку поддержки emoji в браузере. Если у вас уже стоит кэш-плагин или оптимизатор, он может объединять скрипты, и тогда найти источник сложнее. В таком случае проще временно открыть страницу без минификации или посмотреть исходник в режиме инкогнито.
Ещё один полезный способ — проверить, не отключает ли emoji уже ваша тема или плагин. Если вы добавите собственный код поверх чужого решения, можно получить дублирующиеся фильтры и лишнюю путаницу при отладке.
Пошаговое решение через functions.php или мини-плагин
Самый надёжный путь — добавить небольшой код в дочернюю тему или в отдельный мини-плагин. Так вы не потеряете настройку после обновления темы.
Вариант 1: отключить emoji через фильтры WordPress
Этот способ убирает фронтенд- и админские подключения, а также связанные с ними фильтры. Код можно разместить в 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' );
} );На практике этого обычно достаточно. Код не трогает редактор как таковой, а только убирает автоматические подключения и преобразования emoji.
Вариант 2: сделать то же самое в отдельном плагине
Если вы не хотите привязывать оптимизацию к теме, создайте простой плагин, например disable-emoji.php в каталоге wp-content/plugins/:
<?php
/**
* Plugin Name: Disable Emoji
*/
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
Если вы уже чистите <head>, имеет смысл посмотреть на другие лишние элементы, но делать это аккуратно. Не все «оптимизационные советы» безопасны для каждого сайта.
| Подход | Что делает | Риск |
|---|---|---|
| Код в теме | Быстро убирает emoji без плагинов | Слетит при смене темы, если не дочерняя |
| Мини-плагин | Изолирует настройку от темы | Нужно не забыть активировать и хранить в коде |
| Плагин оптимизации | Может отключать emoji вместе с другими мелочами | Легко переборщить и сломать совместимость |
Если у вас уже используется плагин вроде Clearfy Pro, проверьте, не включена ли там аналогичная опция. Дублировать одно и то же отключение в двух местах не нужно: это не ускорит сайт, а только усложнит диагностику.
Проверка результата после внедрения
После добавления кода не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что WordPress действительно перестал выводить emoji-скрипты и стили.
- Откройте страницу сайта в режиме инкогнито.
- Посмотрите исходный код и найдите
wp-emoji-release.min.js. - Проверьте, исчез ли inline-скрипт, связанный с emoji.
- Откройте админку и убедитесь, что редактор и форма записи работают как обычно.
- Если есть кэш, очистите его и проверьте страницу ещё раз.
Если вы используете инструменты разработчика в браузере, можно дополнительно посмотреть вкладку Network и убедиться, что запрос к wp-emoji-release.min.js больше не уходит.
Частые ошибки и как их исправить
Код добавили не туда
Самая частая проблема — вставка в обычную тему вместо дочерней. После обновления тема перезапишется, и оптимизация исчезнет. Если проект уже в продакшене, лучше сразу вынести код в мини-плагин.
Проверили только кэшированную страницу
Иногда кэш-плагин продолжает отдавать старую версию HTML, и кажется, что ничего не изменилось. Очистите кэш плагина, серверный кэш и, если есть, CDN.
Смешали несколько решений
Если emoji отключается и в теме, и в плагине оптимизации, и отдельным кодом, отладка становится бессмысленной. Оставьте один источник правды. Для технической поддержки это сильно упрощает жизнь.
Удалили лишнее, но не проверили админку
Хотя отключение emoji обычно безопасно, после любых правок в functions.php нужно открыть админку, редактор записей и форму комментариев. Ошибка в коде или конфликт с другим хуком может проявиться не на фронтенде, а именно там.
Безопасность и производительность: что важно не упустить
Сама по себе эта оптимизация безопасна, если вы используете штатные хуки WordPress и не правите ядро. Но есть несколько практических правил:
- не редактируйте файлы ядра WordPress;
- храните изменения в дочерней теме или отдельном плагине;
- перед выкладкой на боевой сайт проверьте код на тестовой копии;
- не отключайте больше, чем понимаете: экономия на одном скрипте не оправдывает поломку совместимости;
- если сайт многоязычный или с активной редактурой, проверьте, как ведут себя комментарии и письма.
Если вам нужен более широкий набор технических отключений и чистка лишнего кода, такие задачи обычно удобнее закрывать через один инструмент, а не набор разрозненных сниппетов. Но даже в этом случае сначала смотрите, что именно меняется в HTML, а уже потом включайте опции массово.
В итоге задача сводится к простой проверке: если после отключения emoji исходник стал чище, лишний запрос исчез, а админка работает без побочных эффектов, настройка выполнена правильно.