На живом WordPress-сайте часто копится не только лишний код плагинов, но и подключения, которые уже никто не использует: старые стили темы, скрипты виджетов, библиотека, которая дублируется другим плагином, или assets, оставшиеся после обновления шаблона. Внешне сайт работает, но в исходнике продолжают грузиться файлы, которые не участвуют в рендере страницы.
Задача здесь не в том, чтобы «всё отключить», а в том, чтобы найти конкретные сиротые стили и скрипты, убрать только безопасные подключения и проверить, что ничего не сломалось в админке, фронтенде и на отдельных шаблонах.
Когда проблема действительно есть
Сначала стоит убедиться, что речь не о нормальном поведении темы или плагина. Лишним подключение можно считать, если файл:
- подгружается на страницах, где его функциональность не используется;
- дублируется другим файлом с тем же назначением;
- остался после удаления плагина или смены темы;
- не влияет на интерфейс, но продолжает грузиться на всех страницах сайта;
- ломает критический CSS-контент, потому что подключается в неправильном порядке.
Диагностика в браузере и в коде
Откройте страницу в Chrome DevTools или Firefox Developer Tools и посмотрите вкладки Network и Sources. Если видите файл, который явно не относится к текущей странице, проверьте его источник: тема, плагин, дочерняя тема, mu-plugin или inline-инициализация.
Для быстрой проверки полезно временно вывести список зарегистрированных стилей и скриптов в админке или на тестовой копии сайта. Это помогает понять, что именно WordPress считает подключенным, а не только что реально попало в HTML.
<?php
add_action( 'wp_footer', function () {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
global $wp_scripts, $wp_styles;
echo '<!-- Scripts: ' . esc_html( implode( ', ', array_keys( $wp_scripts->registered ) ) ) . ' -->';
echo '<!-- Styles: ' . esc_html( implode( ', ', array_keys( $wp_styles->registered ) ) ) . ' -->';
} );
Этот код не решает проблему сам по себе, но помогает быстро увидеть, какие handle вообще зарегистрированы. На боевом сайте такую отладку лучше включать только временно.
Что отключать вручную, а что лучше не трогать
Если файл подключает плагин, сначала проверьте его настройки. У многих расширений есть опция отключить фронтенд-стили, если виджет или блок не используется. Если настройки нет, тогда уже имеет смысл снимать подключение через wp_dequeue_style() и wp_dequeue_script().
| Подход | Когда подходит | Риск |
|---|---|---|
| Настройка плагина | Если разработчик предусмотрел отключение assets | Минимальный |
| Код в дочерней теме | Если нужно точечно убрать файл на конкретных шаблонах | Средний: зависит от handle и приоритета |
| Удаление плагина | Если функциональность больше не нужна | Низкий, но нужно проверить зависимости |
Если вы не уверены, что файл действительно лишний, не удаляйте его сразу. Сначала отключите на одной странице или для одной группы шаблонов и проверьте, не пропали ли стили меню, формы, слайдера или блоков редактора.
Пошаговое удаление сиротых стилей и скриптов
1. Найдите handle подключения
WordPress отключает не по имени файла, а по handle. Его можно увидеть в исходниках темы или плагина: обычно он передаётся в wp_enqueue_style() и wp_enqueue_script().
<?php
add_action( 'wp_enqueue_scripts', function () {
wp_dequeue_style( 'plugin-old-style' );
wp_dequeue_script( 'plugin-old-script' );
}, 100 );
Приоритет 100 здесь важен: если снять подключение слишком рано, плагин или тема могут снова добавить файл позже. Это одна из самых частых причин, почему код «не работает».
2. Ограничьте отключение нужными страницами
Не стоит убирать asset глобально, если он нужен хотя бы на одной странице. Например, стили формы обратной связи не нужны на всех страницах, но нужны на странице контактов.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( is_page( 'contacts' ) ) {
return;
}
wp_dequeue_style( 'contact-form-7' );
wp_dequeue_script( 'contact-form-7' );
}, 100 );
Логика простая: сначала исключаете страницы, где asset действительно нужен, потом отключаете в остальных местах. Это безопаснее, чем пытаться «почистить всё сразу».
3. Уберите только то, что не используется в шаблоне
Если тема грузит библиотеку для конкретного блока, а блок есть только на одной странице, можно отключить файл на остальных шаблонах. Для этого удобно использовать условные теги WordPress: is_front_page(), is_single(), is_page_template(), is_archive().
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( is_front_page() || is_page_template( 'templates/landing.php' ) ) {
return;
}
wp_dequeue_style( 'theme-slider' );
wp_dequeue_script( 'theme-slider' );
}, 100 );
Как понять, что файл действительно сиротый
Иногда asset выглядит лишним, но на деле используется косвенно: через inline-скрипт, через CSS-переменные, через блоки редактора или через JS-инициализацию в футере. Поэтому перед удалением проверьте три вещи:
- есть ли вызовы классов или функций этого файла в теме и плагинах;
- не используется ли он только в админке или в редакторе блоков;
- не подхватывается ли он сторонним плагином как зависимость.
Если файл нужен только в редакторе, его не стоит отключать через фронтенд-хуки. Для этого лучше разделять фронтенд и админские подключения и не смешивать их в одном условии.
Проверка результата после внедрения
После удаления лишних подключений не ограничивайтесь визуальным просмотром главной страницы. Проверка должна быть по нескольким сценариям: главная, запись, страница, архив, шаблон контактов, мобильная версия и админка.
- Откройте страницу в режиме инкогнито и проверьте, что нужные блоки отображаются.
- Посмотрите вкладку
Network: файл должен исчезнуть или перестать грузиться на выбранных шаблонах. - Проверьте консоль браузера на ошибки JavaScript.
- Сравните исходный HTML до и после правки.
- Если есть кэш, очистите его и проверьте страницу без CDN-кеша.
Хороший признак — файл исчезает только там, где вы его отключали, а интерфейс не теряет стили и поведение. Если после правки сломалась кнопка, выпадающее меню или слайдер, значит, вы сняли не сиротый asset, а зависимость.
Частые ошибки и как их исправить
Отключают по имени файла, а не по handle
WordPress не понимает путь к файлу как аргумент для wp_dequeue_style(). Нужен именно handle, который использовался при регистрации. Если handle неизвестен, ищите его в коде темы или плагина.
Снимают подключение слишком рано
Если код висит на слишком низком приоритете, плагин может снова добавить стиль или скрипт позже. В таких случаях помогает приоритет 100 или выше, но без фанатизма: сначала проверьте, где именно регистрируется asset.
Удаляют файл, который нужен в редакторе или админке
Это частая ошибка при работе с универсальными плагинами. Если asset используется в блок-редакторе, отключение на фронтенде может быть безопасным, а в админке — нет. Разделяйте условия для is_admin() и фронтенда.
Не учитывают зависимости
Скрипт может зависеть от jquery, wp-element или другого зарегистрированного файла. Если убрать зависимость, начнутся ошибки в консоли. Перед отключением проверьте массив зависимостей в регистрации скрипта.
Практические советы по безопасности и производительности
Любые правки делайте в дочерней теме или в небольшом mu-plugin, а не в файлах родительской темы. Так обновление не затрёт изменения. Для теста лучше использовать staging-копию, особенно если сайт уже кэшируется на уровне сервера или CDN.
Если на сайте много плагинов, полезно сначала убрать неиспользуемые assets через настройки или деактивацию лишних расширений, а уже потом добираться до кода. Иногда это даёт больший эффект, чем точечное отключение нескольких файлов.
Для сайтов, где регулярно появляются дубли и лишние подключения, имеет смысл периодически проверять фронтенд после обновлений темы и плагинов. Обновление может вернуть старый asset или добавить новый handle, который снова придётся разбирать вручную.
Если нужен более системный подход к чистке сайта, можно использовать инструменты уровня Clearfy Pro, но и в этом случае стоит понимать, что именно отключается и на каких шаблонах. Автоматическая чистка без проверки иногда убирает не только мусор, но и нужные зависимости.
Мини-чек-лист перед публикацией правок
- Определён handle файла, а не только его URL.
- Проверено, где asset реально используется.
- Отключение ограничено нужными шаблонами.
- Проверена консоль браузера на ошибки.
- Сайт протестирован после очистки кэша.
- Изменения внесены в дочернюю тему или mu-plugin.
Если после всех проверок файл всё ещё нужен на части страниц, не пытайтесь удалить его глобально. В WordPress точечное отключение почти всегда безопаснее, чем «чистка всего подряд».