Rendimiento y mantenimiento

Qué es el Total Blocking Time (TBT) y por qué importa en la web

El Total Blocking Time mide cuánto tiempo permanece bloqueado el hilo principal del navegador, impidiendo que el usuario interactúe con la página durante la carga.

Close-up of professionals reviewing financial graphs at a business meeting.

El Total Blocking Time (TBT) es la métrica de rendimiento web que mide el tiempo total durante el cual el hilo principal del navegador estuvo bloqueado lo suficiente como para impedir la respuesta a la interacción del usuario. Un TBT alto significa que tu página puede verse cargada pero no responde a clics ni a toques, generando una experiencia frustrante.

¿Qué mide exactamente el TBT?

El navegador ejecuta casi todo en un único hilo principal (main thread): parseo de HTML, ejecución de JavaScript, cálculos de estilos, pintura. Cuando una tarea en ese hilo dura más de 50 ms, se considera una tarea larga (long task).

El TBT suma la parte bloqueante de cada tarea larga que ocurre entre el First Contentful Paint (FCP) y el Time to Interactive (TTI). La parte bloqueante es todo lo que supera esos 50 ms de umbral.

Por ejemplo: si una tarea de JavaScript tarda 200 ms, los primeros 50 ms son el tiempo "normal" y los 150 ms restantes son tiempo bloqueante. Si ocurren tres tareas así en la ventana FCP-TTI, el TBT sería 450 ms.

Umbrales de TBT según Google

Google evalúa el TBT en herramientas como Lighthouse (medición en laboratorio). Estos son los rangos oficiales:

Resultado TBT
Bueno < 200 ms
Necesita mejorar 200 – 600 ms
Malo > 600 ms

El objetivo es mantener el TBT por debajo de los 200 ms para ofrecer una experiencia fluida desde el primer segundo de interacción.

TBT y los Core Web Vitals: ¿son lo mismo que INP?

Es una confusión común. El TBT es una métrica de laboratorio —se mide en condiciones controladas con Lighthouse o WebPageTest— y sirve como proxy para predecir el Interaction to Next Paint (INP), que sí es una métrica de campo (datos reales de usuarios) y forma parte de los Core Web Vitals.

Un TBT alto en el laboratorio suele correlacionar con un INP alto en el campo. Reducir el TBT es, en la práctica, reducir el riesgo de que los usuarios sufran demoras al interactuar con tu sitio.

Puedes profundizar en las métricas de campo en nuestra sección de artículos sobre rendimiento web.

Causas más comunes de un TBT elevado

JavaScript excesivo en el hilo principal

Es la causa número uno. Scripts de terceros (chatbots, píxeles de analítica, widgets de redes sociales), frameworks pesados cargados de forma bloqueante, o código de aplicación mal optimizado pueden disparar tareas largas fácilmente.

Hidratación de frameworks JavaScript

Frameworks como React, Vue o Angular ejecutan la hidratación del DOM al cargar la página. Si se envía demasiado JavaScript al cliente, este proceso puede bloquear el hilo durante cientos de milisegundos.

Scripts de analítica y marketing

Google Tag Manager con docenas de etiquetas activas, píxeles de Meta, scripts de chat en vivo… cada uno ejecuta código en el hilo principal. La acumulación crea múltiples tareas largas que inflan el TBT.

Polyfills y librerías no tree-shaken

Incluir lodash completo cuando solo usas tres funciones, o polyfills para navegadores que ya son obsoletos, añade peso innecesario que el hilo principal debe parsear y ejecutar.

Cómo reducir el TBT paso a paso

  • Divide las tareas largas: usa setTimeout, scheduler.postTask() o requestIdleCallback() para dividir trabajos pesados en fragmentos menores de 50 ms.
  • Aplaza el JavaScript no crítico: añade los atributos defer o async a los scripts que no necesitas para la interacción inicial.
  • Carga scripts de terceros con precaución: evalúa el coste real de cada script. Usa la pestaña de cobertura de DevTools para identificar código no utilizado.
  • Reduce el tamaño del bundle: minificación, tree-shaking y code-splitting para cargar solo lo que la ruta actual necesita.
  • Mueve el trabajo al servidor o a workers: los Web Workers ejecutan código en un hilo separado, sin afectar al hilo principal.
  • Lazy loading de componentes pesados: importa dinámicamente los módulos que el usuario solo necesita al hacer clic o al hacer scroll.

Si quieres una revisión técnica de qué está bloqueando el hilo principal de tu sitio, el equipo de elenlace.com puede identificar los scripts culpables y proponer un plan de optimización.

Cómo medir el TBT de tu sitio

Al ser una métrica de laboratorio, la mides con herramientas que simulan la carga:

  • Google Lighthouse (en DevTools de Chrome o como extensión): muestra el TBT junto al resto de métricas de rendimiento.
  • PageSpeed Insights: corre Lighthouse en los servidores de Google y muestra también datos de campo cuando están disponibles.
  • WebPageTest: permite elegir dispositivo, velocidad de red y ubicación para un análisis más detallado.

Ejecuta siempre las pruebas en modo de navegación privada y con extensiones desactivadas para evitar ruido en los resultados. Para obtener resultados representativos, repite la prueba tres veces y promedia.

Conclusiones clave

  • El TBT mide el tiempo total que el hilo principal del navegador permanece bloqueado entre el FCP y el TTI.
  • Un TBT inferior a 200 ms es el objetivo; por encima de 600 ms la experiencia se considera mala.
  • Es una métrica de laboratorio y sirve como predictor del INP (Core Web Vital de campo).
  • La causa principal es el exceso de JavaScript en el hilo principal: scripts de terceros, bundles grandes y falta de lazy loading.
  • Las estrategias clave son: dividir tareas largas, aplazar scripts no críticos y reducir el tamaño del bundle.

¿Tu Lighthouse muestra un TBT elevado y no sabes por dónde empezar? El equipo de elenlace.com realiza auditorías de rendimiento que identifican las tareas largas específicas de tu sitio y te dan un plan de acción claro.

Preguntas frecuentes

¿El TBT afecta directamente al posicionamiento en Google?

No de forma directa. Google usa los Core Web Vitals (LCP, INP, CLS) como señal de posicionamiento, y estos son métricas de campo. Sin embargo, un TBT alto en el laboratorio predice un INP alto en el campo, por lo que reducirlo sí mejora la probabilidad de tener buenos Core Web Vitals y, por tanto, mejor rendimiento en búsqueda.

¿Cuál es la diferencia entre TBT y TTI?

El TTI (Time to Interactive) es el momento en que la página está completamente lista para la interacción. El TBT es el tiempo acumulado de bloqueo durante la ventana que va desde el FCP hasta ese TTI. Mientras el TTI es un punto en el tiempo, el TBT es una duración acumulada.

¿Un TBT de 0 ms es posible?

Sí, si la página no ejecuta ninguna tarea larga entre el FCP y el TTI. Ocurre en páginas muy simples, sin JavaScript o con JavaScript mínimo. En sitios complejos, es más realista apuntar a menos de 200 ms.

¿Puedo mejorar el TBT sin cambiar mi framework JavaScript?

Sí. Aplazar y cargar de forma asíncrona los scripts de terceros, eliminar scripts no utilizados y dividir el bundle en chunks más pequeños mediante code-splitting son mejoras que no requieren cambiar de framework y pueden reducir el TBT de forma significativa.

Recursos útiles

Otros proveedores y guías que vale la pena comparar:

← Todos