Плагин формы подключает свои CSS и JavaScript на всех страницах, хотя форма есть только на странице контактов. Или слайдер загружается в статьях, где его нет. Чтобы уменьшить число лишних запросов, не обязательно удалять плагин или менять тему: обычно достаточно снять конкретные файлы с очереди WordPress на ненужных страницах.
Для этого используют функции wp_dequeue_script() и wp_dequeue_style(). Сначала нужно выяснить точные идентификаторы файлов (handles), затем добавить условие по странице и проверить, что необходимые функции сайта не сломались.
Сначала выясните, какие файлы можно отключить
Не удаляйте подключения только потому, что файл кажется крупным или его название связано с плагином. Он может обеспечивать меню, форму, галерею или другой элемент, который не сразу заметен на странице. Сравните несколько типов страниц и проверьте, где именно файл нужен.
Удобный способ найти идентификаторы подключений — открыть страницу в админ-панели с установленным плагином Query Monitor и посмотреть раздел со скриптами и стилями. В нём видны handles, источники файлов и, для скриптов, зависимости. Если Query Monitor использовать не хотите, проверьте вкладку Network в инструментах разработчика браузера: она покажет URL загружаемых CSS и JS, но обычно не даст сам handle WordPress. Его можно найти в коде плагина или темы рядом с вызовами wp_enqueue_script() и wp_enqueue_style().
Полезно составить короткую карту: файл, handle, где он подключается и на каких страницах действительно используется. Проверяйте не только главную и одну запись, но и шаблоны, где есть нужный компонент: страницу с формой, каталог, поиск или архив. Наличие файла в коде страницы ещё не означает, что его безопасно отключить.
Отключите подключение только на нужных страницах
Добавьте код в дочернюю тему или собственный небольшой плагин. Не редактируйте файлы родительской темы: её обновление может затереть изменения. В примере ниже замените contact-form-script и contact-form-style на handles, найденные на вашем сайте, а contacts — на слаг страницы, где нужна форма.
add_action( 'wp_enqueue_scripts', 'wpmy_dequeue_contact_assets', 100 );
function wpmy_dequeue_contact_assets() {
if ( ! is_page( 'contacts' ) ) {
wp_dequeue_script( 'contact-form-script' );
wp_dequeue_style( 'contact-form-style' );
}
}Этот вариант сохраняет файлы на странице контактов и снимает их с очереди на остальных страницах. Если нужная страница определяется надёжнее по ID, используйте, например, is_page( 42 ). Для главной страницы подойдёт is_front_page(), для отдельной записи — is_single(). Условные теги проверяйте внутри функции, вызванной на wp_enqueue_scripts: к этому моменту WordPress уже подготовил контекст текущей страницы.
При необходимости можно отключить несколько файлов или задать условие для определённой группы страниц. Например, если скрипт нужен только на странице контактов, его удобнее снимать именно на всех остальных страницах, как в примере. Так меньше риск забыть новый шаблон, на котором он тоже должен работать.
Когда лучше условно подключать файл, а не отключать его
Если вы управляете кодом, который добавляет ресурс, предпочтительнее подключать его только там, где он нужен. Например, собственный код формы может вызывать wp_enqueue_script() и wp_enqueue_style() после проверки условия для страницы. Тогда лишнее подключение вообще не попадает в очередь.
Снять с очереди файл плагина удобно, когда менять его настройки или код нельзя, а сам плагин не умеет ограничивать загрузку. Для сторонних плагинов такой способ проще внедрить, но он зависит от их handle и порядка выполнения хуков. После обновления плагина handle может измениться — в этом случае отключение перестанет работать. Если у плагина есть собственная настройка загрузки ресурсов по страницам, обычно лучше использовать её.
Не отключайте зависимости и общие ресурсы вслепую
Скрипты WordPress и плагинов могут зависеть друг от друга. Например, если оставленный на странице скрипт объявлен с зависимостью от другого файла, WordPress может загрузить эту зависимость при печати скриптов. Поэтому отключение одного handle не всегда удаляет ожидаемый запрос, а отключение общей библиотеки способно нарушить работу других компонентов. В Query Monitor проверьте зависимости и не снимайте с очереди базовые библиотеки, пока не убедились, что они нигде не нужны.
Стили тоже могут содержать правила сразу для нескольких элементов сайта, даже если handle принадлежит плагину с узкой функцией. После отключения проверьте страницу визуально: отсутствие ошибки в браузере не гарантирует, что разметка осталась оформленной правильно.
Учтите и время подключения. Приоритет 100 в примере нужен, чтобы функция отработала после обычных вызовов подключения на стандартном хуке. Если плагин добавляет ресурс позже, например на более высоком приоритете, код может сработать раньше него. В таком случае выясните, на каком хуке и с каким приоритетом плагин ставит файл в очередь, и выполните отключение после этого вызова. Не повышайте приоритет наугад: это может скрыть причину, но не гарантирует правильный порядок.
Как проверить результат и не сломать страницу
После изменения очистите кэш WordPress-плагина, сервера и CDN, если они используются. Оптимизаторы могут объединять, откладывать или переименовывать ресурсы, поэтому проверяйте результат на сайте без авторизации и в актуальной версии страницы, а не по закэшированной копии.
Откройте целевую страницу и несколько страниц, где ресурс отключён. В Network проверьте, что нужный запрос исчез там, где не требуется, и остался там, где нужен. В консоли браузера проверьте ошибки JavaScript. Затем протестируйте сам элемент: отправьте форму, откройте меню, проверьте переключатели или другой функционал, связанный с отключёнными файлами. Если он перестал работать, верните подключение и проверьте, не сняли ли вы общий ресурс или зависимость.
Результат оценивайте не только по количеству запросов: один удалённый файл не обязательно заметно ускорит сайт, если он небольшой или загружается после основного содержимого. Сравните загрузку одной и той же страницы до и после изменения в одинаковых условиях. Если запрос остаётся, проверьте handle, порядок хуков и кэш; возможно, ресурс добавляет другой компонент или оптимизатор.
Если отключение перестало работать
После обновления темы или плагина снова проверьте handles и зависимости. Также убедитесь, что условие соответствует странице: например, слаг в is_page() указан верно, а код исполняется на фронтенде. Для диагностики временно отключите объединение и отложенную загрузку скриптов в оптимизаторе — так легче увидеть исходные подключения. После проверки восстановите нужные настройки оптимизации.
Отключение ресурсов через очередь WordPress влияет на фронтенд и не удаляет файлы с сервера. Если приходится постоянно обходить загрузку ресурса, разумнее проверить настройки самого плагина: возможно, в нём есть штатное ограничение по страницам. Так изменение будет устойчивее к обновлениям и проще в сопровождении.