Time to Interactive (TTI)

TL;DR — Time to Interactive (TTI) medía cuánto tardaba una página en volverse fiablemente clicable: no solo dibujada en pantalla, sino realmente capaz de responder cuando se toca o se hace clic. Antes formaba parte de su puntuación de Lighthouse. Ya no: Google la eliminó de Lighthouse en 2023 porque el número oscilaba demasiado. Nunca fue una Core Web Vital (métrica web esencial) y nunca afectó a su posicionamiento en Google.

Qué era Time to Interactive

Una página puede parecer terminada antes de estarlo. El texto está ahí, los botones se ven, pero si el JavaScript aún no ha terminado de cargarse y ejecutarse, pulsar un botón no hace nada, o tarda un segundo en responder. Esa distancia entre «parece lista» y «está lista» es exactamente lo que TTI se diseñó para detectar.

TTI marcaba el momento en que una página había cargado sus subrecursos principales y podía responder de forma fiable a las interacciones. Antes de ese punto, la página podía estar bloqueada aunque pareciera terminada.

Por qué es posible que aún la vea

Si está leyendo una auditoría antigua, un tutorial desactualizado o un panel heredado que sigue mostrando «Time to Interactive», esta es la versión corta: esa métrica está retirada. Google la eliminó de la puntuación de rendimiento de Lighthouse en Lighthouse 10, en 2023. PageSpeed Insights ya no la puntúa. Cualquier artículo que le diga que «baje su TTI por debajo de 3,8 segundos» está citando un tramo de puntuación que ya no existe.

Las dos cosas que la gente confunde

TTI nunca fue una Core Web Vital. Las Core Web Vitals son LCP, INP y CLS; TTI nunca estuvo en esa lista. Y TTI nunca afectó a su posicionamiento en Google, ni siquiera cuando todavía se puntuaba en Lighthouse. Siempre fue un número de diagnóstico, no una señal de posicionamiento.

Así que, si un informe antiguo señala su TTI, no hace falta alarmarse ni perseguirlo. Lo que TTI intentaba medir —si su página responde rápido a personas reales— hoy lo miden mejor otras dos métricas: TBT en laboratorio e INP en campo.

¿Quiere la historia completa: cómo se calculaba TTI, por qué exactamente se eliminó, adónde fue su peso del 10 % y por qué una parte de ella sigue funcionando dentro de otra métrica? Cambie a la pestaña Avanzado.

TL;DR — TTI es una métrica de laboratorio retirada de Lighthouse: el tiempo desde el inicio de la carga hasta que los subrecursos principales de una página se han cargado y esta puede responder de forma fiable a las interacciones. Eliminada de la puntuación de rendimiento de Lighthouse en Lighthouse 10 (2023) por ser demasiado sensible a peticiones de red atípicas y a tareas largas; su peso del 10 % pasó a CLS (ahora el 25 %). Nunca fue una Core Web Vital (métrica web esencial: esas son LCP, INP y CLS) ni nunca fue un factor de posicionamiento. El valor bruto se sigue calculando en la salida JSON de Lighthouse (la auditoría interactive) con peso 0, oculto en el informe HTML: los scripts de CI heredados siguen funcionando. Y su lógica de «ventana de silencio» todavía define dónde termina la ventana de medición de Total Blocking Time (FCP → TTI). Bing no publica ninguna guía sobre TTI. Use TBT (laboratorio) e INP (campo) en su lugar.

Qué medía TTI en realidad

La definición de Google, tomada de la página de TTI en web.dev, es precisa: “The TTI metric measures 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) «La métrica TTI mide el tiempo desde que la página empieza a cargarse hasta que sus subrecursos principales se han cargado y es capaz de responder de forma fiable y rápida a las interacciones del usuario.» (fuente)

El problema que buscaba detectar es la trampa de «parece interactiva pero no lo está». Técnicas como el renderizado en el servidor pueden hacer que una página parezca lista —con enlaces y botones ya dibujados en pantalla— antes de que su JavaScript se haya cargado realmente, de modo que esos controles están visibles pero no funcionan. TTI era el número que indicaba cuándo la página dejaba de mentirle al usuario.

La misma trampa sigue apareciendo hoy, con TTI o sin ella: una aplicación de página única (SPA) renderizada en el cliente a la espera de la hidratación (hydration), o un script de terceros pesado que ocupa el hilo principal después de que se haya pintado el armazón de la página, producen ambos el mismo hueco de «visible pero no funcional». La métrica que lo medía ha desaparecido; el modo de fallo subyacente, no.

El antiguo documento de la auditoría de Lighthouse detallaba una prueba de tres partes para considerar una página «totalmente interactiva»: la página muestra contenido útil (medido por First Contentful Paint), hay controladores de eventos registrados para la mayoría de los elementos visibles de la página, y la página responde a las interacciones del usuario en menos de 50 milisegundos. (documento de la auditoría de Lighthouse)

Cómo se calculaba TTI (la «ventana de silencio»)

Esta es la parte que más importa para entender por qué se eliminó, y por qué una parte de ella sobrevive. Lighthouse calculaba TTI en cuatro pasos:

1. Empezar en First Contentful Paint (FCP).
2. Buscar hacia delante una ventana de silencio de al menos cinco segundos, definida como la ausencia de tareas largas y no más de dos peticiones de red GET en curso.
3. Buscar hacia atrás desde esa ventana de silencio la última tarea larga anterior, deteniéndose en FCP si no había ninguna tarea larga.
4. TTI es el instante de finalización de esa última tarea larga anterior a la ventana de silencio (o el mismo valor que FCP si no se encontraron tareas largas).

Lea otra vez el paso 2, porque ahí está todo el problema. TTI dependía de encontrar cinco segundos de silencio. Eso la hacía frágil: una sola petición de red lenta y atípica, o una única tarea larga que caiga cerca del final de la carga de la página, puede desplazar la «ventana de silencio» varios segundos más tarde y hacer oscilar TTI de forma drástica sin que cambie en absoluto la sensación real de la página para el usuario.

¿Es TTI una Core Web Vital? No: nunca lo fue

Respuesta directa: no. Las tres Core Web Vitals son LCP (carga), INP (capacidad de respuesta) y CLS (estabilidad visual). TTI es anterior a ese conjunto: la iniciativa Core Web Vitals se lanzó en mayo de 2020, y TTI ya existía como métrica general de «capacidad de respuesta durante la carga» de Lighthouse mucho antes. Nunca se integró en las Core Web Vitals y se retiró por completo de Lighthouse antes de que las Core Web Vitals tuvieran ocasión alguna de absorberla. (Para la taxonomía completa de qué es y qué no es una Core Web Vital, consulte el hub de Web Vitals.)

¿TTI sigue en Lighthouse / PageSpeed Insights? No: se eliminó en Lighthouse 10

TTI fue una métrica de la puntuación de rendimiento de Lighthouse desde las primeras versiones de Lighthouse hasta Lighthouse 9, y se eliminó en Lighthouse 10 (2023). Las notas de la versión de Lighthouse 10 son tajantes sobre el motivo: “TTI marks a point in time, but the way it’s defined makes it overly sensitive to outlier network requests and long tasks.” (traducción) «TTI marca un punto en el tiempo, pero la forma en que está definida la hace excesivamente sensible a peticiones de red atípicas y a tareas largas.» (fuente) Esa es la fragilidad de la ventana de cinco segundos de silencio, expresada como el motivo oficial.

La eliminación no fue un único interruptor accionado en todas partes a la vez: llegó de inmediato a la CLI de npm y a Chrome Canary, aterrizó en Chrome estable con Chrome 112 y alcanzó PageSpeed Insights unas semanas después. Todos esos plazos se cerraron hace años, así que hoy todas las superficies reflejan el cambio; pero conviene saberlo si está intentando datar un informe antiguo o explicar por qué dos herramientas discreparon durante un tiempo a principios de 2023.

Dos consecuencias importantes de la eliminación:

• Su peso del 10 % pasó a Cumulative Layout Shift. La cuota de CLS en la puntuación de rendimiento de Lighthouse subió al 25 %. Por eso la eliminación de TTI es la razón de que CLS pese más en la puntuación de lo que cabría esperar. (No pasó a TBT: TBT conservó su propio peso.)
• El valor bruto sigue existiendo. Lighthouse sigue calculando TTI internamente: vive en la salida JSON como la auditoría interactive, con peso de puntuación 0 y oculta en el informe HTML. La propia nota de Google indica que el acceso mediante scripts al valor del JSON debería seguir funcionando sin cambios. Así que, si tiene un presupuesto de rendimiento en CI ligado a interactive en el JSON de Lighthouse, no se romperá: sencillamente estará siguiendo un número sin puntuación ni peso. Ese es un detalle de profesional que casi ningún artículo del tipo «qué es TTI» menciona, y conviene conocerlo antes de arrancar una comprobación de un pipeline que sigue pasando. Esa promesa de compatibilidad del JSON se hizo en las notas de la versión de Lighthouse 10, en febrero de 2023; he revisado las notas de versión de Lighthouse hasta la v13.4 actual y no he encontrado nada que la revise ni la revoque, así que tómela como exacta en el momento de esa comprobación y no como una garantía permanente.

Qué sustituyó a TTI

El documento de Google sobre TTI es explícito respecto a qué usar en su lugar: métricas más recientes 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. (fuente) Traducido a lo que hace cada una:

• LCP cubre la pregunta de «¿ya está cargada?» de forma más robusta que un recuento de peticiones de red activas.
• TBT es el sustituto de laboratorio para la interactividad: trata las tareas largas y la disponibilidad del hilo principal de forma más directa, y correlaciona mejor con las Core Web Vitals.
• INP es la Core Web Vital real para la capacidad de respuesta, medida a partir de interacciones de usuarios reales en campo.

Ninguna de estas tres es un sustituto exacto de TTI: web.dev las llama “usually better metrics to use in place of TTI,” (traducción) «métricas normalmente mejores para usar en lugar de TTI», no equivalentes, y ese matiz importa. TTI intentaba responder a tres preguntas distintas con un único número inestable: si la página está visualmente terminada (eso es ahora tarea de LCP), si el hilo principal está bloqueado durante la carga (tarea de TBT) y si el toque o la pulsación de tecla de un usuario real va lento (tarea de INP). Dirija su pregunta a la métrica creada para ella en lugar de buscar un único reemplazo directo.

TTI frente a TBT: la relación que sobrevive

Esta es la parte interesante: TTI no ha desaparecido del todo de la metodología de Lighthouse. Su definición de ventana de silencio se reutiliza para definir dónde termina la ventana de medición de TBT. Total Blocking Time suma la porción de bloqueo (el tiempo por encima de 50 ms) de cada tarea larga entre First Contentful Paint y TTI. Así que, aunque TTI no se puntúe, Lighthouse sigue calculando internamente un valor equivalente a TTI solo para saber cuándo dejar de sumar TBT. TTI marca un único punto en el tiempo; TBT suma el tiempo bloqueado hasta ese punto. Están relacionadas, pero no miden lo mismo: TBT heredó de hecho la ventana de TTI en lugar de sustituir lo que TTI medía.

TTI frente a INP

TTI era una métrica exclusiva de laboratorio y ligada al tiempo de carga de la página. INP es una Core Web Vital medida a partir de interacciones de usuarios reales en campo (mediante CrUX), reportada en el percentil 75 del conjunto de visitas, y sí es una señal de posicionamiento de Google. TTI nunca lo fue. Si le importa la interactividad para el SEO, INP es la métrica que cuenta; TBT es el diagnóstico de laboratorio que hace sus veces cuando no puede medir interacciones reales.

¿TTI afecta al posicionamiento SEO? No

Ninguna documentación oficial de posicionamiento de Google ha nombrado nunca a TTI como factor de posicionamiento, ni siquiera antes de que se eliminara de Lighthouse. Siempre fue un diagnóstico de laboratorio, nunca parte de Page Experience. Cabe destacar que TTI nunca generó el ciclo de noticias de «¿es esto un factor de posicionamiento?» que sí generaron las Core Web Vitals: no hubo ninguna polémica dedicada en Search Engine Roundtable, Search Engine Land o Search Engine Journal sobre TTI como señal, precisamente porque siempre fue, de forma evidente, un diagnóstico exclusivo de laboratorio.

Aquí es donde se aplica mi visión más general sobre las métricas de interactividad, y se aplica con más fuerza aquí que en casi ningún otro sitio. En la guía de Core Web Vitals de Ahrefs he dicho claramente que no creo que las Core Web Vitals tengan mucho impacto en el SEO y que, salvo que un sitio sea extremadamente lento, por lo general no priorizaré arreglarlas; y, si quiere defender mejoras en las Core Web Vitals, es difícil argumentarlo solo por motivos de SEO. Si eso es cierto para las métricas que sí son señales de posicionamiento confirmadas, lo es doblemente para TTI, que está retirada y además nunca fue un factor de posicionamiento. La lección de TTI no es «optimice este número» —literalmente no puede, ya no se puntúa—, sino «no persiga métricas obsoletas y de bajo retorno». Haga el trabajo de rendimiento por los usuarios y las conversiones, y mídalo con las métricas que están realmente vigentes.

¿Bing usa Time to Interactive? No

No hay ninguna postura oficial de Bing sobre TTI que citar, porque Bing no habla de TTI en absoluto. Ninguna documentación de Bing Webmaster Tools, entrada de blog o página de ayuda la menciona. Cuando el propio equipo de ingeniería de Bing explicó cómo mide el rendimiento de la página de resultados de bing.com (Driving Performance at Microsoft Bing), describió métricas propias por fases de renderizado —First Render, First Results Render y Above Fold Render— y no mencionó nunca TTI, TBT ni el vocabulario de Core Web Vitals de Google. Es un vacío útil de cubrir: no dé por hecho que Bing replica el conjunto de métricas de Lighthouse de Google. No lo hace.

Umbrales heredados de TTI (solo como referencia histórica)

Si necesita interpretar un informe antiguo, los tramos de puntuación para móvil anteriores a Lighthouse 10 eran: bueno ≤ 3,8 s, moderado 3,9–7,3 s, deficiente > 7,3 s, con la recomendación general de Google de apuntar a un Time to Interactive de menos de 5 segundos en hardware móvil medio. Esa tabla de puntuación se actualizó oficialmente por última vez en 2019. Tómelos como contexto puramente histórico: no existe ningún tramo «bueno» puntuado actualmente, porque hoy TTI tiene peso cero en la puntuación.

¿Debería seguir importándole TTI?

La respuesta honesta depende de quién sea usted:

• Si es SEO o propietario de un sitio: no. No audite TTI, no fije objetivos para ella y no deje que un informe antiguo le asuste. No se puntúa, no es una Core Web Vital y nunca fue un factor de posicionamiento.
• Si es una persona desarrolladora con un presupuesto de rendimiento en CI heredado: su valor interactive en el JSON de Lighthouse sigue funcionando y no romperá su pipeline, pero ahora es un número sin puntuación. Considere reapuntar esa comprobación a TBT (interactividad en laboratorio) o a una Core Web Vital real.
• Para todo el mundo: el instinto diagnóstico de TTI —detectar páginas que parecen interactivas pero no lo son— no ha desaparecido. Hoy lo capturan mejor TBT en laboratorio e INP en campo. Ahí es donde está la acción de verdad.

Para ver dónde encaja TTI entre las métricas retiradas y cómo se organiza todo el programa de Web Vitals, los artículos hermanos de este —Total Blocking Time, First Contentful Paint, Speed Index y las explicaciones de Lighthouse y CrUX— cubren el terreno adyacente, y el clúster de rendimiento web lo une todo.

Resumen con IA

Una versión condensada de la pestaña Avanzado:

• TTI = una métrica de laboratorio retirada de Lighthouse. Marcaba el tiempo desde el inicio de la carga hasta que los subrecursos principales de una página se habían cargado y esta podía responder de forma fiable a las interacciones.
• Eliminada de la puntuación de rendimiento de Lighthouse en Lighthouse 10 (2023) por ser “overly sensitive to outlier network requests and long tasks.” (traducción) «excesivamente sensible a peticiones de red atípicas y a tareas largas.» Su peso del 10 % pasó a CLS (ahora el 25 %), no a TBT.
• Nunca fue una Core Web Vital (esas son LCP, INP y CLS) ni nunca fue un factor de posicionamiento de Google.
• El valor bruto sigue existiendo en la salida JSON de Lighthouse (la auditoría interactive) con peso 0, oculto en el informe HTML: los presupuestos de CI heredados no se rompen, solo pasan a seguir un número sin puntuación.
• La lógica de la «ventana de silencio» sobrevive dentro de TBT: TBT suma el tiempo de bloqueo de las tareas largas entre FCP y TTI, así que Lighthouse sigue calculando internamente un valor equivalente a TTI.
• Cálculo: empezar en FCP → buscar hacia delante una ventana de silencio de 5 segundos (sin tareas largas, ≤ 2 peticiones GET en curso) → buscar hacia atrás la última tarea larga anterior → TTI = el final de esa última tarea larga. Esa dependencia de 5 segundos de silencio es lo que la hacía volátil.
• Qué usar en su lugar: LCP (carga), TBT (sustituto de la interactividad en laboratorio), INP (interactividad en campo, la Core Web Vital real). No es un cambio uno a uno: cada una responde a una pregunta distinta que TTI mezclaba en un solo número inestable.
• Bing no tiene ninguna guía sobre TTI; su blog de ingeniería usa métricas propias por fases de renderizado (First Render, First Results Render, Above Fold Render).
• Tramos heredados (solo históricos): bueno ≤ 3,8 s, moderado 3,9–7,3 s, deficiente > 7,3 s (móvil, anteriores a 2023); ya no se puntúan.
• La opinión de Patrick: no persiga una métrica obsoleta, sin puntuación y que nunca fue de posicionamiento; optimice para los usuarios y mida la interactividad con TBT e INP.

Documentación oficial

Documentación de fuente primaria sobre TTI y sus sustitutas.

Google / web.dev / Chrome

• Time to Interactive (TTI): la definición canónica, el problema de «parece interactiva pero no lo está», el cálculo de la ventana de silencio, la nota sobre la eliminación y la recomendación de usar LCP/TBT/INP en su lugar.
• Time to Interactive (documento de la auditoría de Lighthouse): la página heredada de la auditoría, con la prueba de tres partes de «totalmente interactiva» y la tabla de puntuación anterior a 2023 (hoy lleva un aviso de precaución).
• What’s new in Lighthouse 10: el anuncio de la eliminación; por qué se descartó TTI, adónde fue su peso del 10 % (a CLS) y la nota de que el valor bruto permanece en la salida JSON con peso 0.
• Total Blocking Time (TBT): la métrica cuya ventana de medición sigue terminando en TTI.
• Web Vitals: confirma las tres Core Web Vitals (LCP, INP, CLS); TTI no está entre ellas.
• Are long JavaScript tasks delaying your Time to Interactive?: Addy Osmani sobre cómo las tareas largas ocupan el hilo principal e inflan TTI.

Bing / Microsoft (a modo de contraste: no existe ninguna guía específica sobre TTI)

• Driving Performance at Microsoft Bing: el propio sitio de Bing usa First Render / First Results Render / Above Fold Render, no el vocabulario de TTI ni de Core Web Vitals.

Citas de la fuente

Declaraciones oficiales de los ingenieros y la documentación de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google / web.dev — qué medía TTI

• “The TTI metric measures 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) «La métrica TTI mide el tiempo desde que la página empieza a cargarse hasta que sus subrecursos principales se han cargado y es capaz de responder de forma fiable y rápida a las interacciones del usuario.» — web.dev, Philip Walton. Ir a la cita

Google — por qué se eliminó (Lighthouse 10)

• “TTI marks a point in time, but the way it’s defined makes it overly sensitive to outlier network requests and long tasks.” (traducción) «TTI marca un punto en el tiempo, pero la forma en que está definida la hace excesivamente sensible a peticiones de red atípicas y a tareas largas.» — What’s new in Lighthouse 10. Ir a la cita

Google — qué usar en su lugar

• “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.» — web.dev, Philip Walton. Ir a la cita

Addy Osmani, Google — las tareas largas y TTI

• “Long Tasks can greatly increase your Time to Interactive.” (traducción) «Las tareas largas pueden aumentar en gran medida su Time to Interactive.» — web.dev, “Are long JavaScript tasks delaying your Time to Interactive?” Leer el artículo

Leer una auditoría antigua que menciona TTI: lista de comprobación

Una revisión rápida para cuando «Time to Interactive» aparezca en un informe, una herramienta o un script de CI:

• Confirme la fecha de la fuente: si es anterior a 2023, su enfoque de TTI es previo a la eliminación y sus tramos de puntuación están obsoletos.
• No trate ningún tramo de «TTI bueno ≤ 3,8 s» como vigente: Lighthouse ya no puntúa TTI (peso del 0 % desde Lighthouse 10).
• No informe de TTI a un cliente como si fuera una Core Web Vital: nunca lo fue.
• No informe de TTI como factor de posicionamiento: nunca lo fue.
• Si se trata de un presupuesto de CI ligado a interactive en el JSON de Lighthouse: sigue funcionando, pero es un número sin puntuación; considere reapuntarlo a TBT o a una Core Web Vital real.
• Para diagnosticar de verdad la interactividad, mire TBT (laboratorio) e INP (campo) en su lugar.
• Si las tareas largas son las culpables, la solución es la misma que para TBT/INP: dividir las tareas largas de JS, aplicar code splitting, aplazar o eliminar el JS sin usar y reducir el coste de los scripts de terceros.

Hoja de referencia rápida de TTI

Estado de un vistazo

Cómo se calculaba (la ventana de silencio)

1. Empezar en First Contentful Paint (FCP).
2. Buscar hacia delante una ventana de silencio de ≥ 5 segundos (sin tareas largas, ≤ 2 peticiones GET en curso).
3. Buscar hacia atrás la última tarea larga anterior a esa ventana.
4. TTI = final de esa última tarea larga (o FCP si no hay ninguna). La dependencia de 5 segundos de silencio es la razón de su volatilidad.

Umbrales heredados para móvil (solo históricos: ya no se puntúan)

• Bueno: ≤ 3,8 s · Moderado: 3,9–7,3 s · Deficiente: > 7,3 s
• Antigua recomendación general de Google: menos de 5 s en hardware móvil medio.

Qué usar en su lugar

• Carga → LCP · Interactividad en laboratorio → TBT · Interactividad en campo (la CWV real) → INP

Errores que conviene evitar con Time to Interactive

Llamar Core Web Vital a TTI

TTI nunca fue una Core Web Vital ni una señal de posicionamiento de la Búsqueda. No convierta una etiqueta antigua de Lighthouse en un requisito de SEO vigente.

Perseguir una puntuación de Lighthouse retirada

Lighthouse 10 eliminó el peso de puntuación de TTI porque la métrica era excesivamente sensible a peticiones atípicas y a tareas largas. Use TBT para un diagnóstico de laboratorio reproducible e INP para la capacidad de respuesta con usuarios reales.

Tratar el valor bruto del JSON como una recomendación vigente

La salida heredada puede conservar un valor de TTI con peso cero por compatibilidad. Su presencia no significa que Lighthouse lo puntúe ni que un equipo deba fijar un nuevo objetivo de TTI.

Comparar TTI e INP como si midieran el mismo evento

TTI buscaba una ventana de silencio durante la carga de la página; INP mide interacciones reales de usuarios en campo. Traduzca los hallazgos antiguos de TTI al problema subyacente de tareas largas o de carga y, después, mida ese problema con las métricas actuales.

Recursos que merecen su tiempo

Mis publicaciones relacionadas

• What Are Core Web Vitals (CWVs) & How To Improve Them: mi opinión sobre lo (poco) que las Core Web Vitals mueven el SEO, algo que se aplica con aún más fuerza a una métrica retirada y que nunca posicionó, como TTI.
• The Beginner’s Guide to Technical SEO: dónde encajan las métricas de velocidad de página en el panorama general.

Mis ponencias

• How Search Works (SlideShare): mi recorrido por el rastreo, el renderizado, la indexación y el posicionamiento, para el contexto en el que vive la velocidad de página. (Se aplica mi advertencia habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni precisa».)

Del resto del sector

• Time to Interactive (TTI) (web.dev, Philip Walton): la definición canónica, el cálculo, la nota sobre la eliminación y las sustitutas.
• What’s new in Lighthouse 10 (Chrome DevRel): el anuncio oficial de la eliminación y el traslado del peso a CLS.
• Time to Interactive (documento de la auditoría de Lighthouse) (Chrome): la página heredada de la auditoría, con la prueba de tres partes de «totalmente interactiva».
• Are long JavaScript tasks delaying your Time to Interactive? (web.dev, Addy Osmani): el ángulo de las tareas largas detrás de un TTI deficiente.
• Time to Interactive (DebugBear): el mejor tratamiento técnico de terceros; enmarca la relevancia que TTI conserva a través de TBT.
• Time to interactive (glosario de MDN Web Docs): conciso, en estilo de diccionario; señala que TTI no está estandarizada.
• Driving Performance at Microsoft Bing (Microsoft Bing): cómo mide Bing su propio sitio, con métricas propias en lugar de TTI o de las Core Web Vitals.

Datos que merece la pena citar

• El peso del 10 % de TTI en Lighthouse pasó a CLS (que ahora tiene el 25 %) cuando TTI se eliminó en Lighthouse 10 (2023). No pasó a TBT. Fuente
• El valor bruto de TTI se sigue calculando con peso de puntuación 0, oculto en el informe HTML pero presente en la salida JSON de Lighthouse como la auditoría interactive, de modo que los scripts de CI heredados siguen funcionando. Fuente
• Umbrales heredados para móvil (anteriores a 2023, ya no puntuados): bueno ≤ 3,8 s, moderado 3,9–7,3 s, deficiente > 7,3 s; el antiguo objetivo general de Google era menos de 5 segundos en hardware móvil medio. Fuente
• El cálculo de TTI exige una «ventana de silencio» de 5 segundos (sin tareas largas, ≤ 2 peticiones GET en curso) después de FCP: la dependencia que la hacía volátil y que provocó su eliminación. Fuente

Ponga a prueba sus conocimientos: Time to Interactive

Cinco preguntas rápidas sobre qué era TTI, por qué ha desaparecido y qué sobrevive de ella. Elija una respuesta para cada una y compruebe el resultado.

Registro de cambios