Guías

El Total Blocking Time es la métrica con mayor peso en el score de rendimiento de Lighthouse, un 30 %, por delante del LCP y el CLS con un 25 % cada uno. Aun así no es un Core Web Vital, y sostener esos dos hechos a la vez es precisamente el motivo para entenderlo bien.

Lo que mide no es cuánto tarda en cargar tu página. Mide cuánto tiempo estuvo el navegador demasiado ocupado para responderte.

Qué cuenta realmente el TBT

Durante la carga, el navegador ejecuta tu JavaScript en el hilo principal, el mismo que atiende los clics y las pulsaciones de teclas. Mientras ahí se ejecuta un trabajo, no puede ocurrir nada más. Una tarea que ocupa el hilo principal más de 50 milisegundos se llama tarea larga, y es la unidad con la que se construye el TBT.

Aquí está la parte que sorprende. El TBT no cuenta la tarea entera, solo la porción por encima del umbral de 50 ms. Una tarea de 70 ms aporta 20 ms. Una de 45 ms no aporta nada. El TBT es la suma de esas porciones bloqueantes de cada tarea larga situada entre el First Contentful Paint y el momento en que la página se vuelve interactiva.

El límite de 50 ms no es arbitrario. Es aproximadamente el punto en el que una persona nota que la interfaz no respondió de inmediato, así que la métrica cuenta el tiempo que la página pasó visiblemente inerte, no el tiempo que pasó trabajando.

Por qué pesa un 30 % y aun así no es un Core Web Vital

Lighthouse clasifica el TBT en tres franjas, medidas sobre su dispositivo móvil simulado: bueno con 200 ms o menos, mejorable entre 200 y 600 ms, y malo por encima de 600 ms. Esas cifras suponen un teléfono de gama media, deliberadamente más lento que la máquina desde la que pruebas.

• Bueno - 200 ms o menos
• Mejorable - entre 200 y 600 ms
• Malo - por encima de 600 ms

El TBT es una métrica de laboratorio. Se mide en una ejecución controlada, con un perfil de dispositivo fijo y sin usuario real, y por eso exactamente no es un Core Web Vital: los Core Web Vitals son métricas de campo recogidas de visitas reales. Su equivalente de campo es el Interaction to Next Paint, y ambos están relacionados sin ser lo mismo.

El TBT mira el hilo principal bloqueado durante la carga. El INP mira lo que ocurrió de verdad cuando una persona interactuó, en cualquier momento de la visita. Una página puede tener un TBT decente y un INP malo porque el trabajo caro llega más tarde, al abrir un menú o aplicar un filtro.

Qué lo empeora

Las causas son casi siempre JavaScript, y normalmente con una de tres formas. Un bundle grande debe analizarse, compilarse y ejecutarse antes de que pueda correr cualquier otra cosa, y ese trabajo aterriza en el hilo principal de una sola vez.

La hidratación del framework es la segunda fuente habitual. El HTML renderizado en servidor llega rápido, y después el framework recorre el árbol de componentes para engancharle el comportamiento; en una página grande ese recorrido es una única tarea larga justo en el momento en que el usuario es más propenso a intentar hacer clic.

Los scripts de terceros son la tercera, y la menos controlada. Gestores de etiquetas, analítica, widgets de chat y banners de consentimiento ejecutan cada uno su propio trabajo en tu hilo principal, con un calendario que no fijas tú, y su coste casi nunca aparece en el presupuesto de bundle de nadie.

Dividir vale más que reducir

El instinto es reducir el tamaño del bundle. Ayuda, pero no es la misma palanca, y esto es lo más útil que se puede saber del TBT. La métrica cuenta el tiempo por encima de 50 ms por tarea, así que la misma cantidad de trabajo repartida en varias tareas cortas puntúa mucho mejor que una sola larga, con exactamente los mismos bytes.

Por eso importa ceder el control. Partir un bucle pesado para que el navegador pueda atender la entrada entre fragmentos, mover el cálculo a un Web Worker donde no toca el hilo principal en absoluto, y aplazar los terceros hasta que la página sea usable reducen todos el TBT sin quitar una sola línea de lógica.

El laboratorio y el campo no miden lo mismo

Una salvedad honesta antes de optimizar para la cifra. Una ejecución de laboratorio usa un solo perfil de dispositivo y nunca hace clic en nada, así que el TBT puede parecer bueno mientras usuarios reales con hardware más barato siguen esperando. Trátalo como un diagnóstico que te dice dónde está ocupado el hilo principal, y consulta los datos de campo para saber qué vivió la gente de verdad.

Leídos juntos, ambos responden a preguntas distintas. El TBT te dice que la página estuvo bloqueada durante la carga, y aproximadamente cuánto. El INP te dice si eso le importó a alguien.