Sebesség Szakszó

TBT (Total Blocking Time)

Szerző: · 8 perc olvasás · Frissítve:
TBT (Total Blocking Time) - Sebesség (szakszó) a tudástárban
TBT (Total Blocking Time) - Sebesség | eClick GEO-audit tudástár

A TBT (Total Blocking Time) az az összesített idő, amíg a böngésző fő szála hosszú feladatokkal van elfoglalva, és nem tud válaszolni a felhasználó kattintására. A mérés a First Contentful Paint és a interaktívvá válás között zajlik: minden 50 ezredmásodpercnél hosszabb feladatból az 50 ms feletti részt számolja össze.

Hogyan működik

A JavaScript egy szálon fut. Amíg egy szkript dolgozik, a böngésző nem tud mást csinálni. Nem reagál kattintásra, nem futtat animációt, nem rajzol újra.

Ha egy feladat 180 ms-ig tart, abból 130 ms számít blokkoló időnek. Ha öt ilyen feladat van egymás után, az már 650 ms TBT. A Lighthouse ezt méri labor-környezetben, szimulált lassítással.

Mik a küszöbök

A Lighthouse pontozása mobil emulációval dolgozik. A határok:

  • 0-200 ms: zöld, jó
  • 200-600 ms: narancs, javításra szorul
  • 600 ms felett: piros, gyenge

A TBT a Lighthouse teljesítmény-pontszám 30%-át adja. Egyetlen metrika sem nyom ennyit a latba.

Mi a kapcsolata az INP-vel

A TBT labor-metrika, az INP (Interaction to Next Paint) mezei metrika. A TBT azt méri, mennyire lenne akadozó az oldal, az INP azt, mennyire volt akadozó valódi felhasználóknál.

A kettő között erős, de nem tökéletes az összefüggés. A riportokban rendszeresen látunk 700 ms TBT mellett elfogadható INP-t. Ez akkor fordul elő, ha a felhasználó nem az első két másodpercben kattint. Fordítva ritkább: magas TBT mellett a rossz INP inkább szabály, mint kivétel.

Miért számít a generatív keresőknek

A nyelvi modellek crawlerei nem kattintanak. Számukra a TBT közvetlenül nem releváns. Közvetve viszont igen: ami blokkolja a fő szálat, az általában sok JavaScript, és a sok JavaScript gyakran kliensoldalon renderelt tartalmat jelent. Az AI-crawlerek többsége nem futtat JavaScriptet.

Röviden: a TBT azt mutatja meg, mennyi ideig halott az oldalad, miközben a felhasználó már látja.

Miért fontos

Felhasználói oldalról

A magas TBT a legfrusztrálóbb hibatípus. Az oldal kirajzolódik, a gomb látszik, a felhasználó rákattint, és nem történik semmi. Sokan kétszer-háromszor is kattintanak. Webshopban ez duplikált kosárba tételt vagy dupla megrendelést okoz.

Rangsorolási hatás

A Core Web Vitals része az INP (Interaction to Next Paint), nem a TBT. A TBT viszont a legjobb labor-előrejelzője az INP-nek. Ha a TBT-t leviszed, az INP is javul.

A rangsorolásban az élmény-jelek nem döntőek. Hasonló tartalmi erősségű oldalak között viszont számítanak.

Üzleti következmény

A magas TBT jellemzően sok harmadik féltől származó szkriptből jön. Ezek mérnek, követnek, personalizálnak. A magyar KKV-oldalak többségén öt-tíz ilyen szkript fut egyszerre, és a felét senki nem nézi meg soha.

A Google Tag Manager konténerekben találtunk már olyan címkét, amit három éve leállított kampányhoz raktak be. Még mindig töltődött.

Kikre vonatkozik

Kikre vonatkozik

  • Minden JavaScript-nehéz oldal: React, Vue, Angular alapú frontendek, SPA-k
  • Webshopok: a termékoldalakon általában a legtöbb a szkript
  • WordPress-oldalak sok pluginnal: minden plugin hozhat saját JS-t
  • Mérőkódokkal telepakolt oldalak: Google Tag Manager (GTM), Meta Pixel, hőtérképek, chat-widgetek

Kikre kevésbé

A statikus, szerveroldalon generált oldalak ritkán küzdenek magas TBT-vel. Egy sima blogbejegyzés minimális JavaScripttel jellemzően 0-50 ms körül van.

Staging és fejlesztői környezetben a mérés félrevezető lehet. A development build forrástérképekkel és nem minifikált kóddal fut. Mindig éles buildet mérj.

Eszköz-függés

A TBT erősen függ a mérő eszköz teljesítményétől. Ugyanaz az oldal asztali gépen 80 ms, közepes Android-telefonon 900 ms. A PageSpeed Insights mobil nézete lassított CPU-val szimulál, ezért mutat magasabb értéket.

Hogyan ellenőrzöd

Lépések

  1. Nyisd meg a PageSpeed Insights oldalát, írd be az URL-t. A TBT a Performance blokk diagnosztikai metrikái között szerepel.
  2. Váltsd át Mobil nézetre. A mobil érték a mérvadó.
  3. Böngésző devtools: Lighthouse fül, Performance kategória, Mobile eszköz, Analyze page load.
  4. Ha magas az érték, nyisd meg a Performance fület a devtoolsban. Indíts felvételt újratöltéssel.
  5. A Main track sávban keresd a piros sarkú blokkokat. Ezek a long task-ok. Kattints rájuk, a Summary panel megmutatja, melyik fájl hívta.
  6. A Lighthouse riport Reduce JavaScript execution time és Minimize main-thread work pontjai fájlonként bontva mutatják az időt.

Jó jel

  • TBT 200 ms alatt mobil emulációval
  • Egyetlen long task sem haladja meg a 150 ms-ot
  • A JavaScript végrehajtási idő 2 másodperc alatt van
  • A harmadik féltől jövő szkriptek összesített ideje 500 ms alatt marad

Rossz jel

  • TBT 600 ms felett
  • Egy-két óriási, 500 ms feletti feladat a Performance idővonalon
  • A Lighthouse a Third-party usage pontnál 10-nél több domaint sorol fel
  • A long task-ok döntő része nem a saját kódodból jön

Mit néz ebből a riport

Az audit a Lighthouse mérés TBT-értékét olvassa ki, és a Lighthouse küszöbeihez méri. Ha 600 ms felett van, jelzi, és a legnagyobb végrehajtási idejű szkripteket is kiírja. A riport emellett összeveti a mezei INP (Interaction to Next Paint)-adattal, ha van ilyen a CrUX adatbázisban.

Hogyan javítod

WordPress

  1. Nézd végig a bővítményeket. Minden aktív pluginnál kérdezd meg: használja-e valaki?
  2. Telepíts egy asset-kezelőt (Perfmatters, Asset CleanUp). Ezekkel oldalanként kikapcsolhatod a felesleges JS-fájlokat. A kapcsolati űrlap szkriptje nem kell a főoldalra.
  3. Kapcsold be a JavaScript késleltetését. A cache-pluginok (WP Rocket, LiteSpeed Cache) kínálnak Delay JavaScript execution opciót. Ez az első felhasználói interakcióig visszatartja a szkripteket.
  4. Nézd át a slidereket és animációs könyvtárakat. Egy Revolution Slider önmagában 300-400 ms TBT-t hozhat.
  5. A page builder (Elementor, Divi) alap JS-készletét nem tudod kikapcsolni, de a felesleges widgeteket igen.

Shopify

  1. Online Store > Themes > Customize, nézd át az app-blokkokat. A nem használt appokat távolítsd el, ne csak kapcsold ki.
  2. A törölt appok gyakran hagynak szkript-maradványt a theme.liquid fájlban. Keresd rá az app nevére a kódszerkesztőben.
  3. Settings > Customer events: itt látod a pixeleket. A duplikált mérőkódokat vedd ki.
  4. Ha egyedi appot fejlesztesz, használj Web Pixels API-t. Az a főszáltól elkülönített sandboxban fut.

Unas

  1. Beállítások > Külső szolgáltatások: itt vannak a beillesztett kódok. Minden tételt nézz végig.
  2. A saját HTML-blokkokba írt szkripteket lásd el defer attribútummal.
  3. A sablon JavaScriptjéhez korlátozottan férsz hozzá. A beavatkozási pont a saját kód és a külső szolgáltatások listája.

Shoprenter

  1. Kinézet > Sablonkezelő, keresd a <script> elemeket a fejlécben.
  2. A külső szolgáltatások kódjait Tag Managerbe mozgasd. Egy konténer helyett ne legyen nyolc különálló szkript.
  3. A modulok között nézd meg, melyik hoz JavaScriptet. A nem használtakat kapcsold ki.

Egyedi fejlesztés

  1. Bontsd fel a bundle-t. Code splitting útvonalanként, dinamikus import() hívásokkal.
  2. A nehéz komponenseket töltsd be lustán. Térkép, videólejátszó, chat-widget: ezek várhatnak.
  3. Hosszú számításokat darabolj fel. Használj scheduler.yield() hívást vagy Web Workert.
  4. A hidratálást tedd szelektívvé. Egy statikus lábléc React-komponensként is maradhat statikus.
  5. Ellenőrizd a render-blokkoló erőforrásokat is. A defer és async nem csökkenti a végrehajtási időt, de kitolja, így a TBT-mérési ablakból kieshet.
  6. Harmadik féltől jövő szkripteket tölts Partytown-nal Web Workerbe, ha a szkript engedi.

Gyakori hibák

  • Minden szkriptre async-ot raknak: az async letöltés után azonnal futtat, így akár rosszabb helyre kerül a long task, mint defer-rel.
  • A minifikációtól várják a megoldást: a minifikáció a fájlméretet csökkenti, a végrehajtási időt alig. 200 KB JS ugyanannyi munkát ad a CPU-nak minifikálva is.
  • Csak asztali gépen mérnek: a fejlesztő MacBookján minden gyors, a felhasználó közepes Androidján nem.
  • A Tag Manager konténert soha nem takarítják: a régi kampánycímkék évekig futnak, senki nem törli őket.
  • Több mérőrendszert futtatnak párhuzamosan: GA4, Meta Pixel, hőtérkép, meg egy saját analitika. Mindegyik külön szkript, külön long task.
  • A TBT-t összekeverik a betöltési idővel: az oldal gyorsan megjelenhet és közben teljesen használhatatlan lehet.
  • Chat-widgetet azonnal töltenek: a látogatók 2%-a használja, a szkript 100%-uknak blokkol.

Technikai példa

Long task-ok kilistázása a konzolban. Illeszd be a devtools Console fülébe, majd tölts újra:

<script>
  const obs = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      const blocking = Math.max(0, entry.duration - 50);
      console.log(`Long task: ${Math.round(entry.duration)}ms, blokkol: ${Math.round(blocking)}ms`);
    }
  });
  obs.observe({ type: 'longtask', buffered: true });
</script>

A kiírt blokkoló értékek összege nagyjából a TBT-d. A buffered: true visszamenőleg is megmutatja a már lefutott feladatokat.

Nehéz szkript késleltetése az első interakcióig:

<script>
  const events = ['scroll', 'mousemove', 'touchstart', 'keydown'];
  const load = () => {
    const s = document.createElement('script');
    s.src = 'https://widget.pelda.hu/chat.js';
    document.body.appendChild(s);
    events.forEach((e) => window.removeEventListener(e, load));
  };
  events.forEach((e) => window.addEventListener(e, load, { once: true, passive: true }));
</script>

A chat-widget csak akkor töltődik, ha a látogató tényleg csinál valamit. A TBT-mérési ablakba így nem esik bele.

Lighthouse futtatása parancssorból, csak a teljesítmény-kategóriára:

npx lighthouse https://pelda.hu \
  --only-categories=performance \
  --form-factor=mobile \
  --output=json \
  --output-path=./riport.json

A JSON-ban az audits['total-blocking-time'].numericValue adja az ezredmásodpercben mért értéket.

Gyakori kérdések

Mi a különbség a TBT és az INP között?
A TBT laborban mért érték, szimulált eszközön, oldalbetöltés közben. Az INP (Interaction to Next Paint) valódi felhasználók valódi kattintásaiból jön, és a teljes munkamenetre vonatkozik. A TBT a legjobb előrejelzője az INP-nek, de a kettő nem ugyanaz. A Core Web Vitals hivatalosan az INP-t méri, a TBT csak diagnosztikai eszköz.
Miért jó a TBT-m a saját gépemen és rossz a PageSpeed-ben?
A PageSpeed Insights mobil emulációval mér, négyszeres CPU-lassítással. Ez egy közepes kategóriás Android-telefont szimulál. A fejlesztői gép általában négy-nyolcszor gyorsabb. Mindig a mobil értéket vedd alapul, mert a látogatóid többsége is telefonon jön.
Elég, ha defer-t teszek minden szkriptre?
Nem. A defer csak elhalasztja a futtatást a HTML-feldolgozás végére, a munkát nem szünteti meg. A render-blokkolást megszünteti, de a long task ugyanúgy lefut, csak később. TBT-javuláshoz kevesebb vagy feldarabolt JavaScript kell.
Mennyi TBT-vel érdemes megelégedni?
200 ms alatt jó, ott nincs mit javítani. 200 és 600 ms között érdemes ránézni, de nem katasztrófa. 600 ms felett a felhasználók már érzékelik az akadozást, és a Lighthouse pontszámod is jelentősen esik.
Mi az az 50 ms-os küszöb, és honnan jön?
A 50 ms alatti feladatok között a böngésző még be tud illeszteni egy válaszreakciót. Az ennél hosszabb feladatok észrevehető késést okoznak. Ezért számol a TBT csak az 50 ms feletti többletet, és nem a teljes feladat-hosszt.

Források

Kapcsolódó fogalmak

A te oldaladon hogy áll a(z) „TBT (Total Blocking Time)”?

Futtass egy SEO-auditot: pontszám, fejlesztői ítélet, a leggyorsabb javítások, és minden tételhez bizonyíték.

Ingyenes SEO-audit indítása