Hogyan csökkentsük a Total Blocking Time (TBT) értékét késleltetett JavaScript betöltéssel (defer/async) a weboldaladon

A késleltetett JavaScript betöltés (defer vagy async) egy hatékony módszer arra, hogy optimalizáljuk a weboldalunk teljesítményét azáltal, hogy a JavaScript fájlok futtatását úgy időzítjük, hogy ne blokkolják a böngésző tartalom megjelenítését. Egyszerűbben fogalmazva: a nem kritikus szkriptek defer vagy async attribútummal való ellátásával csökkenthetjük az úgynevezett Total Blocking Time (TBT) értékét. Ez azt jelenti, hogy a fő végrehajtási szál kevesebbet akad, a felhasználók gyorsabban láthatják az oldalt, hamarabb tudnak interakcióba lépni vele, és javulnak a Core Web Vitals mérőszámai. A késleltetett JavaScript betöltés implementálásakor először meg kell határozni, mely fájlok kritikusak, majd a függőségekkel rendelkező szkripteknél a defer, míg a független, külső kódoknál inkább az async használata javasolt. Végül érdemes a változtatások után a PageSpeed Insights, Lighthouse és a Chrome DevTools segítségével mérni a TBT értékét.

A modern weboldalak teljesítményproblémái sokszor nem a képek miatt, hanem a kontrollálatlan JavaScript használat miatt jelentkeznek. Egy webáruházban például, ha egyszerre töltődnek be a termékszűrők, élő chat, reklám pixelek, elemző kódok, komment pluginok, A/B teszt eszközök és a témához tartozó szkriptek, akkor a böngésző fő végrehajtási szála hosszú időre leterhelődik. Ez a jelenség különösen a mobil eszközökön érzékelhető. Lehet, hogy a felhasználó látja a fejlécet, de amikor a menüre vagy egy gombra kattint, nem reagál a weboldal; a Lighthouse jelentésben pedig magas TBT érték jelenik meg.

Ebben az útmutatóban lépésről lépésre bemutatjuk, hogy mit csinálnak a defer és async attribútumok, mikor melyiket érdemes használni, hogyan alkalmazhatók WordPress és egyedi fejlesztésű oldalak esetében, milyen szempontokat vegyünk figyelembe a mérésnél, és milyen reális TBT javulások érhetők el. A Hostragons infrastruktúráján futó weboldalakra vonatkozó javaslatok megfelelnek a széles körben elfogadott webes szabványoknak. Emellett kitérünk arra is, hogy a megfelelő tárhelyszolgáltatás, CDN, SSL és gyorsítótárazási beállítások hogyan segítik elő a JavaScript optimalizációt. Hostragons web hosting csomagok

Mi az a Total Blocking Time (TBT) és miért fontos a JavaScript szempontjából?

A TBT, vagyis Total Blocking Time azt méri, hogy mennyi ideig akadályozza a fő végrehajtási szál a felhasználói interakciót egy oldal betöltése közben. A Lighthouse laboratóriumi tesztjeiben ez a First Contentful Paint és a Time to Interactive közötti időszakban 50 ms-nál hosszabb feladatok összegeként jelenik meg. Például, ha egy JavaScript feladat 180 ms-ig fut, akkor a 130 ms (az első 50 ms után) hozzáadódik a TBT értékhez.

Ez a mérőszám kulcsfontosságú a felhasználói élmény szempontjából, mert ha a látogató az oldal megjelenése után megpróbál kattintani a menüre, a kosár gombra vagy a keresőmezőbe, de a böngésző még mindig JavaScriptet futtat, a reakció késik. A felhasználó ilyenkor lefagyott vagy lassú weboldalnak érzékeli az oldalt. A 2026-os SEO irányelvek szerint a Google nem csak egyetlen mutató alapján értékeli az oldalt, de a gyors és stabil interakciót kínáló webhelyek mind a felhasználói elégedettség, mind a konverziós arány szempontjából előnyt élveznek.

Magas TBT jelei

• A mobil PageSpeed Insights jelentésben a TBT értéke 300 ms fölé emelkedik.
• A Lighthouse jelentésben „Reduce JavaScript execution time” vagy „Minimize main-thread work” figyelmeztetések jelennek meg.
• Az oldal már megjelenik, de a menü, a slider, a szűrők vagy a űrlapmezők lassan reagálnak.
• Külső hirdetés, élő chat vagy elemző szkriptek magas erőforrás-felhasználással bírnak a jelentésben.
• Különösen belépőszintű Android készülékeken késések tapasztalhatók a görgetés és a kattintás során.

Általánosan elfogadott cél, hogy a TBT érték 200 ms alatt maradjon a legtöbb tartalomalapú oldal esetében. Komplexebb webáruházaknál vagy SaaS felületeknél a defer és async önmagukban nem mindig elegendőek: szükséges lehet a kód szeletelése, felesleges csomagok eltávolítása, gyorsítótárazás, szerver válaszidő javítása és kritikus CSS optimalizálása is. Mindezek mellett a késleltetett JavaScript betöltés az egyik leggyorsabban alkalmazható és látványos eredményt hozó lépés.

Mi az a defer és async attribútum?

Amikor egy <script> tageket alapértelmezetten használunk, a böngésző megállítja az HTML feldolgozást, letölti és futtatja a JavaScript fájlt, majd folytatja a lap felépítését. Ez kritikus szkriptek esetén szükséges lehet, ám ha minden fájlt így kezelünk, felesleges várakozást okozunk. A defer és async attribútumok megváltoztatják ezt a folyamatot azáltal, hogy más szabályok szerint kezelik a letöltést és futtatást.

Hogyan működik a defer?

A defer attribútumot kapott szkript a HTML feldolgozás közben háttérben töltődik le, de csak azután fut le, hogy a teljes HTML dokumentum be lett fejezve. Több defer szkript esetén a futtatási sorrend megegyezik a HTML-ben való elhelyezkedésükkel, tehát a függőségi sorrend megmarad. Ezért függőségekkel rendelkező szkriptek esetén a defer biztonságos megoldás. Például ha először egy könyvtár, majd annak függvényei futnak, akkor a defer alkalmazása ajánlott.

Például így használjuk: <script defer src="/js/app.js"></script>. Ebben az esetben az app.js nem akadályozza az oldal első kirajzolását, és a DOM készenlétének pillanatában, a helyes sorrendben fut le. A modern böngészők széles körben támogatják a defer attribútumot, így ez egy megbízható optimalizációs eszköz.

Hogyan működik az async?

Az async attribútummal ellátott szkript szintén a HTML feldolgozás közben töltődik le, de futtatása rögtön elindul, amint a letöltés véget ér, akár még a HTML feldolgozás előtt is megállíthatja a feldolgozást. Az async nem garantálja a futási sorrendet: amelyik fájl előbb töltődik le, az fut először. Ezért független, külső kódok – például elemzők, hirdetési pixelek vagy közösségi média widgetek – számára ideális.

Például: <script async src="/js/analytics.js"></script>. Ilyenkor az analytics.js nem vár más helyi szkriptekre. Ha azonban az analytics.js egy később definiált változóra vagy jQuery könyvtárra támaszkodik, az async használata hibákat okozhat. Az async gyors, de körültekintést igényel a megfelelő besorolás során.

Defer és Async összehasonlító táblázat

Alapvető szabály: ha a fájlnak meg kell őriznie a sorrendjét, kezdjük a deferrel. Ha teljesen független, fontoljuk meg az async használatát. Ha bizonytalanok vagyunk, először egy teszt környezetben próbáljuk ki a defert, és ellenőrizzük a konzol hibáit, illetve a kritikus interakciókat. Előkészítő környezet és biztonsági másolat Útmutató

Lépésről lépésre: késleltetett JavaScript betöltés bevezetése

Nem ajánlott minden szkriptet véletlenszerűen defer vagy async attribútummal ellátni, mert rövid távon javulhat a pontszám, de a termékoldal, a keresés, a menü, az űrlapok vagy a kosár funkciói hibásan működhetnek. Az egészséges megközelítés a mérés, osztályozás, apró módosítások, tesztelés és monitorozás ciklikus folyamata.

1. Teljesítmény alapértékek mérése

Mielőtt bármit változtatnánk, készítsünk alapméréseket. A PageSpeed Insights-szal jegyezzük fel a mobil és asztali pontszámokat. A Lighthouse jelentésből rögzítsük a TBT, First Contentful Paint, Largest Contentful Paint és Speed Index értékeket. A Chrome DevTools Performance fülén vizsgáljuk meg a fő végrehajtási szálat; a hosszú sárga blokkok általában a JavaScript feldolgozás és futtatás költségét mutatják.

Jó gyakorlat egy induló táblázat készítése, például: mobil TBT 780 ms, JavaScript futási idő 2,8 másodperc, fő szál tevékenység 4,5 másodperc. Ha optimalizáció után a TBT 280 ms-ra csökken, akkor kb. 64%-os javulás érhető el. Az ilyen konkrét adatok megkönnyítik a csapat számára, hogy mely lépések voltak hatékonyak.

2. JavaScript fájlok listázása

A forráskód vagy a hálózati fül segítségével listázzuk az összes betöltött JavaScript fájlt. Határozzuk meg mindegyik eredetét, méretét, mikor van rá szükség, és milyen függőségei vannak. Csoportosítsuk őket az alábbi kategóriákba:

• Kritikus szkriptek: az első megjelenítéshez vagy alap navigációhoz szükséges kódok.
• Függő helyi szkriptek: téma, slider, szűrő, galéria és alkalmazás modulok.
• Független harmadik féltől származó szkriptek: elemzők, reklámok, pixelek, chat és közösségi média komponensek.
• Felesleges vagy elavult szkriptek: nem használt bővítményekből maradt fájlok.
• Feltételesen betöltendő szkriptek: például csak az űrlapot ellenőrző kód a kapcsolat oldalon.

Az optimalizálás során gyakran nem a defer hozzáadása a legjobb megoldás, hanem olyan szkriptek eltávolítása, amelyekre nincs is szükség. Egy 90 KB-os tömörített fájl mobilon több mint 300 ms többletterhelést okozhat a feldolgozás és futtatás miatt. Ezért először a felesleges kódokat töröljük, majd a maradékot késleltetjük.

3. Deferrel ellátandó fájlok kiválasztása

Általában a fő téma szkriptek, menü viselkedések, slider kódok, termék galéria modulok és alkalmazás csomagok jó jelöltek a deferhez. Fontos azonban, hogy a szkript ne használjon olyan blokkoló technikákat, mint a document.write, és elfogadható legyen, ha a futtatás a DOM készenléte után történik.

Egy WordPress témában például a jquery-migrate, a fő téma fájl és a bővítmény szkriptek összetett függőségi hálót alkothatnak. A jQuery async-re állítása általában kockázatos, mert a bővítmények gyakran az adott sorrendre támaszkodnak. Ilyenkor a kontrollált defer használata vagy a bővítmény szintű optimalizált betöltési opciók alkalmazása biztonságosabb választás. WordPress sebesség optimalizálási útmutató

4. Async-re alkalmas fájlok kiválasztása

Google Analytics, reklámkódok, Facebook Pixel, LinkedIn Insight Tag, bizonyos külső chat widgetek, és közösségi megosztó kódok tipikusan async használatra alkalmasak. Azonban nem minden harmadik féltől származó szkript egyforma. Egyes élő chat eszközök például azonnal megpróbálhatnak felhasználói munkamenetet létrehozni, míg más hirdetési rendszerek meghatározott konténer sorrendet várhatnak el. Ezért mindig ellenőrizzük a dokumentációt.

Az önálló elemző kód async-re állítása általában nem rontja a felhasználói élményt. Az adatvesztés kockázatának csökkentése érdekében valós idejű riportok esetén ellenőrizzük a triggerelés helyességét. Ha címke kezelőt használunk, ne pakoljuk egyetlen konténerbe az összes címkét, hanem állítsunk be megfelelő feltételeket. Például komment űrlap nélküli oldalakon ne töltsük be a komment követő szkriptet, termékoldal nélküli oldalakon pedig a termék interakció követőt.

5. Feltételes és esemény alapú betöltés

A defer és async csak a kiinduló lépés. Haladóbb megoldás, ha a JavaScript kódokat a felhasználói viselkedéshez igazítjuk. Például az élő chat nem az oldal megnyitásakor töltődik be, hanem csak ha a látogató legalább 5 másodpercet eltöltött vagy megnyomta a segítség gombot. A térkép beágyazás csak akkor töltődik, ha a felhasználó az elérhetőségi szakaszra görget. A videólejátszó szkript pedig csak a lejátszás gomb megnyomásakor indul el.

Ez a megoldás különösen hatékony tartalomoldalak és vállalati weboldalak esetén, ahol a látogatók nem használnak minden widgetet minden oldalon. 200 KB JavaScript eltávolítása az első betöltésből gyengébb mobil eszközökön akár több száz milliszekundummal is csökkentheti a TBT értékét.

6. Tesztelés és fokozatos bevezetés

Ne a termelési oldalon kezdjük az átalakítást, hanem először egy tesztkörnyezetben próbáljuk ki. Manuálisan teszteljük az olyan kritikus oldalakat, mint a kezdőlap, kategóriaoldalak, termék- vagy szolgáltatásoldalak, kapcsolat oldal, belépési és fizetési folyamatok. Figyeljük a böngésző konzolját hibák után, különösen a „Cannot read property”, „is not defined”, vagy „undefined function” típusú hibákat, amelyek a függőségi problémákra utalhatnak.

Az élesítésnél lépjünk fokozatosan: először a független harmadik fél szkripteket optimalizáljuk, majd a témához tartozó szkripteket. Minden változtatás után futtassuk le újra a Lighthouse teszteket azonos hálózati és eszköz szimulációval. Ne csak egy mérést vegyünk figyelembe, hanem átlagoljunk legalább három futtatást a pontosabb eredményért.

Defer és Async használata WordPress oldalakon

A WordPress rendszerben a JavaScript fájlok többsége a wp_enqueue_script funkción keresztül töltődik be, amit a témák és bővítmények használnak. 2026-ra a modern WordPress verziók már részletesebben támogatják a script betöltési stratégiákat, de az elavult témák, oldalépítő bővítmények és inkompatibilis optimalizációs pluginok konfliktusokat okozhatnak.

Ha teljesítménybővítményt használunk, ne csak egy kattintással állítsuk be az összes szkript késleltetését, hanem hozzunk létre kizárási listát. Például a fizetési oldalak, bejelentkezési űrlapok, adminisztrációs sáv, biztonsági ellenőrző és captcha szkriptek érzékenyek lehetnek. WooCommerce esetén a kosár fragmentek, fizetési átjárók és variáns kiválasztók különösen tesztelésre szorulnak. WooCommerce hosting megoldások

Gyakorlati sorrend lehet: először távolítsuk el a nem használt bővítményeket, majd tegyük feltételessé azokat a bővítmény fájlokat, amelyek csak bizonyos oldalakon kellenek. Utána próbáljuk ki a defert a téma és bővítmény szkripteken, végül a független harmadik féltől származó kódokon alkalmazzuk az async vagy késleltetett betöltést. Ez a módszer csökkenti a nagy hibák kockázatát.

Figyelmeztetések egyedi fejlesztésű és keretrendszeres projektek esetén

React, Vue, Angular, Next.js, Nuxt és hasonló modern frontend keretrendszerek esetén a JavaScript optimalizáció nem merül ki egy defer attribútum hozzáadásában. A csomagméret, a code splitting, tree shaking, dinamikus importálás és a hydration költségei alapvetően befolyásolják a TBT-t. Egy 700 KB-os nagy csomag esetén még a defer sem akadályozza meg, hogy a fő szál sokáig foglalt legyen a futtatás alatt.

Egyedi fejlesztéseknél ajánlott route-alapú kód szeletelést alkalmazni: amikor a felhasználó az oldal főoldalán tartózkodik, ne töltődjön be az admin panel, grafikon könyvtár vagy egy összetett szerkesztő kódja. Nehéz komponenseket dinamikusan importáljunk csak akkor, amikor szükség van rájuk. Felesleges függőségeket csomagelemző eszközökkel keressünk meg és távolítsunk el. Nagy méretű dátumkezelő, grafikon vagy animációs könyvtárak helyett keressünk könnyebb alternatívákat.

Ha szerver oldali renderelést vagy statikus generálást használunk, vigyázzunk arra, hogy a hidratáció során ne aktiválódjon egyszerre túl sok komponens, mert az megemelheti a TBT értékét. A nem interaktív tartalmaknál kerüljük az indokolatlan kliens oldali JavaScriptet, mert ez a 2026-os teljesítménykövetelmények központi eleme.

Tárhely, szerver válaszidő és JavaScript teljesítmény összefüggése

Bár a TBT alapvetően a böngészőben futó JavaScript végrehajtási időt méri, a tárhely és a szerver oldali beállítások közvetetten jelentősen befolyásolják az eredményt. A lassú TTFB (Time To First Byte), a tömörítés hiánya, HTTP/2 vagy HTTP/3 támogatás hiánya, nem megfelelő gyorsítótárazás és a távoli szerverek okozta késések mind meghosszabbíthatják a JavaScript fájlok elérését. Ezáltal nő az oldal betöltési ideje és romlik a felhasználói élmény.

Minőségi tárhelyszolgáltatás, Brotli vagy Gzip tömörítés, hatékony böngészői gyorsítótár, naprakész PHP verzió, gyors lemeztechnológia és CDN integráció mind elősegítik a JavaScript optimalizációt. Az SSL tanúsítvány helyes telepítése szintén kulcsfontosságú, hiszen ez támogatja a modern böngészői funkciókat, a HTTP/2-t és a biztonságos harmadik féltől származó integrációkat. Hostragons SSL tanúsítványok Hostragons domain ellenőrzés

Például egy tömörítetlen 320 KB-os JavaScript fájl Brotlival akár 95 KB-ra is csökkenhet. Ez a méretcsökkenés nem csökkenti egy az egyben a TBT-t, mert a TBT a futtatás költségét méri, de lerövidül a letöltési idő, könnyebb a forráspriorizálás, és összességében javul a betöltési élmény. Ezért a defer, async, gyorsítótárazás és megfelelő tárhely együttes alkalmazása szükséges a legjobb eredményhez.

Mérés és ellenőrzés ellenőrző lista

Nem elég csak a PageSpeed pontszámra hagyatkozni az optimalizáció sikerének megítéléséhez. Az alábbi lista segít valós eredményeket értékelni:

• Összehasonlítottuk-e a mobil TBT értékeket a módosítások előtt és után?
• Csökkent-e a JavaScript futtatási idő a legdrágább fájlok esetén?
• Csökkent-e a hosszú futású feladatok száma a Chrome DevTools Performance nézetében?
• Van-e JavaScript hiba a konzolon?
• Menük, kereső, szűrők, űrlapok, kosár és fizetés zökkenőmentesen működnek?
• Harmadik féltől származó elemző és reklám kódok megfelelően indulnak?
• Valós felhasználói adatokban (pl. INP) javultak az interakciós késések?
• Tisztítás után újra teszteltük a gyorsítótárat?

Fontos megkülönböztetni a laboratóriumi és valós felhasználói adatokat. A TBT laboratóriumban mért mutató, míg a valós élményben az Interaction to Next Paint (INP) vált egyre meghatározóbbá. Azonban a TBT csökkenése általában javítja az INP-t is, hiszen kevesebb a blokkolás a fő végrehajtási szálon.

Gyakori hibák és elkerülésük

Minden szkriptet async-re állítani egyszerre

Ez az egyik leggyakoribb hiba. Az async nem garantál sorrendet, így a függőségi láncok esetén véletlenszerű hibák jelentkezhetnek. Ami egy adott böngészőn vagy lassú hálózaton jól működik, más környezetben összeomolhat. Függőségek esetén a defer biztonságosabb választás.

jQuery és függő bővítmények helytelen késleltetése

Különösen WordPress oldalakon jellemző, hogy sok bővítmény függ a jQuery-től. A jQuery async-re állítása miatt az ezzel függő kódok hibásan működhetnek, mert a jQuery még nem töltődött be. Megoldásként a függőségi háló feltérképezése és a kritikus fájlok kizárása javasolt.

Külső szkriptek ellenőrizetlen kezelése

Gyakran előfordul, hogy a weboldal tulajdonosa csak a saját témáját optimalizálja, miközben a reklám, chat vagy elemző kódokat elhanyagolja. Pedig a Lighthouse jelentésekben a legnagyobb költségű feladatok legtöbbször a harmadik féltől származó forrásokból erednek. Ezek eltávolítása, feltételes betöltése vagy késleltetése jelentős javulást hozhat.

Mérés nélkül új bővítmények telepítése

Teljesítménybővítmények hasznosak lehetnek, de mérés nélkül minden új eszköz további JavaScript és CSS terhelést hozhat. Mielőtt bevezetünk egy eszközt, diagnosztizáljuk a problémát, majd utána válasszuk ki a megfelelőt, és teszteljük, hogy valóban csökkenti-e a TBT-t.

Gyorsítótár és minifikáció nem összehangolt használata

Ha minifikáció, összevonás, defer és async egyidejűleg kerül alkalmazásra, megváltozhat a fájlok sorrendje, ami váratlan hibákhoz vezethet. Különösen fontos, hogy a CDN, szerver és alkalmazás szintű gyorsítótárakat a változtatások után teljesen töröljük és frissítsük.

Egy reális optimalizációs példa

Tegyük fel, hogy egy közepes méretű vállalati weboldalon a főoldalon 18 JavaScript hívás történik. Ezek közül 5 a téma és menü viselkedéséért felel, 4 slider és animáció, 3 űrlap és térkép modul, 6 pedig elemző, pixel és élő chat kód. A kezdeti Lighthouse mobil TBT érték 920 ms.

Első lépésként eltávolítanak két nem használt animációs bővítményt és 140 KB tömörített JavaScript méret csökkenést érnek el, ami a TBT-t 760 ms-ra csökkenti. Második lépésben a téma és slider fájlokat defer attribútummal látják el, és tesztelik a függőségeket; ekkor a TBT 480 ms-ra csökken. Harmadik lépésként a térkép script csak a kapcsolat szakasznál töltődik be, az élő chat 7 másodperc késéssel indul, az elemző és pixel kódokat async-szal látják el. Végül a TBT érték 210 ms-ra javul.

Ez a példa jól mutatja, hogy nem egyetlen varázslatos beállítás hozza az eredményt, hanem a rétegezett megközelítés. A defer és async erős eszközök, de a legjobb eredményhez elengedhetetlen a felesleges kód eltávolítása, feltételes betöltés, gyorsítótárazás és minőségi tárhelyszolgáltatás együttes alkalmazása.

Összegzés: kiegyensúlyozott és tesztelt JavaScript stratégia a TBT csökkentéséhez

A késleltetett JavaScript betöltés alkalmazása az egyik legegyszerűbb és leghatékonyabb módja a TBT érték csökkentésének. A defer azokra a fájlokra ideális, amelyeknek meg kell őrizniük a sorrendet és a DOM készültségét igénylik, míg az async a független harmadik féltől származó szkriptek rugalmas betöltésére alkalmas. Egy sikeres optimalizációhoz elengedhetetlen a mérés, osztályozás, felesleges fájlok eltávolítása, fokozatos tesztelés és a valós felhasználói élmény monitorozása.

A Hostragons gyors, biztonságos és skálázható infrastruktúrája a JavaScript optimalizáció, gyorsítótárazás és SSL konfigurációk mellett stabilabb webes teljesítményt biztosít. Ha szeretnéd javítani az oldalad TBT értékét, először készíts részletes jelentést, majd lépésről lépésre haladj a kisebb, mérhető fejlesztésekkel. Tárhely és teljesítmény megoldásokért tekintsd meg a Hostragons ajánlatait. Hostragons web hosting csomagok

Gyakran Ismételt Kérdések

Lehet-e egyszerre használni a defer és az async attribútumot egy script elemen?

Ha egy klasszikus <script> elemen egyszerre adjuk meg a defer és az async attribútumot, a modern böngészők általában az async viselkedést alkalmazzák, ami megszünteti a futási sorrend garanciáját. Ezért nem ajánlott mindkettőt egyszerre használni ugyanazon fájlon. Függőségek esetén a defer, független fájloknál pedig az async a biztonságosabb megoldás.

Javítja-e a késleltetett JavaScript betöltés közvetlenül a SEO helyezést?

Önállóan nem garantálja a jobb helyezést, de jelentősen javítja a felhasználói élményt, a betöltési sebességet és a Core Web Vitals mutatókat. Ezek pedig hozzájárulnak a Google rangsorolási tényezőihez, így hosszú távon támogatják az SEO sikerét. Gyorsabb, stabilabb oldalak több elégedett látogatót és jobb konverziókat eredményeznek.

Biztonságos minden JavaScript fájlra rátenni a defer attribútumot?

Nem. Vannak olyan szkriptek, amelyeknek az oldal korai fázisában kell lefutniuk, vagy amelyek más fájlok meghatározott sorrendjéhez kötöttek. Ezért minden fájl célját, függőségét és futási idejét alaposan át kell tekinteni, és az esetleges változtatásokat tesztkörnyezetben kell kipróbálni.

Elég a TBT csökkentéséhez csak a defer és az async beállítása?

Kisebb és közepes méretű oldalak esetében jelentős javulást hozhatnak, de nagy, keretrendszer-alapú vagy sok harmadik féltől származó kódot tartalmazó oldalaknál további lépések szükségesek, például kódszeletelés, felesleges JavaScript eltávolítása, feltételes betöltések, gyorsítótárazás és megbízható tárhely használata.

Mely szkripteket ne tegyek async-re WordPress oldalon?

A jQuery-függő bővítmények, fizetési és kosár szkriptek, űrlap- és biztonsági ellenőrző kódok nem alkalmasak véletlenszerű async használatra. Ezeknél fennáll a sorrendi zavar és a hibás működés veszélye. Először inkább deferrel próbáljuk meg, vagy készítsünk kizárási listát.