На небольшом сайте это почти незаметно, а на живом проекте быстро превращается в проблему: на странице контактов грузится слайдер, на лендинге — стили формы из другой вёрстки, в статье — скрипты галереи, которой там нет. Обычно это не «лишний плагин», а точечная загрузка ассетов, которую можно убрать без глобального отключения плагина или темы.
Ниже — рабочий сценарий: как понять, что именно грузится, как отключить стили и скрипты только на нужных страницах и как проверить, что после правки не сломались формы, меню и редактор.
Когда это действительно проблема
Сначала стоит убедиться, что речь не о нормальной зависимости. Иногда скрипт подключается не потому, что он нужен на странице, а потому, что плагин не умеет разделять фронтенд по контексту. Это типично для:
- форм обратной связи с масками, валидацией и календарями;
- галерей и lightbox-скриптов;
- виджетов, которые выводятся только в одном шаблоне, но регистрируются глобально;
- блоков Gutenberg, которые тянут свои стили на весь сайт;
- старых тем, где ассеты подключаются через
wp_enqueue_scriptsбез проверки текущего шаблона.
Диагностика: что именно грузится лишним
Откройте проблемную страницу в браузере и посмотрите список CSS/JS в DevTools. Вкладка Network покажет, какие файлы реально уходят в запросы. Если нужен более быстрый способ, используйте просмотр исходного HTML и ищите имена файлов по названию плагина или темы.
На стороне WordPress полезно временно включить отладку и проверить, не подключает ли файл сам плагин через хук wp_enqueue_scripts. Если файл нужен только на одной странице, а грузится везде, это уже кандидат на точечное отключение.
Как отключить скрипт или стиль только на нужной странице
Самый надёжный путь — не править плагин, а снять его ассеты в дочерней теме или в небольшом mu-plugin. Так обновления не сотрут изменения.
Ниже пример для случая, когда на странице с ID 42 не нужен скрипт и стиль плагина. Хэндлы нужно взять из кода плагина или из списка подключённых файлов в HTML.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 42 ) ) {
return;
}
wp_dequeue_script( 'plugin-gallery' );
wp_dequeue_style( 'plugin-gallery' );
wp_deregister_script( 'plugin-gallery' );
wp_deregister_style( 'plugin-gallery' );
}, 100 );Здесь важен приоритет 100: сначала должны отработать подключения плагина, и только потом можно их снять. Если поставить слишком ранний приоритет, WordPress просто не увидит, что именно нужно убрать.
Если нужно отключать по шаблону или типу записи
Иногда удобнее ориентироваться не на ID страницы, а на шаблон или тип записи. Это особенно полезно, если у вас несколько лендингов с одинаковой структурой.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_singular( 'landing' ) ) {
return;
}
wp_dequeue_script( 'slider-library' );
wp_dequeue_style( 'slider-library' );
}, 100 );Если ассет нужен только в админке или только в блоке, не пытайтесь отключать его глобально наугад. Сначала проверьте, где он регистрируется: на фронтенде, в редакторе или в обоих местах.
Сравнение подходов: плагин, код, компромисс
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Настройки плагина | Если у плагина есть отдельное отключение ассетов | Без кода, проще сопровождать | Редко бывает достаточно точным |
Код через wp_dequeue_* | Если нужно убрать конкретный файл на конкретной странице | Точно, прозрачно, не зависит от UI | Нужно знать хэндл и место подключения |
| Замена плагина или блока | Если ассеты тянутся избыточно по архитектуре | Может дать лучший результат на длинной дистанции | Требует тестирования и миграции |
Как найти хэндл, если он не очевиден
Частая ситуация: в HTML виден файл /wp-content/plugins/example/assets/js/front.js, но хэндл неизвестен. Тогда смотрите исходники плагина и ищите wp_enqueue_script или wp_register_script. Хэндл — это первый аргумент функции.
Пример типичной регистрации:
<?php
wp_register_script(
'example-front',
plugins_url( 'assets/js/front.js', __FILE__ ),
array( 'jquery' ),
'1.0.0',
true
);В этом случае отключать нужно именно example-front, а не имя файла. Это частая ошибка: разработчик пытается снять ассет по URL, а WordPress работает с хэндлами.
Пошаговое решение без поломки сайта
- Определите страницу, где ассет не нужен.
- Найдите хэндл скрипта или стиля в исходниках плагина или темы.
- Добавьте отключение в дочернюю тему или mu-plugin.
- Проверьте страницу в приватном окне без кэша.
- Откройте консоль браузера и убедитесь, что нет ошибок JavaScript.
- Проверьте формы, меню, слайдеры и блоки, которые зависят от этого ассета.
Если нужно убрать ассеты у блока Gutenberg
У некоторых блоков стили подключаются только когда блок реально присутствует в контенте, но на старых сайтах это работает неидеально. Если блок используется только в одном шаблоне, можно дополнительно ограничить его вывод на уровне шаблона или заменить блок на более лёгкий аналог. Это лучше, чем вырезать стили «вслепую» и потом ловить сломанный вид на других страницах.
Как проверить, что решение сработало
Проверка должна быть не визуальной «на глаз», а технической. После правки откройте страницу и убедитесь в трёх вещах:
- файл больше не приходит в Network;
- в исходном HTML нет тега
<script>или<link>для отключённого ассета; - в консоли нет ошибок, связанных с удалённой библиотекой.
Если на странице есть форма, отправьте тестовый запрос. Если есть меню или модальное окно — проверьте открытие и закрытие. Иногда ассет кажется лишним, но на деле он нужен для одного маленького поведения, которое заметно только после клика.
Частые ошибки и как их исправить
Отключают не тот хэндл
Это самая частая причина, почему код «не работает». Файл может называться front.js, а хэндл — plugin-front-scripts. Смотрите именно регистрацию, а не имя файла.
Ставят слишком ранний приоритет
Если wp_dequeue_script() вызывается до того, как ассет зарегистрирован, WordPress ничего не снимет. Для фронтенда обычно безопаснее использовать приоритет 100.
Пытаются отключить всё сразу
Удаление целой библиотеки ради одной страницы часто ломает зависимые функции. Лучше убрать только конкретный файл и только там, где он не нужен.
Правят сам плагин
Такой способ быстро ломается после обновления. Если нет другого выхода, лучше вынести правку в отдельный слой: дочернюю тему или mu-plugin.
Безопасность и производительность
Точечное отключение ассетов полезно не только для скорости. Чем меньше лишнего JS и CSS на странице, тем меньше шанс конфликта между плагинами и тем проще отлаживать ошибки. Но не стоит превращать это в ручную войну с каждым файлом: если ассеты подключаются хаотично, иногда выгоднее пересмотреть архитектуру шаблона или заменить тяжёлый плагин на более узкое решение.
Если вы ведёте несколько проектов и часто чистите дубли, лишние стили и скрипты, имеет смысл держать под рукой инструмент для технической оптимизации вроде Clearfy Pro: в нём удобно отключать часть стандартного мусора и управлять отдельными настройками без постоянного редактирования темы. Но даже с таким инструментом логику подключения ассетов всё равно нужно понимать — иначе легко отключить то, что реально используется.
Для ручной проверки можно использовать и простой чек-лист:
- ассет отключён только на нужной странице;
- форма, меню и интерактивные элементы работают;
- кэш очищен после правки;
- изменения вынесены не в основной файл темы, а в отдельный слой;
- после обновления плагина код не затёрся.
Если задача повторяется на нескольких страницах, лучше собрать условия в один аккуратный блок и документировать, почему именно этот хэндл отключён. Через пару месяцев это сэкономит время при следующем аудите сайта.