На живом WordPress-сайте почти всегда накапливаются лишние стили, скрипты и внешние подключения: от старых плагинов, от темы, от виджетов, от встроенных библиотек. Проблема не только в скорости. Лишние ресурсы мешают отладке, создают конфликты и иногда тянут за собой внешние запросы, которые вообще не нужны на конкретной странице.
Ниже — рабочий сценарий: как понять, что именно грузится зря, как отключать это безопасно и как проверить результат без гадания по PageSpeed.
Когда это действительно проблема
Сначала стоит отличить «много запросов» от реальной ошибки. Не каждый CSS или JS нужно удалять. Но если на странице товара, записи или лендинга вы видите ресурсы, которые относятся к формам, слайдерам, иконкам, блокам комментариев или плагинам, которых на странице нет, это уже кандидат на чистку.
Типичные признаки
- в DevTools в Network загружаются файлы от плагинов, которые не используются на странице;
- в HTML есть
<link rel="stylesheet">и<script>от отключённых функций темы; - один и тот же библиотечный файл подключается несколько раз разными плагинами;
- после удаления плагина в коде остаются внешние ссылки на его ассеты;
- в консоли появляются ошибки из-за скриптов, которые ожидают элементы, отсутствующие на странице.
Диагностика: что именно грузится лишним
Начинать лучше не с удаления, а с карты подключений. Откройте проблемную страницу в браузере, затем:
- Откройте DevTools → вкладка Network.
- Обновите страницу с включённым сохранением лога.
- Отфильтруйте по
cssиjs. - Посмотрите, какие файлы идут с темой, какими плагинами и с каких доменов.
Если нужно быстро увидеть список подключённых скриптов и стилей в HTML, можно временно вывести их через хук wp_enqueue_scripts в режиме отладки или использовать просмотр исходника страницы. Но для точечной работы удобнее смотреть уже зарегистрированные handles.
<?php
add_action('wp_enqueue_scripts', function () {
if (is_admin()) {
return;
}
global $wp_scripts, $wp_styles;
if (!empty($wp_scripts->queue)) {
error_log('Scripts: ' . implode(', ', $wp_scripts->queue));
}
if (!empty($wp_styles->queue)) {
error_log('Styles: ' . implode(', ', $wp_styles->queue));
}
}, 9999);Этот вариант полезен на staging или локальной копии. На боевом сайте логирование в error_log включайте только если понимаете, куда пишется файл и кто его читает.
Как убрать лишнее точечно, а не «наугад»
Самый безопасный путь — отключать только то, что вы точно идентифицировали. В WordPress для этого используются wp_dequeue_script(), wp_dequeue_style(), а иногда и wp_deregister_script() или wp_deregister_style(). Обычно достаточно dequeue: вы убираете подключение на конкретной странице, не ломая регистрацию для других мест.
Пример: отключить скрипт только на одной странице
<?php
add_action('wp_enqueue_scripts', function () {
if (!is_page('contacts')) {
return;
}
wp_dequeue_script('contact-form-7');
wp_dequeue_style('contact-form-7');
}, 100);Здесь важно не имя файла, а handle. Его можно найти в коде плагина или через поиск по wp_enqueue_script / wp_enqueue_style.
Пример: убрать библиотеку темы, если она не нужна на фронтенде
<?php
add_action('wp_enqueue_scripts', function () {
if (is_admin()) {
return;
}
if (!is_singular('post')) {
wp_dequeue_script('theme-slider');
}
}, 20);Если библиотека регистрируется внутри темы и используется только в одном шаблоне, лучше не удалять её глобально. Иначе получите ошибки на страницах, где она всё же нужна.
Сравнение подходов: плагин, код, ручная чистка
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Код в дочерней теме или mu-plugin | Нужно отключить 1–10 конкретных ресурсов | Точный контроль | Нужно знать handles и логику загрузки |
| Плагин для оптимизации ассетов | Много страниц и много подключений | Удобно для неразработчика | Есть риск переборщить с отключениями |
| Ручное удаление из темы/плагина | Вы владелец кода и готовы его поддерживать | Чистое решение | Сложнее обновлять и легко сломать совместимость |
Если задача регулярная, а не разовая, удобнее вынести правила в отдельный mu-plugin. Тогда они не потеряются при смене темы.
Пошаговое решение без лишнего риска
- Составьте список ресурсов, которые реально не нужны на конкретной странице.
- Найдите их handles в исходниках темы или плагина.
- Добавьте отключение через
wp_dequeue_script()иwp_dequeue_style()с условием по типу страницы. - Проверьте, не завязаны ли на них другие элементы интерфейса.
- Прогоните страницу в браузере и в инструменте проверки производительности.
Если нужно отключать ресурсы только на части сайта, удобно использовать условные теги WordPress: is_page(), is_single(), is_front_page(), is_archive(). Это лучше, чем пытаться ловить URL строками.
Если ресурс подключает внешний домен
Иногда проблема не в локальном CSS/JS, а во внешних подключениях: шрифты, карты, виджеты, аналитика, iframe. Их тоже стоит оценивать отдельно. Если виджет нужен только на одной странице, не оставляйте его глобально на всём сайте.
Для внешних шрифтов и карт часто помогает не только отключение, но и перенос загрузки на локальный вариант или замена на более лёгкое решение. Но это уже отдельная задача, и её не стоит смешивать с чисткой ассетов.
Как проверить, что решение сработало
Проверка должна быть не по ощущениям, а по факту. После изменений откройте страницу в режиме инкогнито и сравните исходный HTML и список сетевых запросов.
- В Network больше нет отключённых CSS/JS.
- В исходнике страницы отсутствуют соответствующие
linkиscript. - В консоли нет ошибок
Uncaught ReferenceErrorили$ is not defined. - Формы, меню, слайдеры и другие элементы продолжают работать.
- Кэш плагина и CDN очищены, иначе вы увидите старую версию страницы.
Если используете серверный или фронтенд-кэш, обязательно сбросьте его после правок. Иначе можно решить, что отключение не сработало, хотя на самом деле вы просто смотрите старую копию HTML.
Частые ошибки и как их исправить
Отключили не тот handle
Частая ситуация: в коде убирают файл по имени, которого WordPress вообще не знает. В результате ничего не меняется. Проверяйте именно handle, а не путь к файлу.
Сняли регистрацию вместо dequeue
wp_deregister_script() и wp_deregister_style() нужны реже. Если вы снимаете регистрацию глобально, другой плагин может ожидать этот handle и начать падать. Для точечной чистки обычно безопаснее dequeue.
Отключили ресурс без проверки зависимостей
Некоторые скрипты тянут за собой jQuery, wp-util, wp-i18n или другие зависимости. Если убрать только верхний файл, а зависимость оставить, можно получить скрытые ошибки в консоли. Сначала проверьте, кто от кого зависит.
Сделали правку в родительской теме
После обновления всё исчезнет. Для постоянных правок используйте дочернюю тему или mu-plugin.
Чистили всё подряд ради «зелёной» метрики
Удаление ресурсов ради одной оценки часто ломает интерфейс. Правильный критерий — не количество отключённых файлов, а отсутствие лишнего кода на конкретной странице при сохранении функциональности.
Практические советы по безопасности и производительности
Если вы регулярно чистите ассеты, держите под рукой staging-копию сайта. На ней проще ловить конфликты, чем на боевом проекте. Ещё один полезный приём — хранить все правила отключения в одном файле, а не размазывать их по шаблонам.
Для сайтов с большим количеством плагинов иногда удобнее использовать специализированный инструмент для технической чистки и удаления дублей. Например, в Clearfy Pro есть функции, которые помогают управлять лишними подключениями и упрощают техническую оптимизацию сайта: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала нужно понять, что именно вы отключаете, а не полагаться на автоматический чекбокс.
Если задача касается не только ассетов, но и контента, блоков внимания, FAQ или экспертных вставок, лучше разделять оптимизацию интерфейса и оптимизацию кода. Иначе легко получить «чистый» сайт, который хуже конвертирует и сложнее поддерживается.
Мини-чек-лист перед публикацией изменений
- Проверены handles для всех отключаемых ресурсов.
- Изменения вынесены в дочернюю тему или mu-plugin.
- Проверены страницы, где ресурс всё ещё нужен.
- Очищен кэш плагина, сервера и CDN.
- Нет ошибок в консоли браузера.
- Сайт открывается без визуальных поломок на мобильных и десктопе.
Если после чистки вы видите, что страница стала легче, но появились ошибки в интерфейсе, откатывайте только последний шаг и ищите зависимость. В таких задачах лучше убрать один лишний файл, чем сломать весь шаблон ради сомнительного выигрыша.