Если PageSpeed ругается на лишние CSS и JavaScript, это обычно не значит, что на сайте лежит один «плохой файл». Чаще проблема в том, что тема, плагины и сторонние виджеты подключают свои стили и скрипты на всех страницах, хотя нужны они только в отдельных местах. Задача здесь не в том, чтобы удалить всё подряд, а в том, чтобы понять, что реально используется, и аккуратно отключить лишнее там, где оно не нужно.
Ниже — рабочий порядок действий: как найти неиспользуемые CSS и JS, как проверить, можно ли их убрать, и как сделать это без риска сломать фронтенд.
С чего начать: не удалять, а сначала найти источник
В WordPress почти никогда не имеет смысла искать «лишний CSS» вручную в исходниках темы. Сначала нужно понять, какой именно файл или библиотека грузится, кто её подключает и на каких страницах она реально нужна. Один и тот же файл может быть полезен на одной странице и бесполезен на другой.
Самый практичный сценарий такой:
- Открываете проблемную страницу в Chrome или Edge.
- Запускаете Lighthouse или проверяете отчёт PageSpeed Insights.
- Смотрите, какие CSS и JS отмечены как unused, render-blocking или excessive.
- Проверяете, откуда именно они приходят: тема, плагин, встроенный виджет, CDN, аналитика.
Важно не путать «неиспользуемый на этой странице» и «неиспользуемый вообще». Например, библиотека слайдера может быть нужна только на главной, а на внутренних страницах — нет. В таком случае правильное решение не удалять файл из сайта целиком, а отключать его загрузку там, где он не нужен.
Как определить, что именно можно убрать
Для CSS и JS полезно смотреть не только на отчёт PageSpeed, но и на реальное поведение страницы. Инструменты показывают, что код загружен, но не всегда точно объясняют, нужен ли он для интерактивных элементов, которые появляются после клика, открытия меню или прокрутки.
Проверка через DevTools
Откройте страницу, затем в браузере откройте DevTools и используйте вкладку Coverage. Она показывает, какой процент CSS и JS был использован при загрузке и во время взаимодействия со страницей. Это удобный способ увидеть крупные «пустые» файлы, но результат нужно интерпретировать осторожно: если вы не нажимали на меню, не открывали модальное окно и не запускали слайдер, часть кода может считаться неиспользованной, хотя на деле она нужна.
Практически полезно смотреть на такие признаки:
- файл подключён на всех страницах, но относится к одному блоку или шаблону;
- скрипт нужен только в админке, а грузится на фронтенде;
- стили плагина видны на страницах, где плагин не используется;
- библиотека дублирует функциональность уже подключённой версии.
Проверка через исходный код и список подключений
Если у вас есть доступ к коду сайта, проще всего смотреть, какие файлы подключаются через WordPress-хуки wp_enqueue_scripts и admin_enqueue_scripts. Именно там обычно регистрируются CSS и JS темы и плагинов. Важно понимать: файл может быть подключён корректно, но без условий. Тогда он грузится везде, хотя нужен только на части страниц.
Если вы работаете с темой или дочерней темой, ищите вызовы wp_enqueue_style() и wp_enqueue_script(). По ним можно понять handle файла, путь и зависимости. Это пригодится, когда вы будете отключать конкретный скрипт или стиль.
Безопасный способ убрать лишний CSS и JS в WordPress
Самая частая ошибка — удалять файлы из темы или плагина напрямую. Так делать не стоит: обновление всё вернёт обратно, а иногда сайт сломается сразу после удаления зависимости. Безопасный подход — не трогать исходный плагин, а отключать его подключение на уровне WordPress или через настройки оптимизации.
Вариант 1. Отключить загрузку на уровне кода
Если вы понимаете, какой именно файл лишний, его можно снять с очереди через wp_dequeue_style() или wp_dequeue_script(). Делать это лучше в дочерней теме или в небольшом кастомном плагине, а не в файлах родительской темы.
Пример: если плагин подключает скрипт на всех страницах, но он нужен только на конкретной странице, можно убрать его на остальных. Сначала нужно узнать handle скрипта. Затем добавить код в functions.php дочерней темы или в свой плагин:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_script( 'plugin-script-handle' );
wp_deregister_script( 'plugin-script-handle' );
}
}, 100 );Здесь plugin-script-handle — это не имя файла, а handle, под которым скрипт зарегистрирован в WordPress. Если handle указан неверно, код ничего не отключит. Поэтому сначала нужно посмотреть регистрацию ресурса в теме или плагине.
Для стилей логика та же:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_page( 'contact' ) ) {
wp_dequeue_style( 'plugin-style-handle' );
wp_deregister_style( 'plugin-style-handle' );
}
}, 100 );Не используйте этот способ вслепую для критичных файлов темы. Если отключить основной CSS темы или зависимость библиотеки, можно получить «голую» страницу или сломанный интерфейс.
Вариант 2. Отключать по условиям, а не полностью
Во многих случаях правильнее не удалять файл, а ограничить его загрузку по условиям: на страницах с формой, в блоге, в каталоге, на странице оформления заказа и так далее. Это особенно полезно для:
- слайдеров и галерей;
- форм обратной связи;
- календарей, карт, чатов;
- блоков, которые используются только в одной части сайта;
- скриптов аналитики и маркетинговых виджетов, если они не нужны везде.
Такой подход обычно даёт лучший баланс между скоростью и стабильностью. Вы не ломаете функциональность, а просто перестаёте грузить лишнее там, где оно не используется.
Вариант 3. Использовать плагин для управления ассетами
Если вы не хотите править код, удобнее использовать плагин, который позволяет отключать CSS и JS по страницам. Для владельца сайта это часто самый безопасный путь: видно, что именно подключено, и можно точечно выключать ресурсы без редактирования темы. Но здесь тоже нужна аккуратность: отключение «на глаз» легко ломает верстку или интерактив.
Подход с плагином особенно удобен, когда на сайте много сторонних расширений и нужно быстро проверить, какой ресурс реально лишний. Но после теста лучше всё равно зафиксировать решение в коде или в понятной настройке, чтобы не зависеть от случайных изменений.
Как проверить, что вы ничего не сломали
После отключения CSS или JS не ограничивайтесь одной главной страницей. Проверяйте те шаблоны, где код мог быть нужен:
- главная;
- записи блога;
- страницы с формами;
- страницы с галереями, слайдерами, табами, аккордеонами;
- страница 404;
- страницы, где есть виджеты или вставки от сторонних сервисов.
Смотрите на три вещи: не сломалась ли верстка, работают ли клики и анимации, исчезли ли ошибки в консоли браузера. Если после отключения скрипта в консоли появились ошибки вида is not defined или cannot read properties of undefined, значит, вы убрали зависимость, которая ещё используется.
Полезно повторно прогнать PageSpeed или Lighthouse после изменений. Это покажет, уменьшился ли объём CSS и JS и не появились ли новые проблемы с рендерингом. Но не гонитесь только за цифрой: иногда удаление небольшого файла даёт мало пользы, если при этом ломается важный блок сайта.
Что обычно мешает убрать лишний код
На практике проблемы повторяются почти на каждом проекте. Самые частые из них такие:
- код подключён не тем плагином, который кажется на первый взгляд, а ядром темы или конструктором;
- ресурс нужен только на части страниц, но без условий грузится везде;
- скрипт зависит от другой библиотеки, и при отключении рушится цепочка зависимостей;
- оптимизатор уже объединяет или откладывает загрузку, и поверх него добавляют ещё одно отключение;
- файл кажется лишним в отчёте PageSpeed, но реально нужен для взаимодействия после загрузки страницы.
Если сайт сделан на тяжёлой теме или с большим набором плагинов, не пытайтесь вычистить всё за один проход. Лучше идти по одному ресурсу: нашли источник, проверили страницу, отключили, снова протестировали. Такой подход медленнее, но он почти всегда безопаснее.
Когда лучше не удалять, а только оптимизировать
Иногда полностью убрать CSS или JS нельзя без потери функциональности. Тогда разумнее не удаление, а оптимизация загрузки:
- перенести неважный JS в отложенную загрузку, если это поддерживает ваш стек;
- загружать стили только на нужных шаблонах;
- убрать дублирующиеся библиотеки;
- сократить количество сторонних виджетов;
- отказаться от функций, которые не используются посетителями.
Если у вас нет уверенности, что файл действительно не нужен, не удаляйте его только потому, что он попал в отчёт как unused. Сначала проверьте сценарии использования, потом отключайте. Это особенно важно для меню, форм, корзины, модальных окон и других элементов, которые активируются не сразу.
В итоге рабочая схема простая: сначала находите конкретный CSS или JS, затем определяете, кто его подключает, после этого отключаете только там, где он не нужен, и обязательно проверяете сайт в браузере. Именно такой порядок позволяет убрать лишний код в WordPress без случайных поломок и с реальной пользой для PageSpeed.