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

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

Задача здесь не в том, чтобы «сломать всё лишнее», а в том, чтобы отключить только то, что действительно не нужно на публичной части сайта, и при этом не задеть редактор, админку и совместимость с плагинами.

Когда это вообще имеет смысл

Отключение emoji-скриптов оправдано, если вы:

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

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

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

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

• скрипт wp-emoji-release.min.js;
• инлайн-скрипт с проверкой поддержки emoji;
• стили, связанные с emoji в старых версиях или в сторонних надстройках.

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

Как быстро проверить наличие emoji-кода

Самый простой способ — открыть страницу в браузере и найти emoji в исходнике. Если у вас есть доступ к серверу, можно также посмотреть HTML через curl:

curl -s https://example.com/ | grep -i emoji

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

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

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

Вариант 1: отключить 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: отключить только на фронтенде

<?php
add_action( 'init', function () {
    if ( is_admin() ) {
        return;
    }

    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );

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

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

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

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

После правки откройте главную страницу и несколько типовых внутренних страниц. Проверка должна быть не «на глаз», а по факту:

• в исходнике страницы больше нет wp-emoji-release.min.js;
• в <head> не выводится emoji detection script;
• страница не показывает ошибок JavaScript в консоли;
• редактор записей и админка продолжают работать как раньше.

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

Что проверить отдельно в браузере

Откройте:

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

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

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

Отключили не там, где нужно

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

Удалили emoji, но не проверили дубли

Иногда оптимизирующий плагин уже убрал emoji, а вы добавили ещё одно отключение. Это не критично, но усложняет поддержку: через полгода уже непонятно, какой именно слой отвечает за результат.

Сломали админку слишком агрессивной чисткой

Если вы убрали не только emoji, но и другие скрипты из wp_head или admin_print_scripts, можно задеть редактор, медиа-загрузчик или интерфейс плагинов. Не смешивайте отключение emoji с общей «чисткой всего подряд».

Проверяли только кэшированную страницу

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

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

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

Если вы ведёте несколько сайтов, держите такие мелкие оптимизации в одном небольшом служебном плагине, а не размазывайте их по теме. Так проще сопровождать и искать конфликты.

И ещё один полезный момент: не отключайте встроенные механизмы WordPress только потому, что они «лишние по ощущениям». Сначала проверьте, есть ли реальная нагрузка, дублирование или конфликт. В случае с emoji это обычно безопасная и понятная оптимизация, но принцип остаётся тем же: сначала диагностика, потом точечное изменение, потом проверка результата.