Плагин формы, галереи или слайдера может подключать свои CSS- и JavaScript-файлы на всём сайте, хотя используется только в одном месте. Удалить такие ресурсы можно условно: оставить их на нужной странице, а на остальных убрать из очереди загрузки WordPress. Для этого обычно достаточно функций wp_dequeue_style() и wp_dequeue_script() — переписывать тему не требуется.
Сначала выясните, какие именно файлы лишние и какие страницы от них зависят. Затем добавьте условие на фронтенд сайта и проверьте не только отсутствие файлов в запросах браузера, но и работу страницы после изменений.
Как определить, какие ресурсы можно отключить
Не ориентируйтесь только на размер страницы или название файла. Один и тот же скрипт может обслуживать несколько функций, а файл с непонятным именем — быть необходимым для меню, формы или блока темы. Перед отключением установите связь между файлом, WordPress handle (идентификатором ресурса) и компонентом сайта.
Удобнее всего посмотреть список стилей и скриптов в Query Monitor: откройте страницу сайта, войдите в админ-панель и найдите соответствующие панели Scripts и Styles. В них обычно видны handle и источник ресурса. В исходном HTML идентификатор часто можно заметить в атрибуте id у тега <script> или <link>, например some-handle-js или some-handle-css. Это подсказка, но при сомнениях сверяйте handle с Query Monitor.
В инструментах разработчика браузера на вкладке Network проверьте, на каких страницах запрашивается файл и что перестаёт работать при его отсутствии. Сравните страницы, где компонент используется, и где его нет. Если файл загружается со стороннего сервиса или вставлен темой напрямую в HTML, он может не управляться очередью WordPress — обычный вызов wp_dequeue_script() тогда его не удалит.
Отключение скрипта и стиля через условие страницы
Добавьте код в дочернюю тему или собственный небольшой плагин. Не вносите его в файлы родительской темы: после обновления изменения могут пропасть. В примере ниже ресурсы формы остаются на странице с адресом /contacts/, а на остальных страницах сайта удаляются. Замените демонстрационные handle на идентификаторы из своего сайта.
<?php
add_action( 'wp_enqueue_scripts', 'site_unload_contact_form_assets', 100 );
function site_unload_contact_form_assets() {
if ( is_page( 'contacts' ) ) {
return;
}
wp_dequeue_style( 'contact-form-style' );
wp_dequeue_script( 'contact-form-script' );
}Хук wp_enqueue_scripts предназначен для подключения ресурсов на фронтенде. Приоритет 100 позволяет выполнить удаление после большинства стандартных вызовов подключения, но не гарантирует, что любой плагин не поставит ресурс в очередь позже. Если файл продолжает загружаться, проверьте Query Monitor и настройки самого плагина: возможно, он добавляет ресурс на другом хуке или с более поздним приоритетом.
Условие is_page( 'contacts' ) проверяет страницу по её slug. Можно использовать числовой ID: is_page( 123 ). Для набора страниц передают массив, например is_page( array( 123, 456 ) ). Другие полезные проверки — is_front_page() для главной страницы и is_singular( 'post' ) для отдельных записей. Условные теги следует проверять внутри хука, когда WordPress уже определил текущий запрос, а не при загрузке файла с кодом.
Если ресурс нужен только на одной странице, логика может быть обратной: выйдите из функции на этой странице, а на остальных удаляйте файл, как в примере. Для нескольких мест использования перечислите их в условии. Не подменяйте точную проверку страницы поиском по URL в строке: условные теги WordPress надёжнее учитывают тип текущей страницы.
Почему файл может не исчезнуть после dequeue
wp_dequeue_style() и wp_dequeue_script() убирают зарегистрированный ресурс из очереди на вывод. Они не удаляют файл с сервера и не отключают функцию плагина. Для обычной условной разгрузки этого достаточно; вызывать wp_deregister_style() или wp_deregister_script() обычно не нужно. Отмена регистрации может повлиять на другие компоненты, которые рассчитывают на этот handle.
У скриптов есть зависимости. Если другой скрипт требует ресурс, который вы удалили, WordPress может подключить зависимость при обработке оставшегося скрипта; кроме того, сам компонент может перестать работать из-за отсутствия нужной библиотеки. Поэтому не удаляйте наугад общие ресурсы вроде jQuery или скриптов темы. Сначала выясните, какие файлы зависят от выбранного handle, и проверяйте работу каждой функции, которая может его использовать.
Если запрос остаётся в Network, возможны несколько причин: выбран не тот handle, ресурс ставится в очередь позже, файл выводится напрямую или его повторно добавляет оптимизирующий плагин. При прямом выводе нужно найти место подключения в теме или плагине и использовать предусмотренную ими настройку. Попытка удалить тег регулярным выражением из готовой HTML-страницы ненадёжна: она не управляет зависимостями WordPress и может повредить разметку.
Как проверить результат и избежать побочных эффектов
После добавления кода очистите кэш страницы, если сайт использует кэширование, и откройте нужные адреса в приватном окне браузера. На страницах, где ресурс не нужен, проверьте его отсутствие во вкладке Network; на странице с формой — убедитесь, что стили и скрипты остались. Если включена сборка или объединение CSS и JavaScript, очистите также её кэш: оптимизатор может показывать объединённый файл, в котором исходные ресурсы уже невозможно сопоставить напрямую.
Проверьте интерактивные элементы, а не только внешний вид первого экрана: отправку форм, раскрытие меню, модальные окна, карусели и блоки, загружаемые после прокрутки. После изменения страницы может потребоваться очистить кэш плагина, CDN и браузера — конкретные действия зависят от настроек вашего хостинга и сайта.
Если после отключения перестала работать функция, удалите соответствующий вызов dequeue и повторите проверку. Если файл остался, вернитесь к его handle и моменту подключения, а не добавляйте всё более общий код для удаления ресурсов. Условное отключение должно опираться на конкретный компонент и конкретные страницы: так проще сохранить нужные функции и понять, откуда возникла проблема.