Отложенная загрузка скриптов часто включается ради ускорения, но на практике именно она становится причиной странных багов: не открывается меню, ломается слайдер, не срабатывает форма, а иногда плывет весь первый экран. Обычно проблема не в самом defer или async, а в том, что скрипт был отложен без учета зависимостей и порядка выполнения.
Ниже — рабочий сценарий: как понять, что именно ломает сайт, как точечно убрать отложенную загрузку для нужных файлов и как проверить, что после правки ничего не отвалилось.
Когда отложенная загрузка скриптов действительно мешает
Если на сайте включен плагин оптимизации, тема сама добавляет атрибуты к скриптам или серверный кеш переписывает HTML, часть JS может начать выполняться позже, чем ожидает код. Это особенно заметно на:
- скриптах меню и мобильной навигации;
- слайдерах и галереях;
- формах обратной связи и валидации;
- скриптах аналитики, если они завязаны на события страницы;
- блоках, которые инициализируются сразу после загрузки DOM.
Типичный симптом
На странице все выглядит нормально в исходнике, но в браузере часть интерфейса не работает до ручного обновления или до повторного запуска скрипта. В консоли часто видно ошибки вида jQuery is not defined, Cannot read properties of undefined или ошибки инициализации плагина.
Диагностика: что именно отложено и кто это сделал
Сначала нужно понять, на каком уровне добавляется отложенная загрузка: в плагине кеширования, в теме, через фильтр WordPress или на стороне CDN. Самый быстрый путь — открыть исходный код страницы и посмотреть, какие скрипты получили defer или async.
<script src="https://example.com/wp-includes/js/jquery/jquery.min.js?ver=3.7.1" id="jquery-core-js"></script>
<script src="https://example.com/wp-content/themes/site/assets/js/main.js?ver=1.0.0" defer id="site-main-js"></script>Если атрибут появился не в теме, а уже после генерации HTML, ищите настройки в плагинах оптимизации: они обычно умеют исключать отдельные файлы по handle, пути или маске. Если скрипт добавляет сама тема, проверьте functions.php и подключение через wp_enqueue_script().
Что смотреть в консоли и Network
- ошибки JavaScript в Console;
- порядок загрузки файлов в Network;
- есть ли зависимость от jQuery;
- не загружается ли скрипт дважды;
- не уходит ли нужный файл в
deferвместе с библиотекой, от которой он зависит.
Как отключить отложенную загрузку точечно, а не для всего сайта
Полностью выключать оптимизацию обычно не нужно. Безопаснее убрать defer только у проблемных скриптов. Если у вас есть доступ к теме или небольшому плагину, можно использовать фильтр script_loader_tag и исключить конкретные handle.
<?php
add_filter( 'script_loader_tag', function( $tag, $handle, $src ) {
$exclude = array( 'jquery-core', 'site-main-js', 'contact-form-7' );
if ( in_array( $handle, $exclude, true ) ) {
$tag = sprintf(
'<script src="%s" id="%s-js"></script>',
esc_url( $src ),
esc_attr( $handle )
);
}
return $tag;
}, 10, 3 );Этот вариант полезен, если атрибуты добавляет ваш код или если вы хотите принудительно вернуть обычную загрузку для отдельных файлов. Но если defer вставляет плагин оптимизации, лучше сначала использовать его встроенный список исключений. Так меньше риск сломать обновления и не придется поддерживать костыль вручную.
Если отложенную загрузку добавляет плагин кеша
В большинстве плагинов есть поле для исключений по имени файла или части URL. Туда обычно добавляют:
jquery;main.js;contact-form-7;swiperили название библиотеки слайдера;- скрипт конкретного виджета, который ломается первым.
Смысл простой: сначала исключаем библиотеку, потом — скрипт, который от нее зависит. Если исключить только плагин, но оставить отложенной саму библиотеку, ошибка может остаться.
Сравнение подходов: плагин, код или полное отключение
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Исключение в плагине оптимизации | Если defer добавляет кеш-плагин | Быстро, без правки темы | Зависит от конкретного плагина |
Фильтр script_loader_tag | Если нужен точечный контроль | Работает на уровне WordPress | Нужно следить за handle и обновлениями |
| Полное отключение defer | Если сайт уже сломан и нужна быстрая проверка | Просто диагностировать причину | Может ухудшить скорость загрузки |
Пошаговое решение без лишнего риска
- Откройте страницу в режиме инкогнито и зафиксируйте проблему.
- Посмотрите ошибки в консоли браузера.
- Найдите скрипт, который отложен и участвует в ошибке.
- Добавьте его в исключения плагина кеша или снимите defer через код.
- Очистите кеш плагина, сервера и CDN.
- Проверьте страницу снова в чистой сессии.
Если проблема связана с jQuery, не спешите отключать defer у всех скриптов подряд. Часто достаточно вернуть обычную загрузку только для jquery-core и скрипта, который инициализируется сразу после него.
Проверка результата после внедрения
После правки откройте страницу в браузере и проверьте три вещи: нет ли ошибок в консоли, работает ли интерфейс и не изменился ли порядок загрузки критичных файлов. Хорошая практика — сравнить исходный HTML до и после изменения и убедиться, что нужный скрипт больше не получает defer или async.
- кнопка меню открывается с первого клика;
- формы отправляются без JS-ошибок;
- слайдер инициализируется без задержки;
- в консоли нет новых предупреждений;
- кеш очищен на всех уровнях.
Если есть доступ к Lighthouse или PageSpeed Insights, смотрите не только на общий балл, но и на поведение страницы. Иногда после отключения defer у одного файла визуально сайт становится стабильнее, а метрики почти не меняются. Это нормальный компромисс, если речь идет о критичном интерфейсе.
Частые ошибки и как их исправить
Отключили defer у всего сайта
Так делают, когда не хотят разбираться с зависимостями. В результате сайт может стать стабильнее, но тяжелее. Исправление простое: вернуть отложенную загрузку для безопасных файлов и оставить исключения только для проблемных.
Добавили в исключения не тот handle
В WordPress имя файла и handle — не одно и то же. Если в коде зарегистрирован site-main-js, а в исключение добавлен путь к файлу, плагин может его не распознать. Сначала проверьте, как скрипт подключается через wp_enqueue_script().
Не очистили кеш после правки
Это одна из самых частых причин ложного ощущения, что ничего не изменилось. После любого изменения в оптимизации очищайте кеш плагина, серверный кеш и CDN, если он есть.
Сломали зависимость от jQuery
Если скрипт написан под jQuery и выполняется раньше библиотеки, он падает. Решение — вернуть обычную загрузку для jQuery и всех скриптов, которые от него зависят.
Практические советы по безопасности и производительности
Не редактируйте плагины оптимизации напрямую: после обновления правки исчезнут. Если нужен код, держите его в дочерней теме или в небольшом must-use плагине. Для точечных исключений это надежнее и проще в сопровождении.
Если сайт большой, не пытайтесь отключить все оптимизации сразу. Сначала снимите defer только с критичных скриптов, затем проверьте, можно ли вернуть часть оптимизации обратно. Такой подход обычно дает лучший баланс между скоростью и стабильностью.
Когда причина неочевидна, удобно временно отключить все JS-оптимизации в плагине кеша, проверить поведение сайта, а потом включать их по одной. Это быстрее, чем искать проблему вслепую в продакшене.