Если сайт на WordPress грузит слишком много CSS и JavaScript, это обычно видно сразу: лишние запросы в браузере, долгий рендер, тяжелая главная и страницы, где подключается код от плагинов, которые там не нужны. Убирать такие assets можно, но делать это нужно не «на глаз», а по списку конкретных файлов и только там, где они действительно не используются.
Правильный подход простой: сначала найти, что именно загружается на фронтенде, потом понять, что из этого реально нужно на текущей странице, и только после этого отключать подключение точечно. Глобальное удаление стилей и скриптов почти всегда заканчивается поломанной версткой или неработающими формами.
С чего начать: найти лишние assets
В WordPress лишними чаще всего оказываются не только файлы темы, но и стили/скрипты плагинов, которые подключаются на всех страницах без разбора. Чтобы не гадать, откройте страницу сайта в браузере и посмотрите, что именно загружается.
Самый практичный способ — использовать инструменты разработчика в браузере:
- вкладка
Networkпокажет CSS и JS-файлы, которые уходят в запросы; - вкладка
Elementsпомогает понять, какой блок на странице мог потребовать этот файл; - если файл подключен, но на странице нет соответствующего функционала, это кандидат на отключение.
Для WordPress удобно дополнительно поставить плагин для диагностики подключений, например Query Monitor. Он показывает список enqueued styles и scripts, а также иногда помогает увидеть, какой плагин или тема их добавили. Это не инструмент для постоянной работы на боевом сайте, а именно диагностический помощник.
Еще один полезный признак: если CSS или JS относится к форме, слайдеру, галерее, блокам комментариев, иконкам, эмбедам или виджетам, проверьте, используется ли этот функционал на конкретной странице. Очень часто файл нужен только на одной-двух страницах, а грузится по всему сайту.
Что можно отключать безопасно, а что лучше не трогать
Не все подключения одинаково полезны для оптимизации. Есть файлы, которые можно убрать точечно, и есть те, которые лучше оставить до тех пор, пока вы не проверили зависимость на реальной странице.
| Тип подключения | Когда можно отключать | Когда лучше оставить |
|---|---|---|
| Стили и скрипты плагина | Если функционал плагина на странице не используется | Если на странице есть форма, галерея, слайдер, карта, таблица или другой блок плагина |
| Стили темы | Если это вспомогательный файл для редкого шаблона | Если файл влияет на базовую верстку, меню, шапку, мобильную адаптацию |
| WordPress core assets | Если вы точно знаете, что конкретный файл не нужен на сайте | Если это базовые стили блоков, комментариев или встроенных компонентов, которые реально используются |
Особенно осторожно относитесь к отключению стилей редактора блоков, комментариев и библиотек, которые могут использоваться несколькими плагинами сразу. Один и тот же файл иногда нужен неочевидно, и удаление «по названию» без проверки часто ломает внешний вид.
Как отключать лишние стили и скрипты точечно
Самый надежный вариант — делать это через дочернюю тему или небольшой собственный плагин. Так изменения не потеряются после обновления темы. Для отключения подключенных файлов в WordPress используются функции wp_dequeue_style(), wp_deregister_style(), wp_dequeue_script() и wp_deregister_script().
Разница простая: dequeue убирает файл из очереди на вывод, а deregister снимает его регистрацию. В большинстве случаев для фронтенда достаточно dequeue. deregister нужен реже, когда вы хотите полностью заменить регистрацию на свою версию.
Ниже пример, как отключить конкретные стили и скрипты на фронтенде. Перед этим нужно знать их handle — имя, под которым файл зарегистрирован в WordPress. Его можно увидеть через Query Monitor или в коде темы/плагина.
add_action( 'wp_enqueue_scripts', function () {
if ( is_admin() ) {
return;
}
// Примеры: замените handle на реальные значения из вашего сайта.
wp_dequeue_style( 'plugin-name-style' );
wp_dequeue_script( 'plugin-name-script' );
}, 100 );Приоритет 100 здесь важен: он помогает выполнить отключение после того, как тема и плагины уже успели подключить свои файлы. Если поставить слишком ранний приоритет, нужный asset может еще не быть зарегистрирован.
Если нужно убрать файл только на отдельных страницах, добавьте условие. Это безопаснее, чем отключать глобально:
add_action( 'wp_enqueue_scripts', function () {
if ( is_admin() ) {
return;
}
if ( is_page( 'contacts' ) ) {
wp_dequeue_style( 'contact-form-7' );
wp_dequeue_script( 'contact-form-7' );
}
}, 100 );В этом примере стили и скрипты отключаются только на странице с ярлыком contacts. Если форма на этой странице не используется, это нормальный сценарий. Но если форма там есть, отключение сломает отправку и валидацию.
Как понять правильный handle
Ошибка многих владельцев сайтов в том, что они пытаются отключить файл по имени CSS или JS из URL, а WordPress работает с внутренним идентификатором — handle. Найти его можно так:
- через Query Monitor в списке styles/scripts;
- в исходном коде темы или плагина, где вызывается
wp_enqueue_style()илиwp_enqueue_script(); - через документацию самого плагина, если разработчик ее дает.
Если handle найден неверно, отключение просто не сработает. Это безопасно, но бесполезно, поэтому проверка имени — обязательный шаг.
Что делать с файлами WordPress core
Иногда лишними оказываются не только файлы плагинов, но и стандартные подключения WordPress. Здесь нужно быть аккуратнее: у core-скриптов и стилей есть зависимости, и они могут использоваться темой, блоками или встроенными компонентами.
Например, на сайте без комментариев можно убрать часть связанного с ними кода, но только если вы уверены, что комментарии нигде не используются. Аналогично с emoji-скриптами, встроенными эмбедами и некоторыми служебными подключениями. Но универсального списка «всегда отключать» нет: многое зависит от темы, версии WordPress и набора плагинов.
Если вы не уверены, лучше сначала проверить, где именно используется файл. Иногда проще убрать не сам core-asset, а источник его подключения: отключить блок, виджет или плагин, который тянет лишнее.
Как проверить, что после отключения сайт не сломался
После каждого изменения откройте не только главную страницу, но и те шаблоны, где чаще всего проявляются проблемы: записи, страницы, архивы, контакты, формы, мобильную версию. Проверка должна быть не формальной, а по функционалу.
Минимум, что стоит посмотреть:
- не съехала ли верстка;
- работают ли меню и выпадающие элементы;
- открываются ли формы и отправляются ли они;
- не пропали ли стили у кнопок, блоков, галерей и таблиц;
- нет ли ошибок в консоли браузера.
Если после отключения на странице появились ошибки JavaScript, значит, вы убрали файл, от которого зависел другой скрипт. В таком случае возвращайте подключение и ищите более точечный способ: отключать только на страницах, где зависимость не нужна, или оставить файл, если он используется шире, чем казалось сначала.
Когда лучше не править код вручную
Если на сайте много плагинов, а список подключений большой, ручная чистка через functions.php быстро становится неудобной. В такой ситуации полезнее сначала собрать карту подключений и понять, какие файлы можно убрать без риска. Иногда проще и безопаснее использовать плагин, который умеет отключать assets по страницам, чем писать десятки условий вручную.
Если вам нужен именно практический инструмент для чистки лишнего кода и отключения ненужных подключений, у WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Его имеет смысл рассматривать, когда нужно не разово убрать один файл, а системно навести порядок в подключениях WordPress.
Но даже с плагином логика не меняется: сначала определяете, что именно грузится, потом проверяете, где это реально нужно, и только после этого отключаете. Такой подход дает заметный выигрыш без лишнего риска для сайта.
Если коротко, безопасная схема выглядит так: найти лишний CSS/JS, проверить зависимость на конкретной странице, отключить точечно через wp_dequeue_style() или wp_dequeue_script(), затем открыть сайт в браузере и убедиться, что ничего не сломалось. Именно точечное отключение, а не массовая чистка, обычно дает лучший результат на WordPress-сайтах с живой темой и набором плагинов.