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

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

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

Когда это действительно нужно

Сценарий обычно один и тот же: вы открываете исходный код страницы, видите wp-emoji-release.min.js, лишние DNS-prefetch, старые стили плагина, который уже удалён, или скрипты, которые грузятся на всех страницах, хотя нужны только в одной форме или на странице контактов. Если сайт медленный не из-за одного большого файла, а из-за набора мелких «хвостов», чистка даёт более предсказуемый эффект, чем попытка ускорить всё сразу.

Что стоит проверить до правки

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

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

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

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

Пошаговое решение

1. Отключить emoji-скрипты WordPress

Самый безопасный способ — убрать фронтенд-часть emoji через functions.php дочерней темы или через собственный мини-плагин. Это не трогает редактор в админке и не вмешивается в работу контента.

<?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' );
} );

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

2. Убрать лишние ресурсы только на тех страницах, где они не нужны

Если плагин подключает скрипт на весь сайт, но нужен только на одной странице, используйте wp_dequeue_script() и wp_dequeue_style() с проверкой контекста. Важно сначала узнать правильный handle ресурса — его видно в коде плагина или через отладочные инструменты.

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( is_page( 'contact' ) ) {
        return;
    }

    wp_dequeue_script( 'contact-form-7' );
    wp_dequeue_style( 'contact-form-7' );
}, 100 );

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

3. Если нужен более чистый контроль — вынести правки в мини-плагин

Для проекта с несколькими правками лучше не держать всё в functions.php. Мини-плагин проще отключить, перенести между темами и проверить отдельно.

<?php
/**
 * Plugin Name: WP Cleanup Tweaks
 */

add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
} );

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

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

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

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

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

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

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

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

Отключили не тот handle

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

Сломали админку или редактор

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

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

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

Отключили ресурс, который нужен на части страниц

Такое часто случается с формами, галереями и виджетами. Если скрипт нужен только на одной странице, не удаляйте его глобально. Используйте условия is_page(), is_singular() или проверку шаблона, если она уместна в проекте.

Что делать, если нужна более глубокая чистка

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

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

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

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

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