Fas clic a «Contactar» al web d’un proveïdor i el menú triga mig segon a respondre. No és la xarxa: el navegador està executant JavaScript al fil principal. El Total Blocking Time (TBT) resume quant de temps sumen aquestes tasques llargues entre el FCP i el Time to Interactive. El 2026 continua sent una de les mètriques de laboratori que millor correlaciona amb un web d’empresa que «es sent lent» encara que el LCP sembli acceptable.
Aquest article explica què mesura el TBT, quins llindars usar a Lighthouse, com es relaciona amb l’INP, els scripts de tercers i el JavaScript sense optimitzar, i quins canvis solen retallar el bloqueig sense desmuntar el teu stack de màrqueting.
Què és el TBT i què mesura exactament
El TBT és una mètrica de laboratori (Lighthouse, PageSpeed simulat). Suma la durada de totes les tasques llargues del fil principal que superen 50 ms, entre el First Contentful Paint i el Time to Interactive, descomptant una tolerància de 50 ms per tasca.
- Cada tasca > 50 ms al main thread suma (durada − 50 ms) al TBT.
- No substitueix l’INP en dades de camp, però anticipa problemes d’interactivitat.
- Un TBT alt sol coincidir amb menús lents, formularis que no validen a l’instant o scroll entrecortat.
- El parseig i execució de JS, reflows costosos i algun treball síncron alimenten el bloqueig.
La guia de web.dev sobre Total Blocking Time detalla el càlcul i el seu pes en la puntuació de rendiment de Lighthouse.
Llindars orientatius el 2026
Lighthouse segueix usant aquestes referències per al TBT:
- Bon: 200 ms o menys.
- A millorar: entre 200 ms i 600 ms.
- Dolent: per sobre de 600 ms.
En pàgines amb molt CRM incrustat, mapes o tags d’analítica, és habitual veure TBT en groc a desktop i en vermell en mòbil simulat. Prioritza les plantilles de conversió: inici, serveis, contacte i checkout si escau.
TBT davant INP, FCP i LCP
Els Core Web Vitals en camp mesuren experiència real; el TBT ajuda a diagnosticar per què el fil principal no respon. Un bon LCP no garanteix menús fluids si tres bundles de JS competeixen en carregar. Un FCP ràpid amb TBT alt produeix la sensació de «ja veig el web, però no el puc usar».
L’INP penalitza la lentitud davant clics i tecles en usuaris reals; millorar el TBT en laboratori sol ser el primer pas abans de validar l’INP a CrUX. Treballa ambdues mètriques en les mateixes URL crítiques.
Causes habituals en webs d’empresa
- Bundles JavaScript enormes sense dividir per ruta o sense carregar sota demanda.
- Tags de màrqueting i xat que executen codi síncron a l’inici.
- Libreries duplicades (dues versions de jQuery, sliders i frameworks alhora).
- Treball al fil principal que hauria d’anar a Web Workers o al servidor.
- Animacions i scroll listeners sense throttling que forcen layout cada frame.
- CMS o plugins que injecten scripts a totes les pàgines encara que no s’usin.
L’excés de scripts de tercers és la causa nº 1 en sites amb equip de màrqueting actiu sense revisió periòdica d’etiquetes.
Com mesurar el TBT
- PageSpeed Insights / Lighthouse: mètrica «Total Blocking Time» i desglossament de «Main-thread work».
- Chrome DevTools → Performance: grava la càrrega i localitza barres vermelles de tasques > 50 ms.
- WebPageTest: comparativa filmstrip + temps de bloqueig en diferents dispositius.
- Coverage a DevTools: identifica JS descarregat però no executat en aquella vista.
Repeteix la prova amb memòria cau freda i throttling mòbil. Anota el TBT abans i després de cada canvi; un retall de 150 ms en contacte pot notar-se en la taxa d’enviament del formulari.
Accions que solen reduir el TBT
Menys JavaScript a la ruta crítica
Retarda el que no cal per al primer scroll: pop-ups, mapes, reproductors i widgets socials. Aplica la mateixa disciplina que en el lazy loading, però per scripts: carrega en interactuar o en entrar al viewport.
Code splitting i rutes
Separa el bundle de la home del de la botiga o de l’àrea de client. Evita importar tota la llibreria de gràfics en pàgines que només mostren text. La minificació redueix bytes, però dividir redueix treball executat en cada vista.
Auditoria de tercers
Inventaria tags en GTM o plantilla. Elimina duplicats, fixa l’ordre de càrrega i usa consent mode si escau després del teu banner de cookies. Cada script que afegeix 40 ms de tasca llarga es multiplica en mòbil.
Menys treball al client
Filtres, ordenacions i validacions pesades poden resoldre-se al servidor o en el build. Menys JSON processat al navegador implica menys bloqueig i millor INP.
Trencar tasques llargues
Divide bucles costosos amb requestIdleCallback o yields cooperatius. Prioritza la resposta al clic del menú abans que animacions decoratives en la càrrega inicial.
Errors que mantenen el TBT alt
- Optimitzar només imatges quan Lighthouse assenyala «Reduce JavaScript execution time».
- Afegir un altre plugin «lleuger» sense mesurar l’impacte en tasques llargues.
- Carregar el mateix tag en staging i producció amb contenidor diferent, duplicant execució després de desplegaments.
- Confondre TBT amb TTFB: millorar el servidor no desbloqueja el fil principal si el JS segueix sent pesat.
Checklist abans de tancar una millora
- ¿El TBT ha baixat a Lighthouse mòbil en inici, serveis i contacte?
- ¿Les tasques > 50 ms a Performance són menys nombroses o més curtes?
- ¿L’INP o la sensació de menú/formulari han millorat en la mateixa URL?
- ¿Màrqueting segueix tenint les etiquetes imprescindibles després de la poda?
Conclusió
El TBT respon a una pregunta clara: «Quant de temps passa el navegador ocupat en JavaScript abans de poder respondre amb fluïdesa?». En un web d’empresa, retallar-lo redueix fricció en formularis, menús i CTAs i prepara el terreny per un bon INP en dades reals. Mesura en les pàgines que més converteixen, ataca tasques llargues i valida l’impacte juntament amb la resta de mètriques de rendiment.
Si vols un pla prioritzat de JavaScript, tercers i Core Web Vitals amb canvis acotats al teu stack, a AATSOFT auditem plantilles, origen i scripts crítics i proposem millores amb impacte mesurable en conversió.
