Як знизити час блокування сторінки (TBT) за допомогою відкладеного завантаження JavaScript (Defer/Async) на вашому сайті

Q: Чи можна одночасно використовувати defer і async для одного скрипту?

Якщо в тег script додати одночасно defer і async, у сучасних браузерах перевага зазвичай надається async, що позбавляє гарантії порядку виконання. Тому не рекомендується використовувати обидва атрибути одночасно для одного файлу. Для залежних файлів обирайте defer, для незалежних — async.

Відкладене завантаження JavaScript — це метод оптимізації, що дозволяє зменшити Total Blocking Time (TBT), відкладаючи завантаження скриптів, які блокують відображення сторінки, у правильному порядку. По суті, додаючи атрибути defer або async до некритичних файлів скриптів, ви зменшуєте час блокування головного потоку браузера. Це дозволяє користувачеві швидше побачити вміст сторінки, раніше взаємодіяти з нею, а також покращує показники Core Web Vitals. Щоб впровадити відкладене завантаження на вашому сайті, спочатку потрібно визначити критичні файли, застосовувати defer для залежних скриптів, а async — для незалежних сторонніх скриптів, а після змін вимірювати TBT за допомогою PageSpeed Insights, Lighthouse та Chrome DevTools.

У сучасних вебпроєктах проблеми з продуктивністю частіше за все виникають через неконтрольоване використання JavaScript, а не через зображення. Наприклад, на сайті інтернет-магазину, де одночасно завантажуються фільтри товарів, чат підтримки, рекламні пікселі, аналітичні коди, плагіни коментарів, інструменти A/B тестування та скрипти теми, головний потік браузера довго зайнятий. Особливо це помітно на мобільних пристроях — користувач може бачити заголовок сторінки, але меню або кнопки реагують із затримкою. У звіті Lighthouse це проявляється як високий показник Total Blocking Time.

У цьому матеріалі ми детально розглянемо, що таке атрибути defer і async, коли і як їх застосовувати, як реалізувати це у WordPress та кастомних проєктах, на що звертати увагу під час вимірювань і які реальні покращення можна очікувати. Рекомендації підходять для сайтів, розміщених на інфраструктурі Hostragons, а також пояснюють, як правильний вибір хостингу, CDN, SSL-сертифікатів та кешування підтримує оптимізацію JavaScript. Hostragons пакети веб-хостингу

Що таке TBT і чому він тісно пов’язаний із JavaScript?

TBT (Total Blocking Time) — це показник, який вимірює час, протягом якого головний потік браузера заблокований і не може реагувати на дії користувача. У лабораторних тестах Lighthouse цей час вимірюється між First Contentful Paint і Time to Interactive, враховуючи всі завдання, тривалість яких перевищує 50 мс. Наприклад, якщо JavaScript-завдання виконується 180 мс, то 130 мс після перших 50 мс враховується до TBT.

Цей показник критично важливий для UX, бо коли користувач відкрив сторінку і намагається взаємодіяти з меню, кошиком або пошуком, але браузер все ще виконує JavaScript, реакція затримується. Користувач сприймає це як «зависання», повільну реакцію або несправність сайту. У майбутніх SEO-стандартах Google 2026 року швидка і стабільна взаємодія буде ключовою складовою оцінки якості сторінки, що вплине на рейтинг і конверсії.

Основні ознаки високого TBT

Показник TBT у мобільному звіті PageSpeed Insights перевищує 300 мс.
У звітах Lighthouse з’являються попередження Reduce JavaScript execution time або Minimize main-thread work.
Сторінка відображається, але меню, слайдери, фільтри або форми реагують із затримкою.
Сторонні рекламні, чат- або аналітичні скрипти виглядають у звіті як дуже ресурсомісткі.
Особливо на бюджетних Android-пристроях помітні затримки при прокручуванні та натисканні.

Для більшості контентних сайтів здоровим вважається TBT нижче 200 мс. Для складніших інтерфейсів e-commerce або SaaS цього результату можна досягти не лише defer і async, а й розбиттям коду, видаленням непотрібних пакетів, покращенням кешування, оптимізацією серверної відповіді та критичних CSS-стилів. Проте відкладене завантаження JavaScript — це одна з найпростіших і найшвидших у реалізації оптимізацій.

Що таке Defer і Async?

За замовчуванням при додаванні тегу <script> браузер зупиняє розбір HTML, завантажує і виконує JavaScript, а потім продовжує формувати сторінку. Це іноді необхідно для критичних скриптів, але при надмірному використанні викликає зайві затримки. Атрибути defer та async змінюють цей процес, дозволяючи завантажувати та запускати скрипти за іншими правилами.

Як працює defer?

Скрипт з атрибутом defer завантажується фоном під час парсингу HTML, але виконується лише після повного розбору документа. При цьому кілька скриптів з defer зберігають порядок запуску відповідно до порядку в HTML. Це робить цей метод безпечним для залежних скриптів, наприклад, коли спочатку підключається бібліотека, а потім скрипт теми, що від неї залежить.

Приклад використання: <script defer src="/js/app.js"></script>. Файл app.js буде завантажено без блокування першого відображення сторінки і виконаний послідовно після готовності DOM. Сучасні браузери широко підтримують defer як надійний спосіб оптимізації класичних скриптів.

Як працює async?

Скрипт з атрибутом async також завантажується фоном, але виконується відразу після завершення завантаження, навіть якщо парсинг HTML ще не закінчився. Через це парсинг сторінки може тимчасово зупинитись. Async не гарантує порядок запуску скриптів — перший завантажений запускається першим.

Async краще підходить для незалежних сторонніх скриптів: аналітики, реклами, пікселів, віджетів або соціальних мереж.

Приклад: <script async src="/js/analytics.js"></script>. Цей скрипт не має чекати на інші локальні скрипти. Якщо ж analytics.js залежить від змінних, що оголошені пізніше, або бібліотек як jQuery, async може викликати помилки. Тож async швидкий, але потребує уважного підбору.

Порівняльна таблиця defer і async

Порівняльна таблиця defer і async
Характеристика	defer	async
Чи блокує HTML-парсинг під час завантаження?	Ні, завантаження у фоновому режимі.	Ні, завантаження у фоновому режимі.
Коли виконується скрипт?	Після завершення парсингу HTML.	Одразу після завантаження.
Чи гарантується порядок виконання?	Так, відповідно до порядку у HTML.	Ні, виконується перший завантажений.
Оптимальне застосування	Скрипти теми, залежні модулі, основні файли.	Незалежні аналітика, реклама, пікселі, сторонні віджети.
Ризики	Можлива затримка для коду, що повинен запускатись раніше DOM.	Помилки в залежних скриптах через гонки.
Вплив на TBT	Зменшує блокування при початковому завантаженні, безпечний баланс.	Ефективний для швидкого підключення незалежних скриптів.

Практичне правило: якщо скрипт має виконуватись у певному порядку — починайте з defer. Якщо скрипт цілком незалежний — розглядайте async. Якщо сумніваєтесь, спочатку тестуйте defer на тестовому середовищі, перевіряйте консоль на помилки та критичні взаємодії. посібник з тестового середовища та резервного копіювання

Покроковий план впровадження відкладеного завантаження JavaScript

Просто додати defer або async до всіх скриптів може тимчасово покращити показники, але призведе до збоїв у роботі критичних функцій — кошика, пошуку, меню, валідації форм тощо. Тому потрібен системний підхід із вимірюваннями, класифікацією, поступовими змінами, тестуванням і моніторингом.

1. Виміряйте поточну продуктивність

Перед початком зафіксуйте базові показники. Зробіть скріншоти та збережіть результати PageSpeed Insights для мобільних і десктопних версій. У звіті Lighthouse зверніть увагу на TBT, First Contentful Paint, Largest Contentful Paint та Speed Index. У Chrome DevTools у вкладці Performance проаналізуйте головний потік: довгі жовті блоки свідчать про витрати на розбір, компіляцію та виконання JavaScript.

Наприклад, початковий мобільний TBT 780 мс, час виконання JavaScript 2,8 с, main-thread work 4,5 с. Після оптимізації мобільний TBT падає до 280 мс — це покращення на 64%. Такі дані допомагають команді зрозуміти ефективність змін.

2. Зробіть інвентаризацію скриптів

Перегляньте всі JavaScript-файли, що завантажуються на сторінці, у коді або вкладці Network. Визначте їхнє джерело, розмір, час необхідності та залежності. Розподіліть файли на групи:

Критичні скрипти: потрібні для першого відображення або базової навігації.
Залежні локальні скрипти: теми, слайдери, фільтри, галереї, модулі.
Незалежні сторонні скрипти: аналітика, реклама, пікселі, чат-боти, соціальні віджети.
Застарілі або непотрібні скрипти: залишки від неактивних плагінів.
Скрипти з умовним завантаженням: наприклад, валідація форм лише на сторінці контакту.

Оптимальніше іноді не додавати defer, а взагалі прибрати непотрібний скрипт. 90 КБ стисненого файлу може викликати понад 300 мс затримки на мобільних пристроях через парсинг і виконання. Тож спочатку очистіть, потім відкладайте.

3. Визначте скрипти для defer

Зазвичай це основні скрипти теми, меню, слайдерів, галерей та багатофайлові бандли. Важливо, щоб скрипти не використовували застарілі блокуючі методи, як document.write, і могли запускатися після готовності DOM.

У WordPress темах jquery-migrate, основний файл теми і плагінні скрипти часто мають складні залежності. Робити jQuery async ризиковано, бо багато плагінів чекають на її послідовне завантаження. Краще контролювати defer для залежних скриптів або використовувати плагіни з оптимізованим завантаженням. Посібник з оптимізації швидкості WordPress

4. Визначте скрипти для async

Google Analytics, рекламні теги, Facebook Pixel, LinkedIn Insight Tag, деякі зовнішні чат-боти та соціальні кнопки — найкращі кандидати для async. Але не всі сторонні скрипти однакові: деякі чати потребують запуску відразу після завантаження для ініціалізації сесії, а рекламні системи можуть вимагати певного порядку. Тому треба вивчати документацію.

Async для незалежного аналітичного коду зазвичай безпечний і не шкодить UX. Щоб уникнути втрати даних, контролюйте тригери в реальному часі. Якщо використовуєте менеджер тегів, організуйте тригери так, щоб, наприклад, скрипти для відстеження коментарів не завантажувалися на сторінках без форм, а взаємодії з товарами — поза продуктовими сторінками.

5. Додайте умовне й подієве завантаження

Defer і async — хороший старт, але завантаження JavaScript залежно від дій користувача дає ще більший ефект на зниження TBT. Наприклад, чат підтримки можна запускати не одразу, а через 5 секунд перебування на сторінці або після кліку на кнопку допомоги. Вбудовані карти можна завантажувати лише при прокручуванні до контактного блоку, відеоплеєр — при натисканні на кнопку відтворення.

Цей підхід особливо корисний для контентних та корпоративних сайтів, де не всі віджети потрібні відразу. Відключення 200 КБ JavaScript при початковому завантаженні може зменшити TBT на сотні мілісекунд, особливо на слабких мобільних пристроях.

6. Тестуйте та впроваджуйте поступово

Не впроваджуйте зміни одразу на робочому сайті. Спочатку тестуйте на staging-середовищі. Перевіряйте критичні сторінки: головну, категорії, продукти чи послуги, контактну сторінку, форми входу й оплати. Контролюйте наявність помилок у консолі, особливо типу Cannot read property, is not defined, undefined function — це сигнал про проблеми з порядком завантаження.

Впроваджуйте зміни поетапно: спочатку оптимізуйте сторонні скрипти, потім скрипти теми. Після кожного кроку повторюйте Lighthouse тестування в однакових умовах. Не покладайтеся на один вимір — робіть середнє з трьох запусків для більш точної оцінки.

Особливості застосування defer і async у WordPress

У WordPress JavaScript-файли підключаються через функцію wp_enqueue_script темами і плагінами. Станом на 2026 рік сучасні версії WP дозволяють більш гнучко керувати стратегіями завантаження скриптів, але старі теми, конструктори сторінок і плагіни оптимізації можуть конфліктувати.

Якщо використовуєте плагіни для прискорення, не відкладайте всі скрипти одним кліком — створюйте списки виключень. Критичні сторінки як оформлення замовлення, вхід, адмін-панель, скрипти безпеки та капчі потребують особливої уваги. Для WooCommerce важливо протестувати кошик, платіжні шлюзи та селектори варіацій. Рішення для WooCommerce хостингу

Практичний порядок дій: спочатку видаліть непотрібні плагіни, потім зробіть умовне завантаження плагінних скриптів, далі застосуйте defer до скриптів теми, а наприкінці — async для незалежних сторонніх кодів. Такий підхід мінімізує ризики серйозних збоїв.

Зв’язок хостингу, часу відповіді сервера і продуктивності JavaScript

TBT безпосередньо залежить від часу виконання JavaScript у браузері, але інфраструктура хостингу впливає опосередковано. Повільний TTFB, відсутність стиснення, підтримки HTTP/2 чи HTTP/3, слабке кешування та велика відстань до серверу затримують доставку JS-файлів. Через це збільшується час життєвого циклу сторінки і погіршується UX.

Якісний хостинг із Brotli або Gzip стисненням, ефективним кешуванням браузера, актуальною версією PHP, швидкими дисками та CDN суттєво підтримує оптимізацію. Правильна установка SSL-сертифіката важлива для роботи сучасних браузерних функцій, HTTP/2 та безпечної інтеграції з третіми сторонами. Hostragons SSL сертифікати Hostragons перевірка домену

Наприклад, той самий JavaScript-файл без стиснення може важити 320 КБ, а з Brotli — лише 95 КБ. Це безпосередньо не зменшує TBT, який вимірює час виконання, але скорочує час завантаження, полегшує пріоритизацію ресурсів і покращує загальний досвід користувача. Тому defer, async, кешування та правильний хостинг потрібно розглядати в комплексі.

Контрольний список для вимірювань і перевірки

Щоб оцінити ефективність оптимізації, не достатньо дивитись лише на PageSpeed Score. Цей чекліст допоможе краще зрозуміти реальний вплив:

Порівняння мобільного TBT до і після оптимізації.
Зменшення часу виконання JavaScript у звітах.
Зниження кількості довгих завдань у Chrome DevTools Performance.
Відсутність помилок JavaScript у консолі.
Коректна робота меню, пошуку, фільтрів, форм, кошика та процесу оплати.
Правильне спрацьовування сторонніх аналітичних і рекламних скриптів.
Покращення INP і взаємодії у реальних користувачів.
Перевірка після очищення кешу.

Важливо розділяти лабораторні тести та реальні показники користувачів. TBT — це лабораторний показник, а Interaction to Next Paint (INP) стає все важливішим для оцінки UX. Проте зниження TBT зазвичай позитивно впливає і на INP, оскільки зменшує блокування головного потоку.

Типові помилки та як їх уникнути

Встановлення async для всіх скриптів одночасно

Це найпоширеніша помилка. Async не гарантує порядок виконання, тому залежні скрипти можуть викликати випадкові помилки. Структури, які працюють на одному браузері, можуть зламатися на іншому або при повільному інтернеті. Для залежних файлів безпечніше починати з defer.

Неправильне відкладення jQuery і залежних плагінів

У WordPress багато плагінів залежить від послідовного завантаження jQuery. Async для jQuery призведе до помилок, оскільки плагіни можуть спробувати виконатись раніше. Рішення — з’ясувати залежності і виключити критичні файли зі списку async.

Ігнорування сторонніх скриптів

Власник сайту може оптимізувати свої скрипти, але забути про сторонні рекламні, чат- і аналітичні коди. Lighthouse часто показує, що саме сторонні скрипти викликають найбільше блокувань. Видалення непотрібних, умовне завантаження або відкладення цих скриптів дають значний приріст.

Встановлення плагінів без попереднього аналізу

Плагіни для оптимізації корисні, але встановлювати їх без діагностики можна лише на свій ризик — вони можуть додати новий JavaScript і CSS, що навпаки погіршить ситуацію. Спершу визначте проблему, потім обирайте інструмент, і перевірте його ефективність через звіти.

Ігнорування конфліктів кешування і мініфікації

Поєднання мініфікації, об’єднання файлів, defer і async може змінювати порядок завантаження і викликати помилки на продакшені. Особливо це складно, якщо використовуєте CDN, серверне та клієнтське кешування одночасно. Після змін очищайте всі рівні кешу.

Реальний сценарій оптимізації

Припустимо, корпоративний сайт має 18 JavaScript-запитів на головній сторінці: 5 — тема і меню, 4 — слайдер і анімації, 3 — форми і карта, 6 — аналітика, пікселі і чат. Початковий мобільний TBT — 920 мс.

Спершу видаляємо два непотрібні анімаційні плагіни, знижуємо обсяг стисненого JS на 140 КБ — TBT падає до 760 мс. Далі застосовуємо defer до скриптів теми і слайдерів, перевіряємо залежності — TBT знижується до 480 мс. Потім карта завантажується лише при прокрутці до контакту, чат запускається через 7 секунд, аналітика і пікселі — як async. Фінальний мобільний TBT — близько 210 мс.

Цей приклад ілюструє, що найкращий результат дає поетапний підхід із видаленням коду, умовним завантаженням і якісною інфраструктурою — а defer і async залишаються потужними інструментами в комплексі.

Висновок: збалансована і перевірена стратегія JavaScript для зниження TBT

Впровадження відкладеного завантаження JavaScript — один із найпростіших і найефективніших способів зменшити TBT. defer забезпечує безпечний послідовний запуск скриптів після DOM, async дає гнучкість для незалежних сторонніх кодів. Успіх залежить від попереднього аналізу, класифікації, видалення зайвих файлів, поступового тестування і моніторингу реального користувацького досвіду.

Використання якісної, швидкої та надійної інфраструктури Hostragons разом із оптимізацією JavaScript, кешуванням та SSL-сертифікатами допоможе досягти стабільного та швидкого завантаження сайту. Якщо хочете покращити TBT вашого ресурсу, почніть з аналізу поточного стану і рухайтесь поступово до цілі. Ознайомтесь із пропозиціями Hostragons щодо хостингу та продуктивності. Hostragons пакети веб-хостингу

Питання та відповіді

Чи можна одночасно використовувати defer і async для одного скрипту?

Якщо в тег <script> додати одночасно defer і async, у сучасних браузерах перевага зазвичай надається async, що позбавляє гарантії порядку виконання. Тому не рекомендується використовувати обидва атрибути одночасно для одного файлу. Для залежних файлів обирайте defer, для незалежних — async.

Чи підвищує відкладене завантаження JavaScript безпосередньо SEO-позиції?

Сам по собі defer або async не гарантують прямого підвищення рейтингу, але покращують взаємодію користувача, швидкість реакції сторінки і метрики Core Web Vitals. Це позитивно впливає на поведінкові фактори і сприйняття сайту пошуковими системами, що у підсумку підтримує SEO.

Чи безпечно додавати defer до всіх JavaScript-файлів?

Ні. Деякі скрипти мають запускатися на ранніх етапах або залежати від порядку. Кожен файл потрібно оцінювати за призначенням, залежностями і часом виконання. Зміни обов’язково тестуйте на тестовому середовищі перед впровадженням.

Чи достатньо лише defer і async для суттєвого зниження TBT?

Для невеликих і середніх сайтів це може дати значний приріст, але для великих проєктів з важкими фреймворками і численними сторонніми скриптами потрібні додаткові заходи: розбиття коду, видалення непотрібного JS, умовне завантаження, кешування та потужний хостинг.

Які скрипти в WordPress не варто робити async?

Скрипти, що залежать від jQuery, а також ті, що відповідають за кошик, оплату, валідацію форм, безпеку і критичні функції теми, не слід робити async, оскільки це може порушити їхню роботу. Спочатку варто спробувати defer, а при необхідності — створити список виключень.