Как отключить лишние скрипты и стили WordPress на отдельных страницах

Автор: Марина Волкова | Опубликовано: 23.10.2026

Если сайт на WordPress тормозит только на части страниц, часто проблема не в теме и не в хостинге, а в лишних CSS и JS от плагинов, которые грузятся везде подряд. Их можно отключать точечно: не удаляя плагин, а убирая его assets только там, где они не нужны. Это нормальная практика для ускорения сайта, но делать её нужно аккуратно: сначала понять, что именно грузится, потом отключить только нужное и сразу проверить, не сломалась ли страница.

Что именно можно отключать и когда это имеет смысл

Под assets обычно имеют в виду стили CSS, скрипты JavaScript, а иногда и дополнительные шрифты, иконки или библиотеку вроде jQuery, если она подключена плагином отдельно. На практике чаще всего мешают:

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

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

Сначала выясните, что именно грузится

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

вкладка Network в DevTools браузера;
расширения для анализа загрузки страниц;
плагин Query Monitor, если нужен быстрый просмотр подключенных стилей и скриптов прямо в админке.

Ищите не только крупные файлы, но и те, что относятся к конкретному плагину по имени в URL или по handle. В WordPress отключение делается не по имени файла, а по идентификатору, под которым скрипт или стиль зарегистрирован. Это важный момент: путь к файлу и handle могут отличаться.

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

Самый надёжный способ: отключать через код на нужных страницах

Для точечного отключения в WordPress обычно используют хук wp_enqueue_scripts и функции wp_dequeue_script(), wp_dequeue_style(), а иногда ещё wp_deregister_script() и wp_deregister_style(). В большинстве случаев достаточно именно dequeue: он убирает уже подключенный asset с конкретной страницы, не ломая регистрацию для других мест сайта.

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

Пример: отключить скрипт и стиль только на странице с конкретным ID.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_page( 42 ) ) {
        wp_dequeue_script( 'plugin-script-handle' );
        wp_dequeue_style( 'plugin-style-handle' );
    }
}, 100 );

Здесь 42 — ID страницы, а plugin-script-handle и plugin-style-handle — реальные handle нужных файлов. Приоритет 100 нужен, чтобы код сработал после того, как плагин уже успел зарегистрировать и подключить свои assets.

Если нужно отключать не на одной странице, а на группе страниц, используйте условные теги WordPress:

add_action( 'wp_enqueue_scripts', function () {
    if ( is_page( array( 'contacts', 'about' ) ) ) {
        wp_dequeue_script( 'plugin-script-handle' );
    }
}, 100 );

Можно использовать и другие условия: is_front_page(), is_single(), is_archive(), is_category(). Логика простая: сначала определяете, где asset не нужен, потом убираете его только там.

Когда нужен wp_deregister_*

wp_dequeue_* убирает подключение на странице, а wp_deregister_* ещё и снимает регистрацию. Это уже более жёсткий шаг. Его используют реже, потому что можно случайно сломать зависимые скрипты или стили, если другой код рассчитывает на зарегистрированный handle.

Если задача — просто убрать файл с конкретной страницы, почти всегда начинайте с wp_dequeue_script() и wp_dequeue_style(). wp_deregister_* имеет смысл только когда вы точно понимаете зависимости и хотите полностью заменить или убрать регистрацию.

Как найти правильный handle скрипта или стиля

Самая частая ошибка — пытаться отключать файл по имени CSS или JS, хотя WordPress работает с handle. Есть несколько практичных способов узнать его:

посмотреть исходный код страницы и найти атрибуты id у подключенных файлов, например id="plugin-style-handle-css";
проверить документацию плагина, если разработчик указал handle;
временно вывести список подключенных assets через отладочный код или использовать Query Monitor.

Если в исходнике вы видите plugin-style-handle-css, то сам handle обычно будет plugin-style-handle. Для скриптов часто встречается похожая схема с суффиксом -js в HTML-идентификаторе, но в коде нужен именно зарегистрированный handle без лишних окончаний.

Когда handle неочевиден, не гадайте. Лучше один раз посмотреть список зарегистрированных скриптов и стилей, чем потом ловить сломанный фронтенд на продакшене.

Если плагин сам не даёт отключить assets, можно действовать точечно

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

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

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

Если плагин подключает файлы нестандартно, например напрямую через <script> или <link> без WordPress enqueue API, отключить их точечно сложнее. Тогда уже приходится смотреть в код плагина или использовать более грубые методы, но это отдельный сценарий и без понимания исходников лучше туда не лезть.

Как проверить, что отключение сработало и ничего не сломалось

После правки не ограничивайтесь визуальной проверкой. Откройте страницу в режиме инкогнито и проверьте три вещи:

в исходном коде больше нет нужного CSS или JS;
страница отображается без ошибок верстки и консоли браузера;
функция, ради которой плагин нужен, работает там, где должна работать.

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

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

Что чаще всего ломает точечное отключение

Есть несколько типичных ошибок, которые встречаются почти всегда:

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

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

Когда лучше не отключать вручную

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

Если же задача точечная — убрать один-два лишних скрипта на конкретных страницах — ручной способ через wp_dequeue_script() и wp_dequeue_style() обычно самый прозрачный и предсказуемый. Он не требует удалять плагин, не ломает админку и даёт контроль над тем, где именно грузится лишний код.

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