Як відкласти завантаження 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 і браузер — залежно від вашої інфраструктури.