На WordPress часто копится лишняя нагрузка не из-за одной «тяжёлой» темы, а из-за десятка мелких подключений: стили плагинов на всех страницах, скрипты форм на главной, библиотека иконок, которая нужна только в админке, и дублирующиеся CSS-файлы от темы и конструктора. В итоге страдают не только метрики, но и поддержка: любой апдейт может снова включить то, что вы уже отключали.
Ниже — рабочий сценарий: как сначала найти источник, потом отключить его точечно и проверить, что ничего не сломалось. Без выдуманных хуков и без магии.
Когда проблема действительно в лишних скриптах и стилях
Не стоит начинать с удаления всего подряд. Сначала убедитесь, что проблема именно в фронтенд-загрузках, а не в медленном сервере, тяжёлых запросах к базе или внешнем API. Обычно лишние CSS/JS видно по таким признакам:
- на страницах загружаются файлы плагина, хотя его блоков или виджетов там нет;
- один и тот же функционал подключается дважды разными плагинами;
- в
headи в конце страницы есть скрипты, которые не используются на текущем шаблоне; - после отключения конкретного плагина страница визуально не меняется, но список запросов заметно сокращается;
- в отчёте Lighthouse или WebPageTest много ресурсов, которые не участвуют в первом экране.
Как быстро найти источник
Откройте страницу в браузере и посмотрите список загрузок в DevTools. Вкладка Network показывает, какой файл пришёл с какого плагина или темы. Для CSS и JS удобно фильтровать по расширениям .css и .js. Если имя файла неочевидно, ищите путь в URL: /wp-content/plugins/ или /wp-content/themes/.
Ещё полезно временно отключить кэш-плагин и проверить страницу в режиме инкогнито. Иногда кажется, что файл «не уходит», но на деле его просто отдаёт кэш.
Что отключать: сравнение подходов
Есть три нормальных пути: отключать через код, использовать плагин для управления активными ассетами или оставить всё как есть и только минимизировать. Выбор зависит от того, кто будет поддерживать сайт дальше.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Код в теме или mu-plugin | Нужно точечно убрать 1–5 файлов | Контроль и предсказуемость | Нужно понимать, где и как подключён файл |
| Плагин управления ассетами | Много страниц и много плагинов | Удобно тестировать без правки кода | Появляется ещё один слой логики |
| Минификация и объединение | Файлы нужны, но их можно оптимизировать | Меньше запросов | Не решает проблему лишней загрузки |
Если задача — убрать именно ненужные ресурсы, а не просто сжать их, лучше идти через точечное отключение. Минификация полезна только после того, как вы убрали лишнее.
Пошаговое решение через код
Самый надёжный способ — отключать скрипты и стили на конкретных страницах через wp_dequeue_script() и wp_dequeue_style(). Делать это лучше в дочерней теме или в небольшом mu-plugin, чтобы изменения не потерялись при обновлении темы.
Шаг 1. Найдите handle ресурса
В WordPress отключение работает не по имени файла, а по handle — тому имени, под которым стиль или скрипт был зарегистрирован. Его можно найти в коде темы/плагина или через вывод зарегистрированных ассетов. Если у вас есть доступ к исходникам, ищите вызовы wp_enqueue_script() и wp_enqueue_style().
<?php
add_action( 'wp_enqueue_scripts', function () {
// Пример: отключаем скрипт контактной формы только на страницах, где формы нет.
if ( ! is_page( array( 'contacts', 'support' ) ) ) {
wp_dequeue_script( 'contact-form-7' );
wp_deregister_script( 'contact-form-7' );
}
}, 100 );Здесь важно два момента. Во-первых, приоритет 100 нужен, чтобы код сработал после того, как тема и плагины уже подключили свои файлы. Во-вторых, wp_deregister_script() используйте осторожно: если другой плагин ожидает этот handle, можно получить побочный эффект. Во многих случаях достаточно только wp_dequeue_script().
Шаг 2. Отключайте только там, где ресурс не нужен
Не делайте глобальное отключение на всём сайте, если файл нужен хотя бы на одной странице. Для этого и существуют условные теги WordPress.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( is_front_page() ) {
wp_dequeue_style( 'swiper' );
wp_dequeue_script( 'swiper' );
}
}, 100 );Этот пример уместен, если слайдер на главной не используется. Но если он есть в первом экране, отключать его нельзя: визуально сайт сломается, а проблема производительности просто сменится на проблему функциональности.
Шаг 3. Уберите лишнее из админки, если оно там не нужно
Иногда ресурсы грузятся не только на фронтенде, но и в админке. Для этого есть отдельный хук admin_enqueue_scripts. Например, если плагин добавляет тяжёлый скрипт на все экраны админки, а нужен только на странице настроек, можно ограничить его загрузку.
<?php
add_action( 'admin_enqueue_scripts', function ( $hook_suffix ) {
if ( 'settings_page_my-plugin' !== $hook_suffix ) {
wp_dequeue_script( 'my-plugin-admin' );
wp_dequeue_style( 'my-plugin-admin' );
}
}, 100 );Такой подход особенно полезен для сайтов, где редакторы работают в админке каждый день. Лишние ресурсы там тоже влияют на скорость и удобство.
Диагностика перед отключением
Перед тем как править код, зафиксируйте исходное состояние. Иначе потом будет сложно понять, что именно помогло.
- Сделайте копию файла
functions.phpили вынесите код в отдельный mu-plugin. - Проверьте страницу в приватном окне без авторизации.
- Сравните список запросов до и после изменения.
- Очистите кэш плагина, серверный кэш и CDN, если он есть.
- Проверьте не только главную, но и запись, страницу, архив и шаблон с формой.
Если используете плагин для анализа ассетов, отключайте только один ресурс за раз. Иначе вы не поймёте, какой именно файл вызвал проблему.
Проверка результата после внедрения
После отключения ресурса нужно проверить не только скорость, но и функциональность. Рабочий чек выглядит так:
- страница открывается без ошибок в консоли браузера;
- формы отправляются, если они должны работать на этой странице;
- меню, слайдеры, табы и модальные окна не потеряли стили;
- в
Networkбольше не видно отключённого файла; - кэш очищен, и вы смотрите не старую версию страницы.
Если после отключения что-то сломалось, верните ресурс обратно и проверьте, не был ли он нужен зависимому скрипту. Частая ситуация: вы отключили библиотеку, а тема всё ещё вызывает код, который на ней построен.
Частые ошибки и как их исправить
Отключают по имени файла, а не по handle
WordPress не понимает путь к файлу как аргумент для wp_dequeue_script(). Нужен handle, который был указан при регистрации. Если handle неизвестен, ищите его в коде темы или плагина.
Ставят слишком ранний приоритет
Если код срабатывает до того, как ресурс зарегистрирован, отключение не сработает. В большинстве случаев безопасно использовать приоритет 100 или выше для wp_enqueue_scripts.
Удаляют файл глобально, хотя он нужен на части страниц
Это самая дорогая ошибка. Сайт может выглядеть нормально на главной, но сломаться на странице контактов, в блоге или в архиве. Всегда проверяйте сценарии, где ресурс реально используется.
Не очищают кэш после правки
Без очистки кэша можно решить, что код не работает, хотя браузер или CDN отдают старую версию. Это особенно заметно на сайтах с агрессивным page cache.
Практические советы по безопасности и производительности
Если вы вносите такие правки на живом сайте, не редактируйте основной шаблон напрямую. Лучше использовать дочернюю тему или mu-plugin в wp-content/mu-plugins/. Тогда обновление темы не затрёт изменения.
Для массовой оптимизации удобно сначала посмотреть, какие файлы реально добавляет тема. Если задача шире, чем одно-два отключения, имеет смысл использовать инструменты вроде Clearfy Pro: он помогает убирать часть лишних подключений и дублирующих элементов без ручного поиска каждого handle. Но даже с таким плагином полезно понимать, что именно вы отключаете и на какой странице.
Ещё один рабочий приём — не трогать всё сразу. Сначала уберите самый очевидный лишний ресурс, потом проверьте сайт, затем переходите к следующему. Так проще отследить регрессии и не получить «оптимизированный», но сломанный шаблон.
Что делать, если ресурс подключает сам плагин
Если файл добавляет плагин, а не тема, сначала проверьте настройки самого плагина. Иногда у него уже есть опция отключения фронтенд-ассетов или загрузки только на нужных типах страниц. Это безопаснее, чем жёстко вырезать файл кодом.
Если настроек нет, тогда уже используйте точечное отключение через хуки WordPress. Но перед этим убедитесь, что плагин не использует этот же handle для критичной логики. Для форм, слайдеров, галерей и редакторских блоков это особенно важно.
В рабочем проекте такой порядок обычно самый надёжный: сначала диагностика, потом настройка плагина, затем кодовое отключение, и только после этого — проверка на реальных страницах. Именно так можно убрать лишние CSS и JS без сюрпризов на продакшене.