Total Blocking Time (TBT) y SEO

TL;DR — El Tiempo de Bloqueo Total (TBT) mide cuánto tiempo tu página está congelada — incapaz de responder a un clic o toque — mientras se carga. Una herramienta de laboratorio como Lighthouse suma todo el tiempo en que el hilo principal está bloqueado entre la primera pintura y cuando la página se vuelve interactiva. Menos de 200 ms es bueno. Es un número solo de laboratorio, no es una Métrica Vital de la Web, y no aparecerá en Search Console.

Qué es el TBT

Cuando una página se carga, el navegador tiene un hilo principal que hace el trabajo pesado — ejecutar JavaScript, construir la página, reaccionar a tus clics. Solo puede hacer una cosa a la vez. Si un fragmento de JavaScript acapara ese hilo durante demasiado tiempo, la página se vuelve momentáneamente no receptiva: tocas un botón y no pasa nada hasta que el script termina.

El Tiempo de Bloqueo Total es una medición de exactamente ese tiempo congelado durante la carga. Una herramienta de prueba como Lighthouse carga tu página en un entorno controlado, observa el hilo principal y suma todo el tiempo en que estuvo bloqueado para responder a la entrada.

La regla de los 50 ms

No todo el trabajo cuenta. El navegador puede manejar tareas cortas sin que lo notes. La línea está en 50 milisegundos: cualquier tarea que dure más de eso es una “tarea larga”, y solo la parte por encima de 50 ms cuenta como tiempo de bloqueo.

Así que una tarea que dura 70 ms añade 20 ms a tu TBT. Una tarea que dura 40 ms no añade nada. El TBT es la suma de todos esos fragmentos “por encima de 50 ms” mientras la página se carga.

¿Cuál es una buena puntuación?

En Lighthouse, en móvil:

• Bueno: 200 ms o menos
• Necesita mejoras: hasta 600 ms
• Pobre: más de 600 ms

Lo que la mayoría de la gente entiende mal

El TBT no es una Métrica Vital de la Web. Las tres Métricas Vitales de la Web son LCP, INP y CLS. El TBT es una herramienta de laboratorio que ayuda a predecir tu Interacción con la Siguiente Pintura (INP) — la métrica de usuarios reales que Google realmente usa. No encontrarás el TBT en Google Search Console ni en datos de campo, porque se mide simulando una carga de página, no observando visitantes reales.

¿Quieres la mecánica completa — el ejemplo práctico, por qué el TBT tiene el mayor peso en Lighthouse, la diferencia entre TBT e INP, y cómo solucionarlo realmente? Cambia a la pestaña Avanzado.

TL;DR — El TBT es la cantidad total de tiempo, entre la Primera Pintura con Contenido y el Tiempo hasta la Interactividad, en que el hilo principal estuvo bloqueado el tiempo suficiente para impedir la capacidad de respuesta a la entrada. Suma la parte de bloqueo (duración − 50 ms) de cada tarea larga (cualquier tarea del hilo principal de más de 50 ms). Es una métrica de laboratorio — el mayor peso individual (30 %) en la puntuación de Lighthouse 10 y el proxy de laboratorio para INP — pero no es una Métrica Vital de la Web y nunca aparece en CrUX ni en Search Console. Umbrales móviles: bueno ≤200 ms, pobre >600 ms. Soluciónalo como solucionarías el INP: divide las tareas largas de JS, divide el código, difiere/elimina JS no utilizado, controla los scripts de terceros. Mi opinión honesta: soluciónalo para los usuarios, no para un aumento en el ranking.

Qué mide realmente el TBT

La definición de Google es el lugar para empezar. El TBT es “la cantidad total de tiempo después de la Primera Pintura con Contenido (FCP) en que el hilo principal estuvo bloqueado el tiempo suficiente para impedir la capacidad de respuesta a la entrada.” El hilo principal del navegador procesa una tarea a la vez; mientras está ocupado con un fragmento largo de trabajo, no puede reaccionar a un clic, un toque, o una pulsación de tecla. El TBT cuantifica cuánto de tu ventana de carga de página se pasa en ese estado bloqueado.

Dos definiciones hacen todo el trabajo aquí:

• Una tarea larga es “una tarea que se ejecuta en el hilo principal durante más de 50 milisegundos.”
• La parte de bloqueo de una tarea es su duración menos 50 ms. Las tareas de 50 ms o menos contribuyen exactamente 0 ms.

El TBT es la suma de esas porciones de bloqueo entre FCP y Time to Interactive (TTI). Así que First Contentful Paint es la línea de salida: nada antes del primer pintado cuenta, porque no hay nada en pantalla con lo que interactuar todavía.

El ejemplo práctico

La propia tabla de Google es la ilustración más clara. Imagina cinco tareas que se ejecutan en el hilo principal entre FCP y TTI:

Las tareas tres y cuatro están por debajo de la línea de 50 ms, así que no contribuyen nada. La tarea uno bloquea durante 250 − 50 = 200 ms, la tarea cinco durante 155 − 50 = 105 ms. Suma las porciones de bloqueo — 200 + 40 + 0 + 0 + 105 — y obtienes 345 ms de TBT. Eso es una puntuación de “necesita mejoras”, impulsada casi por completo por dos tareas pesadas.

Esta es la parte contraintuitiva que vale la pena internalizar: “A small number of tasks on the main thread doesn’t necessarily mean low blocking time. Conversely, a large number of tasks doesn’t necessarily lead to tons of blocking time.” (traducción) «Un número pequeño de tareas en el hilo principal no significa necesariamente un tiempo de bloqueo bajo. Por el contrario, un número grande de tareas no conduce necesariamente a una gran cantidad de tiempo de bloqueo.» (Ese marco es de NitroPack, transmitido aquí — reverificado contra la fuente en vivo el 2026-07-18.) Lo que importa es si las tareas individuales cruzan los 50 ms, no cuántas tareas hay.

La ventana de medición: FCP a TTI

La ventana termina en Time to Interactive — “the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.” (traducción) «El tiempo desde que la página comienza a cargarse hasta que sus sub-recursos principales se han cargado y es capaz de responder de manera confiable y rápida a la entrada del usuario.» En Lighthouse, el TTI se encuentra buscando hacia adelante una “ventana de silencio” de cinco segundos sin tareas largas y con no más de dos solicitudes de red en vuelo.

Vale la pena señalar: el propio TTI fue eliminado de Lighthouse 10 porque demostró ser demasiado sensible a solicitudes de red atípicas y tareas largas, produciendo alta variabilidad. El TBT sobrevivió y se convirtió en la métrica principal de interactividad. Como dijo Philip Walton, “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (traducción) «Las métricas más nuevas y alternativas como Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Interaction to Next Paint (INP) suelen ser mejores métricas para usar en lugar de TTI.» El TBT no reemplazó al TTI como punto final de la ventana — es un mejor número único para el mismo problema subyacente. Y la desaparición del TTI de la interfaz de usuario del informe de Lighthouse no es lo mismo que afirmar que el TTI ya no limita la ventana de navegación predeterminada de Lighthouse — la ventana en sí todavía se mide de esa manera bajo el capó.

Una nota más de alcance: “FCP a TTI” describe específicamente la auditoría de navegación predeterminada de Lighthouse. Otras herramientas, o el propio Lighthouse ejecutando un rastreo de intervalo de tiempo en lugar de una navegación de carga de página completa, pueden totalizar una ventana medida diferente — la matemática de tareas largas de 50 ms no cambia, pero los puntos de inicio y fin de lo que se suma son específicos de la herramienta y del modo de rastreo, no una ley universal de la métrica.

¿Es el TBT un Core Web Vital? No.

Este es el error más común, así que seamos directos al respecto. Los tres Core Web Vitals son LCP, INP y CLS. El TBT no es uno de ellos. Las propias palabras de Google: “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (traducción) «Total Blocking Time (TBT) es una métrica de laboratorio que es vital para detectar y diagnosticar problemas potenciales de interactividad que pueden afectar a INP. Sin embargo, no forma parte del conjunto de Core Web Vitals porque no son medibles en campo, ni reflejan un resultado centrado en el usuario.» (La gramática en esa frase es de ellos, no mía.)

Entonces, ¿dónde aparece el TBT y dónde no?

• Dónde lo ves: Lighthouse, PageSpeed Insights en la pestaña de laboratorio y Chrome DevTools: todos son entornos simulados/de laboratorio.
• Dónde no lo ves: en el informe de Core Web Vitals de Google Search Console, en CrUX ni en ningún dato de campo. Esos solo incluyen LCP, INP y CLS.

Si alguien te dice que está “viendo TBT en Search Console”, se equivoca: GSC informa datos de campo, y TBT no es una métrica de campo.

Una corrección que vale la pena precisar: que TBT sea recomendado en laboratorio no es lo mismo que TBT sea imposible en campo. Técnicamente puedes calcular un total estilo TBT en campo con la API de Long Tasks; Google lo dice directamente: “It is possible to measure TBT in the field, but we don’t recommend this as user interaction can affect your page’s TBT in ways that lead to lots of variance in your reports.” (traducción) «Es posible medir TBT en campo, pero no recomendamos esto porque la interacción del usuario puede afectar el TBT de tu página de maneras que generan mucha variación en tus informes». Eso es una recomendación en contra, no una barrera técnica. Lo que es realmente cierto sin excepción es más limitado: CrUX y el informe de Core Web Vitals de Search Console nunca incluyen TBT, punto final: esas canalizaciones solo recopilan LCP, INP y CLS.

TBT es el proxy de laboratorio para INP

Aquí está la razón por la que TBT existe. Las herramientas de laboratorio cargan una página en un entorno simulado sin un usuario real, por lo que no pueden medir Interaction to Next Paint: INP necesita clics reales y toques. TBT llena ese vacío: “the Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.” (traducción) «La métrica de tiempo de bloqueo total (TBT) se puede medir en laboratorio y es un proxy de INP».

Las dos están mecánicamente relacionadas: ambas reflejan un hilo principal bloqueado durante el arranque. La fuente resume el efecto con “the browser is delayed” (traducción) «el navegador se retrasa» al responder a las interacciones. Y empíricamente, “A low TBT often correlates with a low Interaction to Next Paint (INP).” (traducción) «Un TBT bajo a menudo se correlaciona con un Interaction to Next Paint (INP) bajo».

Pero “proxy” no es “sustituto”. Google es explícito: “Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (traducción) «El tiempo de bloqueo total (TBT) puede ser una métrica proxy razonable para INP, pero no es un sustituto de INP por sí mismo». Difieren de maneras reales:

• TBT alto, INP bien. TBT mide el bloqueo durante la carga. Si tus usuarios no intentan interactuar realmente durante esa ventana bloqueada (esperan a que la página parezca terminada primero), su INP puede estar bien incluso con un TBT feo.
• TBT bien, INP pobre. INP también cubre manejadores de eventos lentos y trabajo de renderizado que se disparan después de la carga, además de cosas como el retraso de 300 ms del navegador en toques en páginas no optimizadas para móviles: nada de eso lo ve TBT.

Cuando el laboratorio y el campo no coinciden, confía en el campo. INP (el número de usuarios reales) tiene prioridad sobre TBT (la estimación de laboratorio).

Una nota histórica que confunde a la gente: TBT solía ser el proxy de laboratorio para First Input Delay (FID). INP reemplazó a FID como Core Web Vital el 12 de marzo de 2024, así que TBT es ahora el proxy de INP. El mecanismo subyacente nunca cambió: siempre se ha tratado de un hilo principal bloqueado durante la carga, pero cualquier artículo más antiguo que llame a TBT “proxy de FID” antecede a ese cambio.

Por qué TBT domina la puntuación de Lighthouse

TBT tiene el mayor peso individual en la puntuación de rendimiento de Lighthouse: 30 %, una ponderación introducida en Lighthouse 10 y, verificada en vivo contra los documentos de puntuación de Chrome el 18 de julio de 2026, aún sin cambios hasta el actual Lighthouse 13:

Trata esa tabla como limitada a versión y fecha, no como una constante permanente: Lighthouse ha cambiado sus pesos antes y puede volver a hacerlo. Vuelve a verificar contra Lighthouse performance scoring antes de citarla en una presentación de auditoría.

Esta es la razón práctica por la que el TBT importa en las auditorías SEO, aunque no sea una señal de clasificación: un TBT deficiente tiene un efecto desproporcionado en ese gran número de Lighthouse que todos capturan. El ejemplo práctico de Addy Osmani lo hace concreto: eliminar un polyfill de Intersection Observer redujo el TBT de 400 ms a 300 ms y elevó la puntuación de rendimiento de Lighthouse de 63 a 70. Una corrección, siete puntos, debido al peso del 30 %.

Un matiz más: el umbral de categoría “Bueno ≤200 ms” y la puntuación de Lighthouse son escalas diferentes. Para obtener 90+ en la subpuntuación de TBT necesitas aproximadamente ≤300 ms en móvil, y para alcanzar 100 necesitas ≤100 ms. (Esas cifras de subpuntuación son la documentación de DebugBear sobre la curva de puntuación, reverificada contra la fuente en vivo el 2026-07-18.) “Bueno” y “100” no son el mismo nivel.

¿Afecta el TBT a los rankings de SEO?

No directamente, y seré más directo que la mayoría.

El TBT no es una señal de clasificación. La entrada de clasificación de interactividad de Google es INP, una métrica de campo. El TBT es un diagnóstico que te ayuda a encontrar y corregir las tareas largas que perjudican al INP. Mejorar el TBT puede mejorar el INP, lo que podría ayudar marginalmente al aspecto de Page Experience en los rankings, pero eso está a dos eslabones de “puede” de tus posiciones.

Y aquí está mi posición real sobre toda la cuestión de Core Web Vitals, que ya he escrito antes en mi guía de velocidad de página: no creo que Core Web Vitals tengan mucho impacto en el SEO, y a menos que seas extremadamente lento, generalmente no los priorizaré. Hazlos por los usuarios y las conversiones, no por un aumento en el ranking. Eso se aplica doblemente al TBT, que es un proxy de laboratorio para una métrica de campo para una pequeña entrada de clasificación. Arrégialo porque una página congelada te hace perder clientes, no porque estés persiguiendo una posición.

¿Qué causa un TBT alto?

Casi siempre es JavaScript:

• Carga, análisis o ejecución innecesaria de JavaScript — las propias palabras de la auditoría de Lighthouse. Enviar un paquete grande que la página no necesita al cargar es la causa clásica.
• Declaraciones de JavaScript ineficientes — trabajo síncrono pesado que monopoliza el hilo principal.
• Scripts de terceros — gestores de etiquetas, widgets de chat, análisis, scripts de anuncios. A menudo el mayor contribuyente individual, y el que menos controlas.
• Arranque pesado del framework — la hidratación de React y similares pueden ejecutar tareas largas durante el inicio.
• Recálculo de estilo/diseño y recolección de basura — el diseño síncrono forzado, los recálculos de estilo grandes y las pausas de GC aparecen como tareas del hilo principal también; no asumas que cada tarea larga en el rastro es ejecución de JavaScript.

Tampoco asumas que el tamaño de transferencia del paquete es toda la historia. La atribución de rastros tiene brechas reales: los marcos de origen cruzado y los hilos de trabajo tienen límites de privacidad y seguridad sobre lo que un observador de tareas largas puede informar sobre ellos (consulta Solución de problemas), por lo que una tarea no atribuida en tu rastro no es prueba de que no haya terceros involucrados; puede significar simplemente que la API de atribución no tiene permitido decírtelo.

Cómo corregir un TBT alto

Las correcciones son de la misma familia que las de INP: ambas se reducen a un hilo principal bloqueado.

1. Encuentra las tareas largas. Abre el panel de rendimiento de Chrome DevTools y busca tareas de más de 50 ms (se marcan con esquinas rojas), o ejecuta la auditoría de Lighthouse “Evita tareas largas del hilo principal”.
2. Audita primero los scripts de terceros. Suelen ser las victorias más fáciles. Usa las pestañas de Cobertura y Red de DevTools para ver cuánto cuesta cada script, y carga de forma diferida los embebidos pesados (YouTube, mapas, chat) detrás de una fachada.
3. Divide las tareas largas. Cede el hilo principal para que el navegador pueda manejar la entrada entre fragmentos — “cuando las tareas se dividen, el navegador puede responder a trabajo de mayor prioridad mucho antes, incluidas las interacciones del usuario”. (traducción) «cuando las tareas se dividen, el navegador puede responder a trabajo de mayor prioridad mucho antes, incluidas las interacciones del usuario». La API moderna es scheduler.yield(), con un respaldo de setTimeout(resolve, 0) (consulta la pestaña de Hojas de referencia para ver el patrón). Ten en cuenta que Google ya no recomienda isInputPending() — cede independientemente de si hay entrada pendiente.
4. Reduce el JavaScript. Divide los paquetes grandes en código para que se analice y evalúe menos en la carga, elimina JS no utilizado (la pestaña de Cobertura de DevTools te muestra qué), y usa defer para scripts no críticos.
5. Mueve el cálculo pesado fuera del hilo principal. Los Web Workers ejecutan trabajo intensivo de CPU en un hilo separado, dejando el hilo principal libre para responder.

Un efecto secundario útil: las tareas largas que bloquean el hilo principal también pueden retrasar el renderizado de Largest Contentful Paint, por lo que corregir TBT a veces también mejora LCP — especialmente cuando hay JS que bloquea el renderizado.

Dónde ir a continuación

TBT vive en la familia de Core Web Vitals junto con su contraparte de campo Interaction to Next Paint, las métricas de carga Largest Contentful Paint y First Contentful Paint, y las herramientas de laboratorio Lighthouse, PageSpeed Insights y Speed Index que las reportan. Si solo recuerdas una cosa: TBT es la luz de advertencia de laboratorio para la capacidad de respuesta de campo — persigue las tareas largas, no el número.

Resumen de IA

Una versión condensada de la versión avanzada:

• TBT = tiempo de hilo principal bloqueado durante la carga. Es el tiempo total, entre FCP y TTI, en que el hilo principal estuvo bloqueado lo suficiente como para impedir la capacidad de respuesta a la entrada.
• Las matemáticas: suma de la porción de bloqueo (duration − 50 ms) de cada tarea larga (cualquier tarea del hilo principal de más de 50 ms). Las tareas de ≤50 ms añaden 0 ms. El ejemplo resuelto de Google: tareas de 250/90/35/30/155 ms → 345 ms de TBT.
• Es una métrica de laboratorio. La ves en Lighthouse, en la pestaña de laboratorio de PageSpeed Insights y en DevTools — nunca en CrUX ni en Search Console.
• No es un Core Web Vital. Los tres CWV son LCP, INP y CLS. TBT es el proxy de laboratorio para INP (históricamente el proxy de FID; INP reemplazó a FID el 12 de marzo de 2024).
• Mayor peso en Lighthouse: 30 % — el más grande individualmente, por lo que un TBT pobre hunde la puntuación general. Umbrales móviles: bueno ≤200 ms, necesita mejoras ≤600 ms, pobre

  600 ms.

• Clasificaciones: no es un factor de clasificación directo. INP es la señal de campo; TBT solo ayuda a diagnosticarlo. La opinión de Patrick: corrígelo por los usuarios y las conversiones, no por un aumento en la clasificación.
• Correcciones (misma familia que INP): encuentra tareas largas en DevTools, audita primero los scripts de terceros, divide las tareas con scheduler.yield(), divide el código y elimina JS no utilizado, y descarga el trabajo pesado a Web Workers.
• Advertencia: TBT e INP pueden divergir — TBT alto con INP bueno (los usuarios no interactúan durante la carga) o TBT bueno con INP pobre (manejadores de eventos lentos después de la carga). Los datos de campo ganan.
• “Solo de laboratorio” significa recomendado en laboratorio, no imposible en laboratorio. Técnicamente puedes calcular un total estilo TBT a partir de datos de campo con la API de Long Tasks, pero Google lo desaconseja (demasiada variación entre ejecuciones) — CrUX y Search Console simplemente nunca lo llevan de ninguna manera.
• La atribución de trazas tiene vacíos reales. Los marcos de origen cruzado y los hilos de trabajo tienen límites de privacidad/seguridad sobre lo que un observador de tareas largas puede reportar, por lo que una tarea no atribuida significa “causa desconocida”, no “no hay terceros involucrados”.

Documentación oficial

Documentación de fuentes primarias sobre TBT de Google y el equipo de Chrome.

web.dev / Chrome

• Total Blocking Time (TBT) — Philip Walton y Barry Pollard: la definición canónica, la regla de la tarea larga de 50 ms y el ejemplo práctico.
• Auditoría de TBT en Lighthouse — la página de la auditoría, con los umbrales de puntuación para móvil y escritorio y las causas citadas.
• Puntuación de rendimiento de Lighthouse — los pesos de las métricas, de donde proviene el 30 % del TBT.
• Web Vitals — por qué el TBT no es un Core Web Vital y cómo se relaciona con el conjunto.
• Interaction to Next Paint (INP) — la métrica de campo que el TBT representa, y la advertencia de “proxy, no sustituto”.
• Optimizar tareas largas — Jeremy Wagner y Brendan Kenny sobre dividir tareas, scheduler.yield() y por qué isInputPending() ya no se recomienda.
• Time to Interactive (TTI) — la métrica que define el final de la ventana de TBT y por qué se eliminó de Lighthouse 10.
• Diferencias entre datos de laboratorio y de campo — los límites del TBT como sustituto del INP.

Citas de la fuente

Declaraciones oficiales de la documentación de Google. Cada enlace es un enlace profundo que salta al pasaje citado.

Definición y mecánica

• “the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness.” (traducción) «la cantidad total de tiempo posterior a la primera pintura con contenido (FCP) durante el que el hilo principal estuvo bloqueado el tiempo suficiente para impedir la respuesta a la entrada». — web.dev, Total Blocking Time. Ir a la cita
• “a task that runs on the main thread for more than 50 milliseconds” (traducción) «una tarea que se ejecuta en el hilo principal durante más de 50 milisegundos»; esa es la definición de tarea larga. Ir a la cita
• “To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200 milliseconds when tested on average mobile hardware.” (traducción) «Para ofrecer una buena experiencia de usuario, los sitios deberían esforzarse por tener un tiempo de bloqueo total de menos de 200 milisegundos cuando se prueban en hardware móvil promedio». Ir a la cita
• “A low TBT often correlates with a low Interaction to Next Paint (INP).” (traducción) «Un TBT bajo a menudo se correlaciona con un INP bajo». Ir a la cita

Estado: no es un Core Web Vital

• “Total Blocking Time (TBT) is a lab metrics is vital in catching and diagnosing potential interactivity issues that can impact INP. However, it is not part of the Core Web Vitals set because they are not field-measurable, nor do they reflect a user-centric outcome.” (traducción) «El tiempo de bloqueo total (TBT) es una métrica de laboratorio que es vital para detectar y diagnosticar posibles problemas de interactividad que pueden afectar al INP. Sin embargo, no forma parte del conjunto de Core Web Vitals porque no se pueden medir en el campo, ni reflejan un resultado centrado en el usuario». — web.dev, Web Vitals (Philip Walton). (La gramática es textual de la fuente.) Ir a la cita

TBT como proxy del INP

• “In such cases, Total Blocking Time (TBT) may be a reasonable proxy metric for INP, but it’s not a substitute for INP in and of itself.” (traducción) «En tales casos, el tiempo de bloqueo total (TBT) puede ser una métrica proxy razonable para el INP, pero no es un sustituto del INP en sí mismo». — web.dev, Interaction to Next Paint. Ir a la cita

Tareas largas y cómo solucionarlas

• “The main thread can only process one task at a time. Any task that takes longer than 50 milliseconds is a long task.” (traducción) «El hilo principal solo puede procesar una tarea a la vez. Cualquier tarea que tarde más de 50 milisegundos es una tarea larga.» — web.dev, Optimize long tasks. Ir a la cita
• “When tasks are broken up, the browser can respond to higher-priority work much sooner—including user interactions.” (traducción) «Cuando las tareas se dividen, el navegador puede responder mucho antes a trabajos de mayor prioridad, incluidas las interacciones del usuario.» Ir a la cita
• Sobre isInputPending(): “We no longer recommend using this API, and instead recommend yielding regardless of whether input is pending or not.” (traducción) «Ya no recomendamos usar esta API, y en su lugar recomendamos ceder el control independientemente de si hay entrada pendiente o no.» Ir a la cita

TTI y por qué TBT lo reemplazó como el número clave de interactividad

• “Newer, alternative, metrics like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Interaction to Next Paint (INP) are usually better metrics to use in place of TTI.” (traducción) «Métricas más nuevas y alternativas como Largest Contentful Paint (LCP), Total Blocking Time (TBT) e Interaction to Next Paint (INP) suelen ser mejores métricas para usar en lugar de TTI.» — web.dev, Time to Interactive (Philip Walton). Ir a la cita

Lista de verificación de triaje de TBT

Una pasada rápida cuando Lighthouse te da un Total Blocking Time en rojo (o naranja):

• Confirma que estás leyendo datos de laboratorio — TBT está en la pestaña de laboratorio de Lighthouse / PageSpeed Insights / DevTools, no en el campo ni en Search Console.
• Abre el panel Rendimiento de DevTools y encuentra las tareas largas (más de 50 ms, con esquina roja) entre la primera pintura y el estado interactivo.
• Haz una lista de tus scripts de terceros y cuánto cuesta cada uno (pestañas Cobertura y Red) — empieza aquí; suele ser la victoria más grande y fácil.
• Carga diferida de incrustaciones pesadas (YouTube, mapas, chat) detrás de una fachada.
• Ejecuta las auditorías de Lighthouse “Evita tareas largas en el hilo principal” y “Reduce el JavaScript no utilizado” y trabaja la lista.
• Divide el código en paquetes grandes para que menos JS se analice/ejecute en la carga.
• Difiere los scripts no críticos; usa import() dinámico para lo que no se necesita de inmediato.
• Divide las tareas largas restantes con scheduler.yield() (respaldo de setTimeout). No recurras a isInputPending().
• Mueve el cálculo pesado de CPU a un Web Worker.
• Verifica el campo: extrae INP de CrUX / monitoreo de usuarios reales. Si INP está bien, no inviertas de más en perseguir el número de laboratorio.

Hoja de referencia de TBT

Las matemáticas, en una línea

TBT = Σ (taskDuration − 50 ms) para cada tarea > 50 ms entre FCP y TTI. Las tareas ≤ 50 ms contribuyen 0 ms.

Ejemplo práctico (el de Google)

Umbrales de Lighthouse

(Los umbrales difieren de la curva de subpuntuación de Lighthouse: 90+ ≈ ≤300 ms en móvil, 100 ≈ ≤100 ms en móvil — cifras documentadas de DebugBear, reverificadas en vivo el 2026-07-18.)

TBT vs. INP — la hoja de referencia

Patrón de rendimiento al hilo principal (la solución)

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Usa scheduler.yield() donde esté disponible, y recurre a setTimeout como alternativa. No uses isInputPending() — Google ahora recomienda ceder el control independientemente de si hay entrada pendiente.

Herramientas para medir y corregir TBT

• PageSpeed Insights — lee TBT en la sección de datos de laboratorio (no está en la sección de datos de campo, porque TBT no es una métrica de campo).
• Lighthouse (Chrome DevTools → panel de Lighthouse, o la CLI) — la fuente del número de TBT y las auditorías “Evita tareas largas del hilo principal” / “Reduce JavaScript sin usar”.
• Chrome DevTools — panel de rendimiento — graba una carga y encuentra las tareas largas (más de 50 ms, marcadas con esquinas rojas) que componen tu TBT.
• Chrome DevTools — pestaña de cobertura — ve cuánto de cada script se usa realmente, para apuntar a JavaScript sin usar y terceros pesados.
• WebPageTest — pruebas de laboratorio con desgloses detallados del hilo principal y la CPU.
• API de Long Animation Frames (LoAF) — un complemento moderno del lado de campo para TBT, no un reemplazo de su cálculo de ventana de carga de laboratorio: atribuye marcos de animación largos durante toda una visita, lo que se acerca más a cómo los problemas de INP realmente se manifiestan, en lugar de la única ventana de carga de FCP a TTI de TBT.
• TBT del lado de campo mediante la API de Long Tasks — técnicamente posible (suma duration − 50 ms para tareas largas observadas en producción, igual que el fragmento de la pestaña Scripts), pero Google lo desaconseja para RUM: el tiempo real de interacción del usuario hace que el número sea demasiado variable para comparar entre ejecuciones. Recurre a INP o LoAF para la capacidad de respuesta de campo en su lugar.
• Dónde no lo encontrarás: el informe de Core Web Vitals de Google Search Console y CrUX solo incluyen LCP, INP y CLS — nunca TBT, independientemente de lo que sea técnicamente posible calcular por tu cuenta.

Errores de TBT que producen la corrección equivocada

• Llamar a TBT un Core Web Vital. TBT es un diagnóstico de laboratorio y un proxy útil para la contención del hilo principal; INP es el Core Web Vital de usuarios reales. Repórtalos por separado.
• Contar toda la tarea larga como tiempo de bloqueo. Solo la parte que supera los 50 milisegundos cuenta. Una tarea de 70 milisegundos contribuye 20 milisegundos, no 70.
• Optimizar fuera de la ventana de medición. Lighthouse TBT suma el bloqueo entre FCP y TTI. El trabajo antes o después de esa ventana puede importar a los usuarios, pero no es parte de ese valor de TBT.
• Eliminar código de primera parte mientras se ignora el tercero más grande. Usa el trace y los iniciadores de solicitudes para atribuir tareas largas antes de elegir un responsable o una corrección.
• Dividir código sin reducir trabajo. Muchas tareas más pequeñas pueden mejorar la capacidad de respuesta, pero enviar el mismo JavaScript innecesario aún cuesta análisis, compilación y ejecución. Elimina el trabajo no utilizado además de cederlo.
• Asumir que un buen TBT de laboratorio demuestra un buen INP de campo. Los usuarios reales interactúan después de la carga en dispositivos variados. Confirma el resultado con datos de capacidad de respuesta de campo.

TBT es alto pero la red parece rápida

Síntoma: Los recursos se descargan rápidamente, pero Lighthouse reporta bloqueo pesado.

Causa probable: El análisis, la compilación, la ejecución, la hidratación o el trabajo de terceros monopolizan el hilo principal después de que llegan los bytes.

Corrección y confirmación: Graba un trace de rendimiento, ordena las tareas largas por duración y propietario, luego elimina código no utilizado, difiere trabajo no crítico o divide la tarea más grande. Confirma que la porción de bloqueo cae en ejecuciones coincidentes repetidas.

Un paquete grande se difiere pero TBT sigue alto

Síntoma: Agregar defer cambia el orden de descarga/ejecución sin mover materialmente el TBT.

Causa probable: El mismo código costoso aún se ejecuta dentro de la ventana de FCP a TTI.

Corrección y confirmación: Perfila las funciones dentro de la tarea larga. Divide el código por ruta o interacción, reduce la hidratación o elimina trabajo no utilizado/duplicado; luego verifica que el tiempo de ejecución, no solo el tiempo de inicio de la solicitud, disminuya.

El TBT de Lighthouse es bueno mientras que el INP de campo es deficiente

Síntoma: Las pruebas de laboratorio de navegación parecen receptivas, pero CrUX o RUM informan interacciones lentas.

Causa probable: La tarea problemática ocurre después de la carga inicial o solo después de una interacción real que la navegación estándar de Lighthouse no ejercita.

Corrección y confirmación: Recopila trazas de interacción para las páginas y dispositivos con INP deficiente, reproduce la acción localmente y optimiza el manejo de eventos y el siguiente pintado.

Una tarea larga aparece sin un propietario claro

Síntoma: DevTools o un observador de la API de Long Tasks marca una tarea bloqueante, pero la atribución está en blanco, es genérica o está etiquetada como “desconocido” / “cross-origin”.

Causa probable: Esta es una brecha de cobertura conocida, no un error de medición. La propia especificación de la API de Long Tasks limita lo que informará entre contextos de ejecución: las tareas de ancestros cross-origin “this is not reported because of security” (traducción) «no se informan por motivos de seguridad», y un iframe cross-origin profundamente incrustado “does not receive any information” (traducción) «no recibe ninguna información» sobre una tarea larga en un ancestro cross-origin. El trabajo que ocurre en un Web Worker o en el hilo del compositor del navegador también puede quedar fuera de lo que las superficies de atribución te muestran.

Corrección y confirmación: No concluyas que “no hay terceros involucrados” solo porque nada está nombrado. Verifica con la columna de iniciador del panel de Red, la pestaña de Cobertura y (donde controlas el script) la instrumentación de origen propio dentro de los iframes que posees. Trata una tarea no atribuida como “causa desconocida”, no como “causa ausente”.

El TBT varía bruscamente entre ejecuciones

Síntoma: Una ejecución es verde y la siguiente es deficiente sin ningún despliegue.

Causa probable: Ejecución variable de terceros, tiempos de servidor que cambian la ventana de trabajo, estado de caché o contención de la máquina de prueba.

Corrección y confirmación: Iguala la configuración, ejecuta varias pruebas en frío y compara los propietarios de tareas largas y el resultado mediano en lugar de seleccionar una puntuación.

Convierte una traza en un plan de propiedad

Review this Lighthouse/DevTools trace for Total Blocking Time. For every long task
between FCP and TTI, calculate only duration above 50 ms as blocking time, attribute
the task to first-party code, framework/hydration, or a named third party, and rank
owners by blocking contribution. Propose remove, reduce, defer, split, or yield actions
with a validation test for each. Do not treat TBT as field INP or a direct ranking
factor.

Compara dos trazas de rendimiento

Compare these before/after traces under matched settings. Report FCP, TBT, the largest
long tasks, their initiators, and whether work moved outside the measurement window or
was actually removed. Flag regressions hidden by the aggregate score. Return a verdict,
confidence limits from the supplied runs, and the next smallest experiment. Do not
invent missing timings.

Revisa una decisión de script de terceros

Given this script's business purpose, loading pattern, request initiator, and main-
thread tasks, decide whether to keep, delay, conditionally load, replace, or remove it.
Separate network cost from execution/blocking cost. Include consent and functionality
constraints, owner, implementation step, TBT validation, field-INP follow-up, and
rollback trigger.

Observa tareas largas durante una reproducción

Ejecuta esto temprano en la Consola de DevTools, reproduce la carga o interacción e inspecciona la porción bloqueante de cada tarea:

let observedBlocking = 0;
const observer = new PerformanceObserver(list => {
  for (const task of list.getEntries()) {
    const blocking = Math.max(0, task.duration - 50);
    observedBlocking += blocking;
    console.log({ start: task.startTime, duration: task.duration, blocking });
  }
  console.log('Observed blocking total:', observedBlocking);
});
observer.observe({ type: 'longtask', buffered: true });

Este es un total de depuración para el período que observas, no el TBT oficial de Lighthouse a menos que deliberadamente reproduzcas la misma ventana de FCP a TTI y las condiciones de prueba.

Marca los scripts con el mayor tiempo de evaluación en el hilo principal

Después de grabar una traza de rendimiento de DevTools, usa la vista Bottom-up agrupada por URL. Para un inventario rápido de red junto a ella, este fragmento de Consola lista el JavaScript transferido de mayor a menor:

performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .map(r => ({ script: r.name, transferred: r.transferSize, duration: r.duration }))
  .sort((a, b) => b.transferred - a.transferred);

El tamaño de transferencia grande es solo una pista; la traza de rendimiento es la que atribuye el tiempo de análisis y ejecución al TBT.

Reducción de tareas largas

Prueba a ejecutar: Captura varias trazas de Lighthouse/rendimiento coincidentes antes y después del cambio de JavaScript y compara las tareas largas entre FCP y TTI.

Resultado esperado: La tarea objetivo desaparece, se acorta o se divide en tareas más pequeñas, y el TBT mediano mejora sin retrasar el FCP ni romper la funcionalidad.

Interpretación de fallo: El trabajo se movió a otro paquete/tarea, aún se ejecuta en la misma ventana, o la varianza normal de la ejecución es mayor que el cambio.

Ventana de monitoreo: Prueba inmediatamente en perfiles de laboratorio móvil y de escritorio y observa el INP de campo durante la próxima ventana de informes.

Disparador de reversión: Revierte si las interacciones críticas se rompen, los errores aumentan o una regresión repetible de FCP/LCP/INP supera la mejora del TBT.

Diferimiento de terceros

Prueba a ejecutar: Compara un rastreo en frío con el tercero en su posición actual y con él retrasado hasta el consentimiento, el tiempo de inactividad o la interacción relevante.

Resultado esperado: Sus tareas largas salen de la ventana inicial de TBT mientras el evento de negocio requerido sigue disparándose en el momento previsto.

Interpretación del fallo: Otro cargador lo inyecta antes de tiempo, el código dependiente bloquea la página o el trabajo del hilo principal del script no es el cuello de botella medido.

Ventana de monitoreo: Valida en cada plantilla que cargue el script y monitorea tanto el rendimiento como el evento de negocio después del lanzamiento.

Disparador de reversión: Restaura la ruta de carga anterior si el consentimiento, la analítica, el checkout, los anuncios u otra función requerida pierde eventos válidos.

Seguimiento de la capacidad de respuesta en campo

Prueba a ejecutar: Segmenta el INP de campo para las plantillas/dispositivos afectados después del cambio de TBT en laboratorio, manteniendo anotada la fecha de implementación.

Resultado esperado: La capacidad de respuesta en campo se mantiene estable o mejora; una mejora solo de laboratorio no se reporta como un resultado de usuario hasta que la evidencia de campo lo respalde.

Interpretación del fallo: El trabajo de interacción real ocurre fuera de la carga inicial o la cohorte optimizada es demasiado pequeña para mover el agregado.

Ventana de monitoreo: Revisa durante toda la ventana de reporte de datos de campo y durante interacciones de alto valor.

Disparador de reversión: Investiga o revierte si el INP de campo o el éxito de interacciones críticas regresan de manera consistente después del lanzamiento.

Ponte a prueba: Tiempo de bloqueo total

Cinco preguntas rápidas sobre la matemática y el diagnóstico de TBT. Elige una respuesta para cada una y luego comprueba.

Recursos que valen tu tiempo

Oficial

• Total Blocking Time (TBT) — la definición canónica y el ejemplo resuelto.
• Optimize long tasks — la guía práctica de corrección (scheduler.yield(), agrupación, por qué no isInputPending()).
• Web Vitals — dónde se sitúa TBT en relación con las Core Web Vitals.
• Optimizing Web Vitals using Lighthouse — Addy Osmani; incluye el ejemplo resuelto de eliminación de polyfill (TBT 400→300 ms, puntuación 63→70).

De otros (verifica antes de citar)

• DebugBear — Total Blocking Time — gran profundidad técnica sobre el mecanismo TBT↔INP y la curva de puntuación de Lighthouse.
• NitroPack — What is Total Blocking Time? — la idea de que “el número de tareas ≠ tiempo de bloqueo”.
• BrowserStack — TBT guide y Catchpoint — TBT — descripciones generales orientadas a herramientas/monitoreo.
• web.dev — User-centric performance metrics — el marco de Philip Walton que clasifica TBT como una métrica de laboratorio/responsividad de carga frente a las métricas de campo; marco útil para explicar por qué TBT no aparece en CrUX.
• web.dev — Introducción a la medición de Web Vitals — cubre cómo TBT sirve como proxy de laboratorio para INP cuando la medición de usuarios reales no es posible en entornos simulados.
• WebPageTest — herramienta gratuita de pruebas de laboratorio que reporta TBT junto con desgloses detallados del hilo principal y de la CPU; útil para diagnosticar qué tareas están impulsando una puntuación alta.
• Search Engine Journal — Core Web Vitals coverage — reportaje continuo de la industria sobre actualizaciones de CWV, el papel de TBT en las auditorías y cómo los profesionales interpretan las brechas entre laboratorio y campo.

Estadísticas que vale la pena citar

• El TBT es el 30 % de la puntuación de rendimiento de Lighthouse — el mayor peso de cualquier métrica (LCP y CLS son 25 % cada una; FCP y Speed Index 10 % cada una). Introducido en Lighthouse 10, verificado en vivo el 2026-07-18 como sin cambios hasta Lighthouse 13. Fuente
• La barra de “bueno” es ≤200 ms en móvil (≤150 ms en escritorio); “malo” es >600 ms en móvil (>350 ms en escritorio) — documentación de auditoría de Lighthouse. Fuente
• Un polyfill = siete puntos. Eliminar un único polyfill de Intersection Observer redujo el TBT de 400 ms a 300 ms y elevó la puntuación de rendimiento de Lighthouse de 63 a 70 — una ilustración clara del peso del 30 %. Fuente
• Una tarea de 250 ms contribuye con 200 ms de tiempo de bloqueo — la parte de bloqueo es siempre duration − 50 ms. El ejemplo resuelto de Google suma 345 ms en cinco tareas. Fuente

Registro de cambios