Как отложить загрузку JavaScript в WordPress без ошибок

Что дает defer и чем он отличается от async

Обычный JavaScript в head может приостановить разбор HTML: браузер загружает файл, выполняет его и только потом продолжает строить страницу. defer позволяет загружать файл параллельно с обработкой HTML, но выполнить его после завершения разбора документа.

Для обычных внешних скриптов defer сохраняет порядок выполнения, в котором они подключены. Это делает его более предсказуемым для зависимых файлов. async работает иначе: скрипт выполняется сразу после загрузки, поэтому порядок может меняться в зависимости от скорости сети.

Поэтому async подходит только для независимых скриптов, которые не зависят от jQuery, библиотек или другого кода. Для скриптов с зависимостями безопаснее рассматривать defer или оставить стандартную загрузку.

• defer: загрузка параллельно с HTML, выполнение после его разбора;
• async: выполнение сразу после загрузки, без гарантии общего порядка;
• обычная загрузка: наиболее предсказуемый вариант, но она может блокировать обработку страницы.

Какие скрипты можно откладывать

Начинайте не с атрибута defer, а с анализа роли каждого JavaScript-файла. Откладывать стоит код, который не нужен для первого отображения страницы: фильтры каталога, дополнительные модальные окна, интерактивные блоки ниже первого экрана или функции, запускающиеся только после действия пользователя.

Не стоит автоматически откладывать jQuery, основной скрипт темы, файлы конструкторов страниц, скрипты корзины и checkout, а также библиотеки, от которых зависят другие файлы. На конкретной странице такой файл может быть критически важным, даже если на другой странице он не используется.

Отдельно проверяйте inline-код. Он может ожидать, что определенная библиотека уже доступна в момент выполнения. Добавление defer к внешнему файлу без анализа связанных inline-скриптов часто создает ошибки, которые не видны только по списку подключенных файлов.

• Более безопасные кандидаты: независимые виджеты, фильтры, слайдеры и функции, которые не нужны сразу.
• Рискованные кандидаты: jQuery, его плагины, скрипты темы, WooCommerce и конструкторов страниц.
• Не смешивайте без проверки defer для библиотеки и async для файла, который от нее зависит.

Как определить handle скрипта в WordPress

В WordPress скрипты подключаются через handle — уникальный идентификатор, например catalog-filter или theme-script. Именно handle нужно передать в wp_script_add_data(), а не URL файла и не название JavaScript-файла на диске.

Найти handle можно в коде темы или плагина, в вызове wp_enqueue_script(). Также помогают вкладка Network в DevTools и просмотр HTML-кода: обычно handle входит в имя или идентификатор сформированного тега script, однако для точной проверки лучше посмотреть регистрацию скрипта в коде.

Дополнительно проверьте зависимости, указанные при регистрации. Если catalog-filter зависит от jquery или другой библиотеки, отложенная загрузка должна учитывать эту зависимость. Handle должен быть уже зарегистрирован или добавлен через wp_enqueue_script() к моменту изменения его атрибутов.

• Ищите третий параметр wp_enqueue_script() — именно там часто указывают массив зависимостей.
• Проверяйте, на каких страницах handle действительно подключается.
• Не изменяйте все скрипты по одному универсальному правилу без проверки шаблонов.

Пример выборочного добавления defer

В примере ниже стратегия defer добавляется только для скрипта catalog-filter и только на страницах с шаблоном templates/catalog.php. Приоритет 100 дает теме или плагину время зарегистрировать нужный handle.

Этот код не регистрирует скрипт самостоятельно. Если handle не существует, WordPress не сможет применить к нему стратегию. Поэтому сначала убедитесь, что скрипт подключается на нужной странице.

• Замените catalog-filter на реальный handle вашего скрипта.
• Замените templates/catalog.php на фактический путь к шаблону.
• Не добавляйте async к этому же скрипту, если у него есть зависимости.

add_action('wp_enqueue_scripts', function () {
    if (!is_page_template('templates/catalog.php')) {
        return;
    }

    wp_script_add_data(
        'catalog-filter',
        'strategy',
        'defer'
    );
}, 100);

Как проверить сайт после изменений

Тестируйте не только скорость загрузки, но и все сценарии, которые могут зависеть от измененного скрипта. Проверка одной главной страницы не показывает проблемы, возникающие в каталоге, личном кабинете или во время оформления заказа.

После очистки кеша откройте сайт в режиме инкогнито и проверьте страницы на мобильных и настольных устройствах. Если используется кеширование или CDN, убедитесь, что пользователи получают новую версию HTML и JavaScript.

• Console: проверьте ошибки вроде is not defined, Cannot read properties of undefined и ошибки загрузки файлов.
• Network: убедитесь, что нужные скрипты загружаются, не имеют статусов 404 или blocked и выполняются в ожидаемом порядке.
• Интерфейс: проверьте мобильное меню, поиск, фильтры, слайдеры, вкладки и модальные окна.
• Формы и WooCommerce: добавьте товар в корзину, измените количество, примените купон, перейдите к checkout и выполните тестовую отправку формы.
• Производительность: сравните показатели и одновременно убедитесь, что не ухудшились стабильность страницы и взаимодействие пользователя.

Типичные ошибки при оптимизации JavaScript

Самая распространенная ошибка — глобально добавить defer или async ко всем script через плагин оптимизации или фильтр в functions.php. Такой подход может дать краткосрочное улучшение одного показателя, но сломать функции, используемые только в отдельных шаблонах.

Другая проблема — изменение атрибутов без учета кеша. Старый объединенный или минифицированный файл может оставаться в кеше плагина, CDN или браузера, поэтому результат теста не будет соответствовать новой конфигурации.

Также не следует исправлять ошибки простым переключением defer на async. Если причина заключается в неправильной зависимости, дублирующемся подключении или конфликте плагинов, изменение стратегии лишь сделает поведение менее предсказуемым.

• Не редактируйте напрямую файлы плагинов или темы — обновления перезапишут их.
• Не добавляйте defer к скрипту только потому, что он большой: сначала определите его зависимости и роль.
• Не считайте отсутствие ошибок на главной странице доказательством того, что checkout или формы работают правильно.
• После изменений очищайте кеш в правильном порядке: сайт, сервер, CDN и браузер — в зависимости от вашей инфраструктуры.