Как убрать лишние скрипты в WordPress: пошаговая инструкция

За 30–60 минут вы сможете найти лишние JavaScript-файлы на страницах WordPress, определить плагин или тему, которая их добавляет, и отключить загрузку точечно. Инструкция рассчитана на WordPress 6.x, доступ к панели администратора и файлам сайта; перед изменениями нужен тестовый стенд или резервная копия.

Что подготовить до начала

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

• резервную копию файлов и базы данных;
• тестовую копию сайта или хотя бы возможность быстро откатить изменение;
• доступ администратора WordPress;
• доступ к файлам темы через хостинг, SFTP или Git;
• Chrome или другой браузер с инструментами разработчика;
• список важных сценариев: открытие меню, отправка формы, добавление товара в корзину, оформление заказа.

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

Шаг 1. Найдите страницы и скрипты с проблемой

Откройте страницу в Chrome, нажмите F12 и перейдите на вкладку Network. Включите фильтр JS, обновите страницу и отсортируйте запросы по размеру или времени загрузки. Смотрите не только на большие файлы: лишний скрипт на одной странице может весить мало, но запускать дополнительные запросы и обработчики.

Проверьте минимум четыре типа страниц:

1. главную;
2. страницу записи или товара;
3. архив или каталог;
4. контактную страницу и страницу оформления заказа, если они есть.

Для каждого подозрительного файла запишите полный URL, размер, время загрузки и страницу, где он встречается. URL часто подсказывает источник: в нём могут быть названия плагина, темы или каталога wp-includes.

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

Шаг 2. Узнайте WordPress handle скрипта

WordPress не управляет файлами только по их имени. При добавлении JavaScript разработчик назначает ему внутренний идентификатор — handle*. Именно его нужно передать функции отключения.

Быстрее всего handle ищется через плагин Query Monitor: в его панели откройте раздел со скриптами и найдите нужный файл. Если ставить дополнительный плагин нельзя, временно добавьте диагностический код в отдельный mu-плагин.

Создайте файл wp-content/mu-plugins/list-enqueued-scripts.php. Если каталога mu-plugins нет, создайте его. Код рассчитан на WordPress 6.x:

<?php
add_action('wp_print_scripts', function () {
    if (!is_user_logged_in() || !current_user_can('manage_options')) {
        return;
    }

    $scripts = wp_scripts();
    error_log('Enqueued scripts: ' . implode(', ', $scripts->queue));
}, 100);

Включите запись журнала WordPress только на тестовом сайте, обновите нужную страницу и посмотрите файл wp-content/debug.log. Для этого в конфигурации WordPress должны быть включены WP_DEBUG и WP_DEBUG_LOG. После поиска удалите диагностический файл и отключите отладку на рабочем сайте.

Проверка результата: в журнале появилась строка с handle, например contact-form-7, comment-reply или другим идентификатором. Сопоставьте его с URL из вкладки Network, потому что на странице могут быть несколько файлов одного плагина.

*Handle — внутреннее имя ресурса в очереди WordPress. Это не обязательно имя JavaScript-файла и не всегда совпадает с названием плагина.

Шаг 3. Определите, где скрипт действительно нужен

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

• Формы требуют не только своего JavaScript, но иногда и зависимостей.
• WooCommerce может загружать скрипты для корзины, фильтров, вариаций и оформления заказа.
• Скрипты редактора и админской части не стоит отключать наугад: код для посетителей и код для панели управления подключаются в разных контекстах.
• Код аналитики, рекламы и чата может добавляться не через очередь WordPress. Тогда wp_dequeue_script() его не удалит.

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

Шаг 4. Отключите скрипт на конкретной странице

Для WordPress 6.x используйте хук wp_enqueue_scripts. Отключение выполняйте с поздним приоритетом, чтобы код сработал после большинства плагинов. Сохраните фрагмент в дочерней теме или в собственном небольшом плагине.

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

    // Укажите handle, найденный в Query Monitor или debug.log.
    wp_dequeue_script('YOUR_SCRIPT_HANDLE');
    wp_deregister_script('YOUR_SCRIPT_HANDLE');
}, 100);

Замените contact на slug нужной страницы, а YOUR_SCRIPT_HANDLE — на реальный handle. В коде нельзя оставлять условие без проверки: например, глобальное отключение скрипта формы может сломать все формы на сайте.

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

Проверка результата: в Network нужный JavaScript больше не загружается на выбранной странице, но продолжает загружаться там, где он нужен. После этого проверьте меню, формы, интерактивные блоки и консоль браузера.

Шаг 5. Проверьте результат не только в браузере

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

Сравните до и после:

• количество JavaScript-запросов;
• объём переданных данных;
• ошибки в Console;
• время появления основного содержимого;
• работу форм, меню, фильтров, корзины и оплаты.

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

Цель — не получить страницу без JavaScript, а загружать каждый сценарий только там, где он нужен, и не оплачивать его лишними байтами на остальных страницах.

Если не получилось

Скрипт всё ещё виден в Network

Проверьте handle, приоритет хука и кеш. Если файл приходит с внешнего домена или вставлен непосредственно в HTML, его добавляет не очередь WordPress. Ищите источник в настройках темы, плагина, Google Tag Manager или коде шаблона.

После отключения появилась ошибка в Console

Верните изменение и посмотрите текст ошибки. Сообщения вроде Uncaught ReferenceError или is not a function обычно означают, что удалённая библиотека была зависимостью другого скрипта. Отключите только дополнительный файл или отмените правку.

Пропала форма или перестала работать корзина

Верните скрипт, очистите кеш и проверьте страницу в приватном окне. Для WooCommerce и плагинов форм тестируйте не только внешний вид, но и отправку данных, валидацию и переход на следующий шаг.

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

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

Что сделать дальше

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

Инвалидация кеша, объединение и отложенная загрузка скриптов — отдельные задачи. Сначала убедитесь, что каждый оставшийся файл действительно нужен, и только потом меняйте порядок его выполнения.