Total Blocking Time (TBT)

Een taak op de main thread die langer duurt dan 50 ms heet een long task. Tijdens zo'n taak kan de browser niet op klikken of tikken reageren. TBT telt per long task het deel boven die 50 ms op. Een taak van 250 ms levert dus 200 ms blokkeertijd op.

Lighthouse meet dit tussen First Contentful Paint en Time to Interactive. Volgens web.dev is een TBT onder 200 ms goed, gemeten op gemiddelde mobiele hardware. Sinds Lighthouse 10 weegt TBT 30% in de performance-score, het zwaarste van alle metrics.

TBT is een labmetric. Het is geen Core Web Vital. Google gebruikt INP (Interaction to Next Paint) als veldmetric voor reactiesnelheid. TBT is daar een benadering van in het lab, omdat je in een test zonder echte gebruiker geen INP kunt meten. web.dev zegt expliciet: optimaliseer voor INP, niet voor TBT zelf.

In Magento met Luma komt een hoge TBT meestal door de hoeveelheid JavaScript: RequireJS, Knockout en jQuery-widgets die bij het laden initialiseren. Hyvä vervangt die stack door Alpine.js, wat veel minder werk op de main thread geeft. Extensies die eigen JavaScript meebrengen kunnen dat voordeel weer tenietdoen.

In Shopify zijn apps en tracking de gebruikelijke bron. Elke app die een script in je thema zet, draait op dezelfde main thread. Meet vóór en na het installeren van een app.

In Laravel hangt het af van je frontend. Een server-rendered Blade-pagina met weinig JavaScript scoort laag. Een grote single-page app die bij het laden hydrateert, kan hoog scoren. Kijk dan naar code-splitting en minder werk tijdens hydration.

- TBT behandelen als rankingfactor. Google gebruikt INP uit CrUX-velddata, niet je Lighthouse-TBT.

- Testen op een snelle laptop. Lighthouse simuleert een trager mobiel apparaat; je eigen indruk zegt weinig.

- Third-party scripts vergeten. Tag managers, chatwidgets en A/B-testtools veroorzaken vaak de langste taken.

- Alleen de homepage meten. Product- en categoriepagina's hebben vaak meer scripts en een andere TBT.