Haces clic en «Contactar» en la web de un proveedor y el menú tarda medio segundo en reaccionar. No es la red: es el navegador ejecutando JavaScript en el hilo principal. El Total Blocking Time (TBT) resume cuánto tiempo suman esas tareas largas entre el FCP y el Time to Interactive. En 2026 sigue siendo una de las métricas de laboratorio que más correlaciona con una web de empresa que «se siente lenta» aunque el LCP parezca aceptable.
Este artículo explica qué mide TBT, qué umbrales usar en Lighthouse, cómo se relaciona con INP, scripts de terceros y JavaScript sin optimizar, y qué cambios suelen recortar el bloqueo sin desmontar tu stack de marketing.
Qué es TBT y qué mide exactamente
TBT es una métrica de laboratorio (Lighthouse, PageSpeed en modo simulado). Suma la duración de todas las tareas largas del hilo principal que superan 50 ms, entre el First Contentful Paint y el Time to Interactive, descontando una tolerancia de 50 ms por tarea.
- Cada tarea > 50 ms en el main thread suma (duración − 50 ms) al TBT.
- No sustituye a INP en datos de campo, pero anticipa problemas de interactividad.
- Un TBT alto suele coincidir con menús lentos, formularios que no validan al instante o scroll entrecortado.
- El parseo y ejecución de JS, reflows costosos y algunos estilos síncronos alimentan el bloqueo.
La guía de web.dev sobre Total Blocking Time detalla el cálculo y su peso en la puntuación de rendimiento de Lighthouse.
Umbrales orientativos en 2026
Lighthouse sigue usando estas referencias para TBT en la auditoría de rendimiento:
- Bueno: 200 ms o menos.
- A mejorar: entre 200 ms y 600 ms.
- Pobre: por encima de 600 ms.
En páginas con mucho CRM embebido, mapas o tags de analítica, es habitual ver TBT en amarillo en desktop y en rojo en móvil simulado. Prioriza las plantillas de conversión: home, servicios, contacto y checkout si aplica.
TBT frente a INP, FCP y LCP
Core Web Vitals en campo miden experiencia real; TBT ayuda a diagnosticar por qué el hilo principal no responde. Un buen LCP no garantiza menús fluidos si tres bundles de JS compiten al cargar. Un FCP rápido con TBT alto produce la sensación de «ya veo la web, pero no puedo usarla».
INP penaliza la lentitud ante clics y teclas en usuarios reales; mejorar TBT en laboratorio suele ser el primer paso antes de validar INP en CrUX. Trabaja ambas métricas en las mismas URLs críticas.
Causas habituales en webs de empresa
- Bundles JavaScript enormes sin dividir por ruta o sin cargar bajo demanda.
- Tags de marketing y chat que ejecutan código síncrono al inicio.
- Librerías duplicadas (dos versiones de jQuery, sliders y frameworks a la vez).
- Trabajo en el hilo principal que debería ir a Web Workers o al servidor.
- Animaciones y scroll listeners sin throttling que fuerzan layout en cada frame.
- CMS o plugins que inyectan scripts en todas las páginas aunque no se usen.
El exceso de scripts de terceros es la causa nº 1 en sitios con equipo de marketing activo y sin revisión periódica de etiquetas.
Cómo medir TBT con herramientas accesibles
- PageSpeed Insights / Lighthouse: métrica «Total Blocking Time» y desglose de «Main-thread work».
- Chrome DevTools → Performance: graba la carga y localiza barras rojas de tareas > 50 ms.
- WebPageTest: comparativa filmstrip + tiempo de bloqueo en distintos dispositivos.
- Coverage en DevTools: identifica JS descargado pero no ejecutado en esa vista.
Repite la prueba con caché fría y throttling móvil. Anota el TBT antes y después de cada cambio; un recorte de 150 ms en contacto puede notarse en la tasa de envío del formulario.
Acciones que suelen reducir TBT
Menos JavaScript en la ruta crítica
Retrasa lo que no hace falta para el primer scroll: pop-ups, mapas, reproductores y widgets sociales. Aplica la misma disciplina que en lazy loading, pero para scripts: carga al interactuar o al entrar en viewport.
Code splitting y rutas
Separa el bundle de la home del de la tienda o del área de cliente. Evita importar toda la librería de gráficos en páginas que solo muestran texto. La minificación reduce bytes, pero dividir reduce trabajo ejecutado en cada vista.
Auditoría de terceros
Inventaria tags en Google Tag Manager o en plantilla. Elimina duplicados, fija orden de carga y usa consent mode si aplica tras tu banner de cookies. Cada script que añade 40 ms de tarea larga se multiplica en móvil.
Menos trabajo en el cliente
Filtros, ordenaciones y validaciones pesadas pueden resolverse en el servidor o en el build. Menos JSON procesado en el navegador implica menos bloqueo y mejor INP.
Romper tareas largas
Divide bucles costosos con requestIdleCallback o yields cooperativos. Prioriza la respuesta al clic del menú antes que animaciones decorativas en la carga inicial.
Errores que mantienen el TBT alto
- Optimizar solo imágenes cuando el informe de Lighthouse señala «Reduce JavaScript execution time».
- Añadir otro plugin «ligero» sin medir el impacto en tareas largas.
- Cargar el mismo tag en staging y producción con distinto contenedor, duplicando ejecución tras despliegues.
- Confundir TBT con TTFB: mejorar el servidor no desbloquea el hilo principal si el JS sigue siendo pesado.
Checklist antes de cerrar una mejora
- ¿TBT bajó en Lighthouse móvil en home, servicios y contacto?
- ¿Las tareas > 50 ms en Performance son menos numerosas o más cortas?
- ¿INP o la sensación de menú/formulario mejoraron en la misma URL?
- ¿Marketing sigue teniendo los tags imprescindibles tras la poda?
Conclusión
TBT responde a una pregunta clara: «¿Cuánto tiempo pasa el navegador ocupado en JavaScript antes de poder responder con fluidez?». En una web de empresa, recortarlo reduce fricción en formularios, menús y CTAs, y prepara el terreno para un buen INP en datos reales. Mide en tus páginas que más convierten, ataca tareas largas y valida el impacto junto al resto de métricas de rendimiento.
Si quieres un plan priorizado de JavaScript, terceros y Core Web Vitals con cambios acotados a tu stack, en AATSOFT auditamos plantillas, origen y scripts críticos y proponemos mejoras con impacto medible en conversión.
