Як знізіць TBT на сайце: Адкладзенае і асінхроннае падключэнне JavaScript у беларускай вэб-інфраструктуры

Адкладзенае падключэнне JavaScript — гэта метад, які дазваляе зменшыць Total Blocking Time (TBT), час блакіроўкі асноўнага патоку ў браўзеры, праз правільнае кіраванне загрузкай і выкананнем скрыптаў. У двух словах: калі вы дадаеце defer або async да некрытычных JS-файлаў, асноўны паток меней блакуецца, карыстальнік хутчэй бачыць старонку і Core Web Vitals паляпшаюцца. Каб рэалізаваць адкладзеную загрузку JS на вашым сайце, спачатку вызначыце, якія скрыпты крытычныя, для залежных — выбірайце defer, для незалежных і трэціх бакоў — async, і пасля змяненняў замярайце TBT праз PageSpeed Insights, Lighthouse і Chrome DevTools.

У сучасных вэб-сайтах праблемы з прадукцыйнасцю часцей звязаны не з малюнкамі, а з некантраляваным JavaScript. На інтэрнэт-краме могуць загружацца фільтры, чат, рэкламныя пікселі, аналітыка, каментары, A/B-тэсты і тэма — усё адначасова. Асноўны паток браўзера заняты, асабліва на мабільных. Карыстальнік бачыць загаловак, але меню не рэагуе, а Lighthouse паказвае высокі TBT.

У гэтым гайдзе мы разбяром, як працуе defer і async, калі іх выкарыстоўваць, як рэалізаваць у WordPress і кастомных праектах, на што звяртаць увагу пры замерах і як атрымаць рэальныя вынікі. Рэкамендацыі для сайтаў на Hostragons адпавядаюць агульным стандартам, плюс разглядаецца ўплыў хостынгу, CDN, SSL і кэшавання на JS-аптымізацыю. Hostragons пакеты веб-хостынгу

Што такое TBT і чаму ён залежыць ад JavaScript?

TBT (Total Blocking Time) — гэта метрыка, якая паказвае, наколькі доўга асноўны паток браўзера блакуецца і затрымлівае гатоўнасць старонкі да ўзаемадзеяння. У Lighthouse, паміж First Contentful Paint і Time to Interactive, усе задачы JS, што перавышаюць 50 мс, павялічваюць TBT. Скажам, JS-файл працуе 180 мс — 130 з іх ідуць у TBT.

Гэта крытычна для досведу карыстальніка: калі ён націскае меню, кошык або пошук, а браўзер яшчэ выконвае JavaScript, узаемадзеянне затрымліваецца. Гэта ўспрымаецца як "замарозка" або некарэктная праца. У SEO-стандартах Google на 2026 год, сайт, што хутка і стабільна рэагуе, мае перавагу ў лаяльнасці і канверсіі.

Сімптомы высокага TBT

• У Mobile PageSpeed Insights TBT перавышае 300 мс.
• У Lighthouse ёсць папярэджанні Reduce JavaScript execution time або Minimize main-thread work.
• Старонка адлюстроўваецца, але меню, слайдэр, фільтр або формы рэагуюць з затрымкай.
• Трэцябаковыя скрыпты (рэклама, чат, аналітыка) маюць высокі кошт у Lighthouse.
• На бюджэтных Android прыладах — затрымкі пры скроле і кліках.

Ідэальная мэта — трымаць TBT ніжэй за 200 мс для кантэнтных сайтаў. На складаных e-commerce або SaaS-гэта зрабіць цяжэй, таму акрамя defer і async патрэбна падзяляць код, выдаляць лішнія пакеты, кэшаваць, аптымізаваць сервер і CSS. Але адкладзенае падключэнне JS — першы і хуткі крок для большасці праектаў.

Што такое Defer і Async?

Па змаўчанні, калі вы дадаеце JS у HTML праз script, браўзер спыняе разбор HTML, загружае, выконвае JS і толькі тады працягвае. Гэта можа быць неабходна для крытычных скрыптаў, але, калі так робяць усюды, — ствараецца лішняе чаканне. Атрыбуты defer і async змяняюць гэтую логіку.

Як працуе defer?

Скрыпт з defer загружаецца ў фонавым рэжыме, пакуль браўзер працягвае разбор HTML. Выконваецца JS пасля таго, як HTML цалкам разабраны. Defer захоўвае парадак скрыптаў, таму для залежных JS — бяспечна. Напрыклад, спачатку бібліятэка, потым скрыпт тэмы — defer падыходзіць.

Прыклад: <script defer src="/js/app.js"></script>. У гэтым выпадку app.js загружаецца без блакіроўкі першай рэндарызацыі, выконваецца пасля гатоўнасці DOM. Defer падтрымліваецца ўсімі сучаснымі браўзерамі і з'яўляецца надзейнай аптымізацыяй для стандартных JS-файлаў.

Як працуе async?

Скрыпт з async таксама загружаецца ў фонавым рэжыме, але выконваецца імгненна пасля загрузкі, незалежна ад разбору HTML. Парадак не гарантуецца — хто першы загрузіўся, той першы выконываецца. Async ідэальны для незалежных скрыптаў — аналітыка, рэклама, пікселі, віджэты.

Прыклад: <script async src="/js/analytics.js"></script>. Важна: analytics.js не павінен залежаць ад іншых скрыптаў, інакш async можа выклікаць памылкі. Таму async — хутка, але патрабуе дакладнай класіфікацыі.

Табліца параўнання defer і async

Практычнае правіла: калі патрэбна захоўваць парадак — пачынайце з defer. Калі скрыпт самастойны — async. Калі не ўпэўнены, спачатку тэстуйце defer на staging, правярайце кансоль і ўзаемадзеянне. Кіраўніцтва па staging асяроддзі і рэзервовым капіраванні

План паэтапнай рэалізацыі адкладзенай загрузкі JavaScript

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

1. Ацэніце бягучую прадукцыйнасць

Перш чым пачаць, зафіксуйце базавыя значэнні: PageSpeed Insights (мабільны/дэсктоп), Lighthouse (TBT, First Contentful Paint, Largest Contentful Paint, Speed Index). У Chrome DevTools паглядзіце main thread: доўгія жоўтыя блокі — гэта JS-працоўка.

Можна зрабіць табліцу: мабільны TBT 780 мс, JS execution time 2,8 с, main-thread work 4,5 с. Пасля аптымізацыі TBT 280 мс — паляпшэнне 64%. Такія дадзеныя дазваляюць камандзе бачыць, што працуе.

2. Скласці інвентар скрыптаў

У кодзе старонкі або сетцы пералічыце ўсе JS-файлы, пазначце крыніцу, памер, патрэбнасць, залежнасці. Падзяліце на групы:

• Крытычныя: для першага выгляду і навігацыі.
• Залежныя лакальныя: тэма, слайдэр, фільтр, галерэя, модулі.
• Незалежныя трэцябаковыя: аналітыка, рэклама, піксель, чат, сац. сеткі.
• Лішнія або састарэлыя: ад непатрэбных плагінаў.
• Умоўныя: толькі на асобных старонках, напрыклад, валідацыя формы.

Лепшая аптымізацыя — не толькі defer, але і выдаленне непатрэбнага скрыпта. 90 KB JS можа дадаваць 300 мс TBT на мабільным. Спачатку вычысціце лішняе, потым прымайце меры па затрымцы.

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

Звычайна гэта асноўная тэма, меню, слайдэр, галерэя, bundle-файлы. Галоўная ўмова: скрыпт не моцна залежыць ад document.write і старых блакіруючых метадаў, і дапушчальна працаваць пасля гатоўнасці DOM.

У WordPress тэмах, напрыклад, jquery-migrate, асноўны тэма-файл і скрыпты плагінаў маюць складаныя залежнасці. Async для jQuery — рызыка, бо многія плагіны чакаюць парадку. Лепш — defer для залежных, або аптымізаваныя загрузкі на ўзроўні плагіна. Кіраўніцтва па аптымізацыі хуткасці WordPress

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

Google Analytics, рэклама, Facebook Pixel, LinkedIn Insight Tag, некаторыя чаты і сац. віджэты — добрыя кандыдаты. Але ў кожнага трэцябаковага скрыпта свае патрабаванні: чат можа ствараць сесію адразу пры загрузцы, рэкламны скрыпт — чакаць кантэйнер. Правярайце дакументацыю.

Async для незалежнай аналітыкі — не шкодзіць досведу. Але для надзейнасці правярайце трыгеры, асабліва калі карыстаецеся Tag Manager: не складвайце ўсе тэгі ў адзіны кантэйнер, а аптымізуйце ўмовы загрузкі. Напрыклад, скрыпт для каментароў не патрэбны на старонках без формы, а скрыпт для прадуктаў — толькі на старонках прадуктаў.

5. Дадайце ўмоўную і падзеевую загрузку

Defer і async — добра, але лепшы вынік дае загрузка JS па падзеях. Напрыклад, чат загружаецца не адразу, а калі карыстальнік прабыў 5 секунд або націснуў "дапамога". Карта — толькі калі карыстальнік скроліць да раздзела кантактаў. Відэа — толькі пры націску "play".

Гэта асабліва эфектыўна для кантэнтных і карпаратыўных сайтаў: не кожны наведвальнік патрэбуе ўсе віджэты. Выдаленне 200 KB JS з пачатковай загрузкі — мінус сотні мс TBT на слабым смартфоне.

6. Тэстуйце і выпускайце паступова

Змены спачатку тэстуйце на staging, а не на live. Праверце ўсе ключавыя старонкі: галоўная, катэгорыя, прадукт, кантакты, увод, аплата. Правярайце кансоль: памылкі "is not defined", "undefined function" — прыкмета парушэння парадку.

На live — рухайцеся невялікімі групамі: спачатку трэцябаковыя скрыпты, потым тэма. Пасля кожнай змены — Lighthouse з аднолькавымі ўмовамі. Не давярайце аднаму замеру; лепш браць сярэдняе з 3-х тэстаў.

Асаблівасці рэалізацыі defer і async у WordPress

У WordPress JS-файлы загружаюцца праз wp_enqueue_script. У сучасных версіях (2026+) можна дакладна кіраваць стратэгіямі загрузкі, але старыя тэмы, page builder'ы і неаптымізаваныя плагіны могуць канфліктаваць.

Калі выкарыстоўваеце performance-плагін, не адкладайце ўсе JS адным клікам — зрабіце whitelist. Крытычныя: аплата, аўтарызацыя, admin bar, security/captcha — патрабуюць асаблівай увагі. На WooCommerce: праверце кошык, payment gateway, variation picker. Рашэнні хостынгу WooCommerce

Практычны парадак: спачатку выдаляйце непатрэбныя плагіны. Потым зрабіце загрузку JS умоўнай — толькі там, дзе трэба. Далей defer для тэма і плагінаў. І ўжо ў канцы — async або адкладзеная загрузка трэцябаковых. Так вы мінімізуеце рызыку масавых паломак.

На што звяртаць увагу ў кастомных і framework-праектах

У React, Vue, Angular, Next.js, Nuxt і іншых сучасных фреймворках аптымізацыя JS — гэта не толькі defer. Тут важныя памер bundle, code splitting, tree shaking, dynamic import і кошт hydration. Калі bundle 700 KB, defer не выратуе ад блакіроўкі main thread.

У кастомных праектах выкарыстоўвайце route-based splitting: на галоўнай не трэба грузіць панэль кіравання, графікі або rich editor. Дынамічна загружайце цяжкія кампаненты. Аналізуйце пакеты — выдаляйце непатрэбнае. Замяняйце вялікія бібліятэкі (date, chart, animation) на лёгкія альтэрнатывы.

У SSR або static-генерацыі таксама трэба быць уважлівым: HTML можа прыйсці хутка, але на этапе hydration сотні кампанентаў запускаюць JS і павышаюць TBT. У неінтэрактыўным кантэнце пазбягайце лішняга client-side JavaScript — гэта галоўны трэнд 2026 года.

Як хостынг і сервер уплываюць на TBT і JS-прадукцыйнасць

TBT залежыць ад JS у браўзеры, але інфраструктура ўплывае ўскосна. Павольны TTFB, адсутнасць сціскання, HTTP/2 або HTTP/3, дрэнны кэш, вялікая адлегласць да сервера — JS-файлы даходзяць пазней, жыццёвы цыкл старонкі расцягваецца, досвед слабы.

Якасны хостынг — Brotli/Gzip сцісканне, эфектыўны кэш, свежы PHP, SSD, CDN, правільны SSL. Гэта павялічвае аптымізацыю. SSL — важна для падтрымкі новых браўзераў, HTTP/2 і бяспекі інтэграцый. Hostragons SSL сертыфікаты Hostragons праверка дамена

Напрыклад, JS-файл без сціскання — 320 KB, з Brotli — 95 KB. Гэта не зніжае TBT прама, бо TBT — выкананне, але скарачае загрузку, палягчае прыярытэт, паляпшае агульны досвед. Defer, async, кэш і хостынг маюць сэнс разам.

Чэк-ліст для замера і валідацыі

• Параўналі TBT да і пасля аптымізацыі на мабільным?
• У JS execution time — паменшылася колькасць цяжкіх файлаў?
• У DevTools — менш доўгіх задач?
• У кансолі — JS-памылкі?
• Меню, пошук, формы, кошык, аплата працуюць стабільна?
• Трэцябаковая аналітыка і рэклама спрацоўваюць правільна?
• INP і затрымкі ў рэальных карыстальнікаў паляпшаюцца?
• Паўторны тэст пасля ачысткі кэша?

Галоўнае: адрознівайце лабараторныя і рэальныя дадзеныя. TBT — Lighthouse-метрыка, але для рэальнага досведу важней Interaction to Next Paint (INP). Зніжэнне TBT звычайна паляпшае INP, бо main thread менш блакуецца.

Тыповыя памылкі і як іх пазбегнуць

Async для ўсіх JS адначасова

Самы распаўсюджаны промах. Async не гарантуе парадак, таму ў залежных скрыптах — памылкі. На некаторых старонках працуе, на іншых, пры павольным інтэрнэце — ламаецца. Для залежных пачынайце з defer.

Няправільнае адкладванне jQuery і плагінаў

У WordPress шмат плагінаў залежаць ад jQuery. Async для jQuery — плагіны могуць не дачакацца загрузкі. Вырашэнне: праглядзець залежнасці і крытычныя JS-файлы ўключыць у whitelist.

Неаптымізаваныя трэцябаковыя скрыпты

Вэб-майстар аптымізуе тэму, але забывае пра рэкламу, чат, аналітыку. У Lighthouse, самыя цяжкія задачы — ад трэціх бакоў. Выдаляйце непатрэбныя тэгі, рабіце ўмоўную загрузку, або адкладайце па падзеях.

Усталёўка плагіна без замера

Performance-плагіны бываюць карысныя, але нярэдка ўносяць дадатковае JS і CSS. Спачатку — дыягназуеце праблему, потым выбіраеце інструмент, і абавязкова правяраеце эфект тэстамі.

Ігнараванне канфліктаў кэша і мініфікацыі

Збіранне, мініфікацыя, defer і async разам — можа парушыць парадак файлаў. На live — нечаканыя памылкі. Калі выкарыстоўваеце CDN, серверны і аплікацыйны кэш — пасля змены ачышчайце ўсе пласты.

Рэалістычны кейс аптымізацыі

Уяўляем карпаратыўны сайт з 18 JS-запытамі на галоўнай: 5 — тэма і меню, 4 — слайдэр і анімацыя, 3 — формы і карта, 6 — аналітыка, пікселі, чат. Стартовы Lighthouse TBT на мабільным — 920 мс.

Крок 1: выдаляюцца два лішніх анімацыйных плагіны (мінус 140 KB JS), TBT — 760 мс. Крок 2: тэма і слайдэр — defer, праверка залежнасцей, TBT — 480 мс. Крок 3: карта грузіцца толькі пры скроле да кантактаў, чат — праз 7 секунд, аналітыка і пікселі — async. Фінальны TBT — 210 мс.

Гэты кейс паказвае: няма чароўнай кнопкі, важны шматпластовы падыход. Defer і async — магутныя інструменты, але максімальны эфект — у камбінацыі з выдаленнем лішняга, умоўнай загрузкай, добрым кэшам і хостынгам.

Вынік: Як збалансаваць і тэставаць стратэгію JavaScript для нізкага TBT

Адкладзенае падключэнне JS — адзін з найбольш эфектыўных і простых спосабаў знізіць TBT. Defer — бяспечна для залежных і пасля DOM, async — ідэальна для незалежных трэцябаковых. Паспяховая аптымізацыя: спачатку замеры, класіфікацыя скрыптаў, выдаленне лішняга, паступовыя змены, маніторынг рэальнага досведу.

Хуткая, бяспечная і маштабаваная інфраструктура Hostragons дапамагае дасягнуць стабільнай прадукцыйнасці: JS-аптымізацыя, кэш, SSL — у комплексе. Каб палепшыць TBT, спачатку зафіксуйце свой бягучы вынік, потым рухайцеся маленькімі, але прыкметнымі крокамі. Для выбару хостынгу і прадукцыйнасці — праверце Hostragons. Hostragons пакеты веб-хостынгу

Частыя пытанні

Ці можна выкарыстоўваць defer і async адначасова?

Калі дадаць defer і async да аднаго script, браўзеры аддаюць перавагу async, што парушае парадак. Таму не рэкамендуецца выкарыстоўваць абодва разам. Для залежных — defer, для незалежных — async.

Ці паляпшае адкладзенае падключэнне JS SEO непасрэдна?

Само па сабе — не гарантуе росту ў ранжыраванні. Але паляпшае досвед, хуткасць узаемадзеяння і Core Web Vitals, што спрыяе SEO. Хуткія сайты — лепшая якасць, канверсія, больш высокая ацэнка crawler'амі.

Ці можна дадаваць defer да ўсіх JS?

Не. Некаторыя скрыпты павінны працаваць у першым этапе або патрабуюць строгага парадку загрузкі. Таму перад зменамі — праверце прызначэнне, залежнасці, час запуску, і абавязкова тэстуйце.

Ці дастаткова defer і async, каб знізіць TBT?

На малых і сярэдніх сайтах — так, эфект вялікі. Але ў цяжкіх фреймворках, з вялікімі bundle і трэцябаковымі скрыптамі, патрэбны дадатковыя меры: code splitting, выдаленне лішняга JS, умоўная загрузка, кэш і добры хостынг.

Якія JS-файлы не варта рабіць async у WordPress?

Залежныя ад jQuery плагіны, скрыпты аплаты і кошыка, валідацыя формы, бяспека, крытычныя функцыі тэмы — не варта рабіць async. Калі парушыцца парадак — карыстальнік сутыкнецца з праблемамі. Спачатку defer, калі трэба — whitelist для выключэння.