Abres la web de un proveedor y el logo aparece al segundo, pero el bloque de servicios sigue en blanco otros dos. No es solo «lentitud»: es una carga visual desigual. El Speed Index (índice de velocidad) resume cuánto tarda el contenido visible en llenar la pantalla durante la carga. En 2026 sigue siendo una métrica de laboratorio muy útil para webs de empresa donde importa la primera impresión antes de que el visitante lea un solo párrafo.
Este artículo explica qué mide el Speed Index, qué umbrales usar en Lighthouse, cómo se relaciona con FCP, LCP y TBT, y qué cambios suelen mejorar la sensación de «la página ya está aquí» sin sacrificar el diseño.
Qué es el Speed Index y qué mide exactamente
El Speed Index es una métrica de laboratorio (Lighthouse, WebPageTest). Calcula la velocidad media a la que el contenido visible se pinta en el viewport, usando capturas del filmstrip de carga. Un valor bajo indica que la página se vuelve útil visualmente pronto; un valor alto sugiere pantallas vacías, placeholders eternos o saltos de contenido tardío.
- No mide un solo elemento como el LCP: resume todo el progreso visual.
- Penaliza páginas que muestran poco al inicio aunque el LCP final sea aceptable.
- Complementa al FCP: el primero marca el primer píxel; el Speed Index mide cómo avanza el resto.
- En informes de PageSpeed aparece en segundos (cuanto menor, mejor).
La documentación de web.dev sobre Speed Index detalla el algoritmo y su papel en auditorías de rendimiento.
Umbrales orientativos en 2026
Lighthouse sigue usando estas referencias para Speed Index en móvil simulado:
- Bueno: 3,4 s o menos.
- A mejorar: entre 3,4 s y 5,8 s.
- Pobre: por encima de 5,8 s.
En desktop los números suelen ser más bajos, pero prioriza las plantillas que reciben tráfico de campañas: home, servicios, landing de producto y formulario de contacto. Un Speed Index en rojo en móvil suele correlacionar con abandono antes del scroll.
Speed Index frente a FCP, LCP y TBT
Core Web Vitals en campo (LCP, INP, CLS) miden experiencia real; el Speed Index ayuda a diagnosticar cómo se siente la carga en laboratorio. Puedes tener un LCP razonable si una imagen hero aparece tarde, pero un Speed Index alto si el resto del layout tarda en rellenarse.
Un FCP rápido con Speed Index alto produce la sensación de «algo apareció, pero la página no termina de cargar». El TBT alto puede retrasar la pintura de componentes hidratados por JavaScript, empujando el índice hacia arriba.
Causas habituales en webs de empresa
- Hero pesado sin prioridad de carga ni tamaños responsivos.
- Fuentes web que bloquean el texto visible (FOIT) o provocan repintados tardíos.
- CSS crítico no inline o bundles enormes antes del primer render.
- JavaScript que oculta contenido hasta ejecutarse (spinners innecesarios).
- Imágenes below-the-fold compitiendo por ancho de banda con el above-the-fold.
- Sliders y vídeos autoplay que retrasan el resto del layout.
La optimización de imágenes y el lazy loading bien aplicado suelen ser las palancas más rápidas cuando el filmstrip muestra huecos largos.
Cómo medir el Speed Index con herramientas accesibles
- PageSpeed Insights / Lighthouse: métrica «Speed Index» en el informe de rendimiento.
- WebPageTest: filmstrip + gráfico de Speed Index por conexión y dispositivo.
- Chrome DevTools → Lighthouse: repetible en local con throttling móvil.
- Comparativa antes/después en la misma URL tras cada despliegue.
Graba siempre la URL, fecha y plantilla. Un recorte de 0,8 s en la home puede no mover el LCP pero sí el Speed Index si el contenido intermedio aparece antes.
Acciones que suelen mejorar el Speed Index
Priorizar lo que se ve primero
Marca la imagen hero y el logotipo con fetchpriority="high", sirve formatos modernos (WebP o AVIF) y define width/height para evitar saltos de layout. Retrasa sliders y mapas con carga bajo demanda.
CSS y renderizado inicial
Reduce CSS bloqueante en la ruta crítica: extrae estilos above-the-fold, elimina reglas no usadas en la home y evita @import en cadena. La minificación ayuda, pero priorizar qué se pinta primero impacta más en el índice.
Fuentes y texto visible
Usa font-display: swap, subconjuntos de caracteres y precarga solo de la variante usada en el hero. El texto legible temprano mejora el filmstrip aunque las imágenes sigan descargando.
Menos bloqueo en la carga inicial
Retrasa scripts no esenciales y reduce tareas largas que impiden pintar secciones. Evita ocultar todo el contenido hasta que React o Vue terminen de hidratar si puedes servir HTML estático visible.
Servidor y red
Un TTFB alto retrasa cualquier pintura. Combina caché, CDN y compresión para que el primer HTML y el CSS crítico lleguen antes.
Errores que mantienen el Speed Index alto
- Optimizar solo el LCP ignorando huecos en el filmstrip intermedio.
- Mostrar un loader a pantalla completa durante tres segundos «por branding».
- Cargar todas las imágenes de la página con prioridad alta.
- Confundir Speed Index con tiempo total de carga o con INP.
- Medir solo en desktop cuando el 70 % del tráfico es móvil.
Checklist rápido antes del próximo despliegue
- Ejecuta Lighthouse en móvil en home y contacto; anota Speed Index, FCP y LCP.
- Revisa el filmstrip: ¿cuántos segundos hay con menos del 50 % del viewport pintado?
- Prioriza hero, tipografía y CSS crítico; retrasa el resto.
- Valida de nuevo tras el despliegue y compara capturas.
Conclusión
El Speed Index no sustituye a los Core Web Vitals de campo, pero explica por qué una web «parece lenta» aunque una métrica aislada esté en verde. En webs de empresa, donde la confianza se gana en los primeros segundos, merece la pena vigilarlo junto al FCP y el LCP. Si necesitas una auditoría priorizada de plantillas críticas, en aatsoft podemos ayudarte a traducir el informe en cambios concretos sin romper marketing ni diseño.
