Índice de velocidad

TL;DR — Speed Index es una puntuación de Lighthouse que mide la rapidez con la que aparece el contenido visible durante la carga. Un valor menor es mejor y se expresa en segundos; en móvil, menos de 3,4 s se considera bueno. No es un Core Web Vital ni afecta directamente al posicionamiento, aunque sus correcciones suelen mejorar métricas que sí forman parte de la experiencia de página.

Qué es Speed Index

Cuando se analiza una página con Lighthouse o PageSpeed Insights, uno de los resultados es Speed Index. La métrica responde a una pregunta sencilla: ¿con qué rapidez se completa visualmente la parte visible de la página?

La mayoría de las métricas de velocidad marca un instante, como First Contentful Paint o Largest Contentful Paint. Speed Index observa toda la carga y calcula el tiempo promedio en que el contenido visible aparece. Una página que pinta casi todo de inmediato obtiene un valor bajo; una que permanece en blanco y muestra el contenido poco a poco obtiene uno alto.

Cómo interpretar la puntuación

Lighthouse califica Speed Index en móvil de la siguiente manera:

• Bueno: 0 – 3,4 s (verde)
• Necesita mejoras: 3,4 – 5,8 s (naranja)
• Deficiente: más de 5,8 s (rojo)

El escritorio es mucho más estricto — bueno es aproximadamente menos de 1,3 s — porque Lighthouse prueba móvil en un dispositivo simulado más lento. Por ello, no debe compararse un número de escritorio con uno de móvil; están en escalas diferentes.

¿Importa para el SEO?

Una distinción importante: Speed Index no es una Core Web Vital, y no es un factor de posicionamiento en Google. Las señales de experiencia de página de Google provienen de Core Web Vitals (LCP, INP y CLS) medidas en usuarios reales. Speed Index no es una de ellas y ni siquiera se mide en usuarios reales — necesita una grabación de video de la carga, que solo ocurre en herramientas de prueba.

Eso no lo hace inútil. Las correcciones que mejoran Speed Index — un servidor más rápido, menos archivos que bloquean el renderizado, texto que permanece visible mientras se cargan las fuentes — son las mismas correcciones que mejoran FCP y LCP. Así que un mejor Speed Index suele ir a la par de un mejor LCP, que sí importa.

La fórmula, el origen en WebPageTest, el peso en Lighthouse y las limitaciones se explican en la pestaña Advanced.

TL;DR — Speed Index mide qué tan rápido se muestra visualmente el contenido durante la carga de la página — el tiempo promedio en que aparece el contenido visible, puntuado en segundos (menor es mejor). Se calcula a partir de un video de la carga sumando el área por encima de la curva de progreso visual, lo que lo convierte en una métrica solo de laboratorio (no está en CrUX, datos de campo de PSI ni en Search Console). Se originó en WebPageTest (Pat Meenan); Lighthouse lo calcula mediante el módulo de código abierto Speedline. No es una Core Web Vital y no es un factor de posicionamiento — es una de las cinco métricas de Lighthouse, con un peso del 10 % en Lighthouse 10. Móvil: Bueno ≤ 3,4 s, Necesita mejoras ≤ 5,8 s, Deficiente > 5,8 s; escritorio bueno ≤ ~1,3 s. No puede ser más rápido que FCP, depende del viewport y mejora con las mismas correcciones que FCP/LCP.

Qué mide realmente Speed Index

La definición de Google es una línea: “Speed Index measures how quickly content is visually displayed during page load.” (traducción) «Speed Index mide qué tan rápido se muestra visualmente el contenido durante la carga de la página.» La palabra clave es visualmente. Speed Index no es una marca de tiempo única como lo son First Contentful Paint y Largest Contentful Paint — es una puntuación compuesta que representa el tiempo promedio en el que se muestran las partes visibles de la página. Cuanto más bajo, mejor, y se informa en segundos.

Un modelo mental claro consiste en trazar un gráfico con el tiempo en el eje X y “porcentaje de la página visualmente completa” en el eje Y, subiendo del 0 % al 100 %. Speed Index es el área por encima de esa curva. Cuanto más rápido sube la curva al 100 %, más pequeño es el área y mejor es la puntuación. Una página que permanece en blanco durante un rato deja un gran rectángulo de área vacía por encima de la línea; una página que pinta rápido no deja casi nada.

Cómo se calcula

Lighthouse captura un video de la carga de la página y calcula la progresión visual entre fotogramas. Cada intervalo de tiempo se pondera según lo incompleta que esté la página en ese momento: un fotograma completamente en blanco cuenta al 100 %, un fotograma mayormente renderizado cuenta muy poco. La fórmula original de WebPageTest es:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

Un ejemplo práctico lo hace concreto. DebugBear analiza una carga de esta manera:

• 0 % completo (0–253 ms) → contribución de 253,0 ms
• 43 % completo (253–403 ms) → contribución de 85,5 ms
• 98 % completo (403–536 ms) → contribución de 2,7 ms
• 99 % completo (536–653 ms) → contribución de 1,2 ms
• Total: 342,3 ms

En el primer bloque, mientras no hay nada visible, todo ese tiempo contribuye con peso completo. Por eso el Speed Index nunca puede ser más rápido que el First Contentful Paint — cada milisegundo antes de que se pinte el primer contenido se cuenta al 100 %.

Lighthouse no implementa su propia versión aquí. Ejecuta el módulo de código abierto Speedline (originalmente de Paul Irish), que aplica la misma metodología de progresión visual desde video que WebPageTest, trabajando con trazas de Chrome DevTools con capturas de pantalla habilitadas. Speedline puede calcular un Speed Index estándar (diferencia de histograma entre el fotograma actual y el final) o una variante perceptual usando SSIM; la variante estándar es la que se muestra normalmente.

Qué es una buena puntuación

Lighthouse 10 califica el Speed Index según datos de sitios web reales del HTTP Archive, y los umbrales difieren notablemente según el dispositivo porque Lighthouse simula un dispositivo móvil de gama media con limitación de velocidad por defecto:

El antiguo punto de referencia de “menos de 1000 ms es bueno”, que aún puede encontrarse, es una guía heredada de WebPageTest para una era y un perfil de conexión específicos — no el estándar móvil actual de Lighthouse. Debe identificarse qué herramienta y qué configuración de dispositivo/red produjeron el número observado, porque la misma página obtiene puntuaciones diferentes en Lighthouse, WebPageTest y GTmetrix.

Dónde se ubica en la puntuación de Lighthouse

El Speed Index es una de las cinco métricas en la puntuación de rendimiento de Lighthouse 10, y tiene un peso del 10 % — empatado con FCP por el peso más bajo:

La conclusión práctica: perseguir el Speed Index de forma aislada tiene un ROI bajo. Total Blocking Time (30 %) y LCP y CLS (25 % cada uno) mueven la puntuación general mucho más. A menos que el Speed Index sea lo que específicamente está fallando, normalmente se obtiene mayor beneficio más arreglando LCP y TBT — y el Speed Index mejora como efecto secundario de todos modos. En PageSpeed Insights aparece el Speed Index en la sección de laboratorio (Lighthouse), no en la sección de datos de campo de arriba.

¿Es el Speed Index un Core Web Vital o un factor de ranking?

No en ninguno de los dos casos, y la distinción importa al explicar un informe a una parte interesada.

• No es un Core Web Vital. Los Core Web Vitals son LCP, INP y CLS, medidos en usuarios reales a través de CrUX. El Speed Index no está en ese conjunto y no aparece en el informe de Core Web Vitals de Search Console.
• No es un factor de ranking directo. La señal de experiencia de página de Google usa datos de campo de Core Web Vitals. El Speed Index es un diagnóstico solo de laboratorio que Google no recopila de usuarios reales, por lo que no hay una ruta directa desde el valor de Speed Index hasta los rankings.

La relación con los rankings es indirecta: los problemas que producen un mal Speed Index — TTFB lento, CSS/JS que bloquea el renderizado, texto invisible durante el intercambio de fuentes — son los mismos que producen un mal FCP y LCP. Al corregirlos, un mejor Speed Index generalmente acompaña a un mejor LCP, que es la parte que Google realmente recompensa.

Por qué es solo de laboratorio

El Speed Index necesita un video cuadro por cuadro del renderizado de la página y, luego, procesamiento de imágenes para calcular la completitud visual en cada cuadro. Eso es demasiado costoso para ejecutarlo en cada visitante real, por lo que solo existe en herramientas sintéticas/de laboratorio: Lighthouse, WebPageTest, GTmetrix. El monitoreo real de usuarios y el conjunto de datos CrUX simplemente no lo incluyen. Para los datos de rendimiento de campo deben usarse Core Web Vitals; el Speed Index es para diagnosticar el renderizado en una prueba controlada.

De dónde viene

El Speed Index se originó en WebPageTest, que Pat Meenan creó y publicó como código abierto en 2008 (la métrica en sí se agregó alrededor de 2012). Fue diseñado para llenar un vacío real en las métricas de la época:

• El inicio del renderizado podía activarse con un solo píxel o un color de fondo, no con contenido significativo.
• La finalización del documento (onload) incluye recursos que están debajo del pliegue y que son irrelevantes.

El Speed Index dividió la diferencia al medir la completitud visual sobre el pliegue a lo largo del tiempo, un mejor indicador de lo que el usuario realmente percibe. Lighthouse adoptó posteriormente esa metodología a través del módulo Speedline, por lo que los números de WebPageTest y Lighthouse comparten un linaje, aunque su limitación de ancho de banda difiera.

Cómo mejorarlo

No existe un truco específico para Speed Index. La orientación de Google indica que cualquier mejora de la velocidad de carga también mejora esta puntuación. En la práctica:

• Reducir el tiempo de respuesta del servidor (TTFB). Cada milisegundo antes del primer byte es tiempo de página en blanco contado con peso completo.
• Eliminar el CSS y JavaScript que bloquean el renderizado. Estos retrasan la primera pintura, que es la parte más costosa de la curva. El CSS crítico debe insertarse en línea y el resto debe diferirse.
• Corregir la carga de fuentes. Durante un intercambio de fuentes, el texto puede ser invisible, contando como 0 % completo en ese lapso. font-display: swap (u optional) mantiene el texto visible. Esta es una de las auditorías que Lighthouse marca explícitamente para el Speed Index.
• Minimizar el trabajo del hilo principal y reducir el tiempo de ejecución de JavaScript: los otros dos diagnósticos que Lighthouse señala como de alto impacto para el Speed Index.
• Priorizar el contenido sobre el pliegue. Al Speed Index solo le importa el viewport visible, por lo que lograr que la primera pantalla se pinte rápido es todo el juego.

Estos se superponen casi por completo con la optimización de FCP y LCP, que es exactamente por lo que Speed Index debe tratarse como una señal corroborante, no como una lista de tareas separada. Antes de aplicar cambios sobre cualquier número individual, debe revisarse la tira de fotogramas de la carga (Lighthouse y WebPageTest generan una) para confirmar qué se está pintando realmente temprano versus tarde, y deben compararse varias ejecuciones repetidas y comparables en lugar de una sola prueba; la nota sobre variabilidad entre ejecuciones aparece a continuación.

Limitaciones que vale la pena conocer

• Solo de laboratorio — nunca refleja la experiencia real de un usuario, solo representa el entorno de prueba.
• Dependiente del viewport — mide el área visible, por lo que móvil y escritorio dan resultados muy diferentes (de ahí los umbrales tan distintos).
• Punto ciego para SPA/AJAX — las aplicaciones de una sola página pueden parecer artificialmente rápidas: el shell se pinta rápidamente mientras el contenido real se carga más tarde sin una actualización de página.
• Carruseles, vídeo con reproducción automática y superposiciones de consentimiento — cualquier cosa que siga cambiando píxeles después de que el contenido significativo se haya cargado puede ser penalizada por seguir registrándose como “incompleto”, el mismo mecanismo que penaliza a los carruseles de rotación automática.
• No es una métrica de “carga completa” — mide la progresión visual por encima del pliegue, no cuándo terminan todos los scripts, imágenes o elementos por debajo del pliegue. La métrica separada Visually Complete de WebPageTest (siempre ≥ Speed Index) es la que detecta un widget de carga diferida tardía.
• La progresión visual no es prueba de utilidad. El Speed Index solo mide el cambio de píxeles contra un fotograma final — no sabe si lo que está en pantalla es legible, está correctamente ordenado, es accesible o es realmente interactivo. Un esqueleto o shell que se pinta rápido puede obtener una buena puntuación mientras el contenido real (y la capacidad de usarlo) llega más tarde; ese es el mismo modo de fallo que el antipatrón de “pintado temprano sin significado” mencionado antes, solo que descrito desde el lado de la métrica.
• Variabilidad entre ejecuciones. Debido a que se deriva de una sola carga grabada, el Speed Index varía con las condiciones de la prueba — la propia guía de puntuación de Google menciona diferencias de dispositivo, extensiones del navegador, software antivirus e incluso cambios de anuncios o pruebas A/B como fuentes de fluctuación de la puntuación que no tienen nada que ver con el código evaluado. Deben compararse distribuciones de ejecuciones repetidas y comparables, no números aislados.

Métricas relacionadas

El Speed Index vive en el mismo cluster de rendimiento web que el centro de Core Web Vitals y sus vecinos. Está más cerca de First Contentful Paint (el Speed Index no puede superar al FCP) y de Largest Contentful Paint (mismas correcciones, mismas causas raíz), se sitúa junto a Total Blocking Time en la puntuación de Lighthouse y aparece dentro de Lighthouse y PageSpeed Insights. Para las métricas de campo que realmente impulsan los rankings, debe consultarse el centro de Core Web Vitals.

Resumen de IA

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

• Speed Index = rapidez con la que el contenido se muestra visualmente durante la carga — una puntuación compuesta (tiempo medio en que aparece el contenido visible), no una marca de tiempo única. Se informa en segundos; cuanto más bajo, mejor.
• Modelo mental: el área por encima de la curva de progreso visual (tiempo vs. % visualmente completo). Se calcula a partir de un vídeo de la carga, ponderando cada intervalo por lo incompleta que sigue estando la página.
• Solo de laboratorio: necesita capturas de pantalla fotograma a fotograma, por lo que no está en CrUX, en los datos de campo de PageSpeed Insights ni en Search Console. Para los datos de campo deben usarse Core Web Vitals.
• Origen: WebPageTest (Pat Meenan, 2008; métrica ~2012). Lighthouse lo calcula mediante el módulo de código abierto Speedline — misma metodología que WebPageTest.
• No es un Core Web Vital, ni un factor de ranking. Los CWV son LCP, INP y CLS. El vínculo con los rankings es indirecto: corregir el Speed Index suele mejorar el FCP/LCP.
• Peso en Lighthouse 10: 10% — empatado con el FCP como el más bajo. El TBT (30%) y el LCP/CLS (25% cada uno) importan mucho más, así que perseguir solo el Speed Index tiene un ROI bajo.
• Umbrales (móvil): Bueno ≤ 3,4 s, Necesita mejorar ≤ 5,8 s, Pobre > 5,8 s; bueno en escritorio ≤ ~1,3 s. No puede ser más rápido que el FCP y depende del viewport.
• Correcciones = correcciones de FCP/LCP: TTFB más rápido, menos recursos que bloquean el renderizado, font-display: swap, menos trabajo en el hilo principal/JS, priorizar el contenido por encima del pliegue.
• Limitaciones: las SPA pueden puntuar artificialmente bien; los carruseles, el vídeo con reproducción automática y las superposiciones de consentimiento pueden ser penalizados; no es una medida de “carga completa”; la progresión visual no es prueba de que el contenido sea legible, accesible o utilizable; y una sola ejecución puede verse afectada por el dispositivo, las extensiones o los cambios de anuncios o A/B que no tienen nada que ver con el código evaluado.

Documentación oficial

Documentación de fuente primaria para Speed Index.

Google / Lighthouse

• Speed Index (auditoría de Lighthouse) — la referencia canónica: definición, cómo Lighthouse lo calcula mediante Speedline, umbrales de puntuación y las auditorías de optimización.
• Puntuación de rendimiento de Lighthouse — donde se encuentran el peso del 10 % de Speed Index y el desglose completo de las métricas.
• Minimizar el trabajo del hilo principal — una de las tres auditorías que Lighthouse marca como de alto impacto para Speed Index.
• Reducir el tiempo de ejecución de JavaScript — la segunda auditoría marcada.
• Garantizar que el texto permanezca visible durante la carga de webfont (font-display) — la tercera auditoría marcada.

Origen / implementación

• Speedline (paulirish/speedline) — el módulo de código abierto que Lighthouse usa para calcular Speed Index a partir de trazas de DevTools.
• Código fuente de Lighthouse — speed-index.js — la constante de descripción de la auditoría.
• WebPageTest — Acerca de — Pat Meenan creó y publicó como código abierto WebPageTest, donde se originó Speed Index.

Citas de la fuente

Declaraciones registradas. Cada enlace de Google/Lighthouse es un enlace profundo que salta al pasaje citado.

Google — qué mide Speed Index

• “Speed Index measures how quickly content is visually displayed during page load.” (traducción) «Speed Index mide la rapidez con la que el contenido se muestra visualmente durante la carga de la página». — Auditoría de Speed Index de Lighthouse. Ir a la cita

Google — cómo se establece la puntuación

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” (traducción) «Tu puntuación de Speed Index es una comparación entre el speed index de tu página y los speed indexes de sitios web reales, basada en datos del HTTP Archive». — Auditoría de Speed Index de Lighthouse. Ir a la cita

Fuentes transmitidas (parafraseadas de documentación secundaria, no citadas textualmente)

• Lighthouse captura un video de la carga de la página, calcula la progresión visual entre fotogramas y genera la puntuación con el módulo Speedline, basándose en los mismos principios que el Speed Index original de WebPageTest. (Auditoría de Speed Index de Lighthouse, sección de cálculo.)
• Cuanto más tiempo esté visible un fotograma y menos completa esté la página en ese momento, más contribuye ese fotograma a la puntuación; y como todo el tiempo anterior al FCP cuenta al 100 %, Speed Index no puede ser más rápido que First Contentful Paint. (DebugBear, documentación de Speed Index.)
• Speed Index solo está disponible en pruebas sintéticas/de laboratorio debido al costo del procesamiento de capturas de pantalla fotograma a fotograma. (DebugBear, documentación de Speed Index.)
• La métrica se añadió a WebPageTest alrededor de 2012, sobre la herramienta que Pat Meenan publicó como código abierto en 2008. (KeyCDN; página Acerca de WebPageTest.)

Hoja de referencia de Speed Index

Umbrales (Lighthouse 10)

Pesos de rendimiento de Lighthouse 10

Datos rápidos

• Mide la integridad visual a lo largo del tiempo (área por encima de la curva de progreso), no un único sello de tiempo. Cuanto más bajo, mejor.
• Solo de laboratorio — no está en CrUX, datos de campo de PSI ni en Search Console.
• No es una señal web esencial; no es un factor de clasificación directo.
• Nunca puede ser más rápido que FCP (el tiempo anterior a FCP cuenta al 100 %).
• Depende de la ventana gráfica — las puntuaciones móviles y de escritorio difieren mucho.
• Calculado por Speedline; originado en WebPageTest (Pat Meenan).

Cómo mejorarlo (igual que FCP/LCP)

• Reducir el TTFB (respuesta más rápida del servidor).
• Eliminar el CSS/JS que bloquea el renderizado, con el CSS crítico incluido en línea.
• font-display: swap / optional para que el texto permanezca visible.
• Minimizar el trabajo del hilo principal y el tiempo de ejecución de JS.
• Priorizar el renderizado por encima del pliegue.

Advertencias

• “Menos de 1 000 ms” es una guía antigua de WebPageTest, no el estándar móvil de Lighthouse.
• Las SPA pueden obtener puntuaciones artificialmente buenas; los carruseles pueden ser penalizados.

Herramientas que informan el índice de velocidad

• Lighthouse (en Chrome DevTools, la CLI o el módulo Node) — informa el índice de velocidad como una de las cinco métricas de rendimiento, calculado mediante Speedline.
• PageSpeed Insights — ejecuta Lighthouse y muestra el índice de velocidad en la sección de laboratorio (Diagnóstico). Nota: la sección de datos de campo en la parte superior usa las señales web esenciales, por lo que el índice de velocidad nunca aparece allí.
• WebPageTest — donde se originó la métrica; informa el índice de velocidad junto con las vistas de película y de integridad visual, con perfiles de conexión configurables.
• GTmetrix — muestra el índice de velocidad en su interfaz, usando datos de WebPageTest; sus números no coincidirán con los de Lighthouse debido a la diferente simulación de dispositivo/red.
• DebugBear — monitoreo sintético con un desglose claro cuadro por cuadro de cómo se calculó la puntuación del índice de velocidad.

Un recordatorio al comparar herramientas: la misma página produce diferentes valores de índice de velocidad en Lighthouse, WebPageTest y GTmetrix debido a sus diferentes supuestos de limitación y dispositivo. La comparación debe hacerse entre condiciones equivalentes.

Errores del índice de velocidad que desperdician tiempo de optimización

• Llamar al índice de velocidad una señal web esencial. Es una métrica de progreso visual solo de laboratorio, no una señal de clasificación de campo. Debe usarse para diagnosticar cómo se llena una página y luego deben verificarse las señales web esenciales reales por separado.
• Comparar umbrales móviles y de escritorio. Lighthouse usa diferentes curvas de puntuación y condiciones de prueba. Debe seguirse un perfil a lo largo del tiempo en lugar de tratar las dos puntuaciones como intercambiables.
• Mejorar el número con una pintura temprana sin significado. Un esqueleto de encabezado puede hacer que el progreso visual comience antes mientras el contenido principal permanece en blanco. Debe revisarse la película de carga junto con la métrica.
• Optimizar cada imagen antes de verificar la ruta crítica. Un TTFB lento, CSS que bloquea el renderizado, fuentes y JavaScript síncrono pueden retrasar toda la secuencia visual. Debe encontrarse el primer cuello de botella en la cascada y rastrearse.
• Esperar un valor estable de una sola ejecución. El índice de velocidad se deriva de un video sintético y se mueve con el entorno de prueba. Deben repetirse ejecuciones comparables antes de declarar una regresión o una victoria.

Evaluación: Speed Index

Cinco preguntas breves sobre lo que mide Speed Index. Se selecciona una respuesta para cada pregunta y después se comprueba el resultado.

Recursos recomendados

Oficial

• Índice de velocidad — auditoría de Lighthouse — la definición canónica, los umbrales y las auditorías de optimización.
• Puntuación de rendimiento de Lighthouse — los pesos de las métricas, incluido el 10 % del índice de velocidad.
• WebPageTest — Acerca de — el origen de la métrica.

Implementación

• paulirish/speedline — el módulo de código abierto que Lighthouse usa para calcular el índice de velocidad.

De otros

• DebugBear — Speed Index — el ejemplo práctico paso a paso más claro del cálculo y de la relación con el FCP.
• KeyCDN — Speed Index — contexto histórico y la fórmula de WebPageTest.
• Catchpoint — Speed Index — heredero del blog de WebPageTest; fórmula de progreso visual y las limitaciones de SPA/carruseles.
• Google Search Central — Core Web Vitals — confirma que LCP, INP y CLS son las señales de clasificación; Speed Index no aparece, lo que refuerza que no tiene un impacto directo en la clasificación.
• web.dev — Descripción general de Vitals — la definición autorizada de Core Web Vitals (LCP, INP, CLS); Speed Index está ausente, útil al explicar por qué no afecta a las clasificaciones.
• WebPageTest — Documentación de Speed Index — antecedentes sobre la creación de WebPageTest por Pat Meenan (código abierto en 2008) y dónde se originó la métrica Speed Index.

Números que vale la pena citar

• Peso de Lighthouse: 10 % de la puntuación de rendimiento en Lighthouse 10 — empatado con FCP por el peso más bajo, muy por detrás de TBT (30 %) y LCP/CLS (25 % cada uno). Fuente
• Móvil “Bien” ≤ 3,4 s; escritorio “Bien” ≤ 1,3 s — umbrales de Lighthouse 10, calibrados con datos de sitios web reales de HTTP Archive. Fuente
• Speed Index ≥ FCP, siempre — todo el tiempo antes del primer pintado de contenido contribuye al 100 %, por lo que Speed Index no puede ser más rápido que First Contentful Paint. Fuente
• Origen: WebPageTest, ~2012 — añadido sobre la herramienta que Pat Meenan publicó como código abierto en 2008. Fuente

Registro de cambios