На живом WordPress-сайте лишние CSS и JS обычно появляются не из-за одной ошибки, а из-за накопления: тема тащит свои стили, плагин добавляет библиотеку на все страницы, а потом часть функциональности уже не используется. В результате растёт число запросов, усложняется отладка и появляются конфликты между скриптами.
Сразу важно разделить две задачи: удалить реально ненужные файлы и не отключить то, что нужно на отдельных страницах. Второе часто важнее первого.
Как понять, что проблема именно в лишних CSS и JS
Начинать стоит не с правки кода, а с проверки того, что именно грузится. В браузере откройте DevTools → Network и обновите страницу. Если видите файлы, которые не относятся к текущему шаблону или функциональности, это кандидат на отключение.
Признаки, что подключение лишнее
- скрипт загружается на всех страницах, хотя нужен только в форме, галерее или слайдере;
- файл идёт из плагина, который вы уже частично заменили другим решением;
- в HTML есть стили и JS от старой темы после миграции;
- на странице появляются ошибки в консоли, связанные с библиотекой, которой там быть не должно;
- после отключения плагина остались его ассеты в кэше или в очереди подключения.
Для первичной диагностики удобно использовать Query Monitor: он показывает список подключённых стилей и скриптов, а также источник их регистрации. Это не магия, а просто быстрый способ увидеть, кто именно добавил файл.
Сначала проверьте, можно ли убрать файл без кода
Если подключение идёт из плагина, посмотрите его настройки. Многие плагины позволяют отключать CSS на фронтенде, убирать иконки, шрифты, эмодзи, встроенные виджеты или лишние библиотеки. Это безопаснее, чем сразу писать wp_dequeue_style() наугад.
Если используете плагин для технической чистки, например Clearfy Pro, проверьте, нет ли там уже готовой опции для отключения лишних скриптов, эмодзи, dashicons для гостей и других стандартных нагрузок. Но даже в этом случае нужно сверяться с фактической загрузкой на странице, а не включать всё подряд.
Пошаговое решение через functions.php или mu-plugin
Когда источник понятен, отключайте ассеты точечно. Для этого лучше использовать дочернюю тему или mu-plugin, чтобы изменения не потерялись после обновления.
1. Найдите handle файла
В WordPress отключение работает не по имени файла, а по handle — внутреннему идентификатору, под которым стиль или скрипт зарегистрирован. Его можно увидеть в Query Monitor или в коде плагина/темы.
2. Отключите файл на нужной странице
Ниже пример, как убрать лишний стиль и скрипт только на фронтенде. Важно: сначала проверьте handle, потом уже вставляйте код.
add_action('wp_enqueue_scripts', function () {
if (is_admin()) {
return;
}
// Пример: отключаем стиль и скрипт плагина на всех страницах, кроме нужной.
wp_dequeue_style('plugin-extra-style');
wp_deregister_style('plugin-extra-style');
wp_dequeue_script('plugin-extra-script');
wp_deregister_script('plugin-extra-script');
}, 100);Если файл нужен только на одной странице, лучше ограничить отключение по условию. Например, на странице контактов форма должна работать, а на остальных — нет.
add_action('wp_enqueue_scripts', function () {
if (is_page('contacts')) {
return;
}
wp_dequeue_script('contact-form-7');
wp_dequeue_style('contact-form-7');
}, 100);Такой подход безопаснее, чем глобально вырезать всё подряд. Но если плагин использует несколько зависимых файлов, отключать нужно весь набор, иначе можно сломать интерфейс или валидацию.
3. Уберите ненужные подключения темы
Если проблема в теме, ищите вызовы wp_enqueue_style() и wp_enqueue_script() в functions.php, inc/ или в шаблонах. Часто там остаются старые библиотеки: слайдеры, lightbox, иконки, которые уже не используются.
Пример: если тема подключает библиотеку только для одной страницы, лучше перенести условие в регистрацию, а не отключать её после факта.
add_action('wp_enqueue_scripts', function () {
if (!is_page_template('templates/page-landing.php')) {
return;
}
wp_enqueue_script(
'landing-slider',
get_stylesheet_directory_uri() . '/assets/js/landing-slider.js',
array('jquery'),
'1.0.0',
true
);
});Что проверить после отключения
После каждого изменения откройте страницу в приватном окне и проверьте три вещи: загрузку, консоль и функциональность. Если файл был связан с формой, меню, галереей или модальным окном, убедитесь, что сценарий работает без ошибок.
- в Network больше нет отключённого CSS/JS;
- в Console нет ошибок
Uncaught ReferenceErrorили$ is not defined; - верстка не поехала на мобильных;
- форма отправляется, слайдер листается, кнопки кликаются;
- кэш-плагин и CDN не отдают старую версию файла.
Если используете кэширование, после правок очистите кэш плагина, серверный кэш и, при наличии, CDN. Иначе вы будете смотреть на старую сборку и решите, что код не сработал.
Сравнение подходов: плагин, код или сборка
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки плагина | Если лишнее подключает сам плагин и у него есть опция отключения | Не всегда есть точечный контроль |
Код через wp_dequeue_* | Если нужен точный контроль по страницам и шаблонам | Нужно знать handle и зависимости |
| Правка сборки темы | Если вы контролируете тему и можете убрать подключение на этапе разработки | Требует доступа к исходникам и дисциплины при обновлениях |
Частые ошибки и как их исправить
Отключили не тот handle
Это самая частая причина. Файл визуально похож на нужный, но handle у него другой. Решение простое: сначала найдите точное имя в Query Monitor или в исходниках, потом отключайте.
Сняли зависимость, но оставили зависимый скрипт
Например, убрали jQuery-плагин, а код инициализации оставили. В консоли появятся ошибки, а часть интерфейса перестанет работать. Проверьте, какие скрипты зависят друг от друга, прежде чем удалять.
Отключили ассет только на фронтенде, но забыли про редактор
Иногда стили нужны в блок-редакторе, а на сайте — нет. Для таких случаев разделяйте фронтенд и админку. Не используйте один и тот же хук без условий, если файл нужен в редакторе.
Проверили без очистки кэша
После правок старый CSS может продолжать отдаваться из кэша браузера, плагина или CDN. Очистка кэша — обязательный шаг, иначе диагностика будет ложной.
Практические советы по безопасности и производительности
Не отключайте всё подряд ради красивой цифры в отчёте. Сначала смотрите на реальную пользу: уменьшение количества запросов, устранение конфликтов и сокращение лишней логики. Если файл маленький и используется на половине сайта, выгода от его удаления может быть ниже риска поломки.
Для рабочих сайтов лучше вести список изменений: какой handle отключён, где и почему. Это экономит время, когда через месяц кто-то спросит, почему перестала работать конкретная кнопка или блок.
Если задача — не только убрать мусор, но и системно почистить сайт, имеет смысл смотреть в сторону инструментов, которые помогают управлять техническими настройками без ручного вмешательства. Но даже тогда финальная проверка в браузере остаётся обязательной.
Самый надёжный сценарий выглядит так: нашли источник, отключили точечно, проверили зависимости, очистили кэш, прогнали страницу в браузере и только потом переносите правку на боевой сайт.