Chrome 151’s Soft Navigations API finalmente permite que las aplicaciones de una sola página (SPA) informen sobre los Core Web Vitals para cada navegación dentro de la aplicación, pero el conjunto de datos CrUX de Google todavía solo registra la primera carga completa (hard load), dejando a los desarrolladores con dos imágenes de rendimiento divergentes.

Por qué las métricas de las SPA se han quedado atrás

Los Core Web Vitals —Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) y Cumulative Layout Shift (CLS)— se definieron en torno a las hard navigations (navegaciones completas). Una navegación completa carga un documento totalmente nuevo y descarta el estado de la página anterior.

Las SPA construidas con React, Vue, Next.js o frameworks similares rara vez activan navegaciones completas. Al hacer clic en un enlace, se actualiza la URL a través de la History API, se obtienen datos en segundo plano y se intercambia el contenido sin una recarga completa. La Performance API existente solo captura la carga inicial de la página, por lo que el LCP y el INP nunca detectan la latencia que sienten los usuarios cuando se mueven de una ruta a otra.

Ese punto ciego sesga los paneles de control que extraen datos de la Performance Timeline o del Chrome User Experience Report (CrUX) de Google. A menudo muestran un LCP excelente para la página "shell" (base), mientras ignoran las cargas más lentas en las profundidades de la aplicación, lo que genera una falsa sensación de salud en el rendimiento.

La API de Soft Navigations de Chrome

Chrome 151 introdujo la Soft Navigations API, un conjunto de heurísticas que trata ciertas interacciones de las SPA como navegaciones reales. La API vigila tres señales:

  • Una interacción iniciada por el usuario (clic, toque, evento de teclado)
  • Un cambio de URL a través de la History API
  • Eventos de renderizado (paint) posteriores que muestran contenido nuevo

Cuando los tres coinciden, Chrome registra una soft navigation en la Performance Timeline, y los Core Web Vitals se calculan para esa transición de la misma manera que para una navegación completa. La biblioteca de código abierto web-vitals añadió soporte el 21 de julio, por lo que los desarrolladores ya pueden empezar a extraer estos números con la misma API que ya utilizan.

En la práctica, ahora verás un valor de LCP para cada cambio de ruta, un INP que refleja la latencia real de la última entrada del usuario y un CLS que captura los cambios de diseño tras una navegación suave (soft navigation).

La división de datos: Chrome vs. CrUX

El CrUX (Chrome User Experience Report) de Google impulsa PageSpeed Insights, Search Console e, indirectamente, las señales de posicionamiento. CrUX sigue agregando únicamente datos de navegaciones completas (hard-navigation).

En consecuencia, terminas con dos flujos de datos consistentes pero diferentes:

  • Las herramientas internas que leen la Performance Timeline ahora muestran LCP, INP y CLS a nivel de ruta, ofreciendo una visión realista de lo que experimentan los usuarios en una SPA.
  • Los conjuntos de datos públicos de Google continúan mostrando métricas solo para la primera carga de la página, que es lo que reporta Search Console y lo que utilizan los algoritmos de clasificación de Google.

Ambos son correctos; simplemente miden momentos diferentes. Confiar únicamente en Search Console puede ocultar regresiones de rendimiento que ocurren después de la carga inicial, mientras que los paneles internos por sí solos no reflejarán la línea base que Google utiliza para el SEO.

Qué deben vigilar los desarrolladores

  • Soporte del navegador – La Soft Navigations API solo está disponible hoy en navegadores basados en Chromium. Safari y Firefox carecen de un equivalente, por lo que debes mantener una lógica de respaldo (fallback) para una parte de tu audiencia.
  • Límites de la heurística – La API decide si hay una navegación suave basándose en un conjunto de señales. Si tu aplicación actualiza el contenido sin cambiar la URL (por ejemplo, superposiciones modales o scroll infinito), la API puede perder esas transiciones, dejando huecos en los datos.
  • Probar antes de confiar – Debido a que la detección es heurística, ejecuta una suite de interacciones del mundo real en tu aplicación y compara las métricas reportadas con la medición manual (por ejemplo, usando performance.mark). Solo después de confirmar la precisión deberías basar tus decisiones de optimización en los nuevos números.

Conclusión

Chrome 151 otorga a los desarrolladores de SPA la tan esperada capacidad de medir LCP, INP y CLS para cada cambio de ruta dentro de la aplicación, pero los datos de clasificación de Google siguen reflejando solo la primera carga completa. Hasta que CrUX se ponga al día, los equipos deberán gestionar dos conjuntos de datos paralelos: uno que cuenta la verdadera historia del usuario y otro que impulsa el posicionamiento en las búsquedas. Equilibrar ambos —y prepararse para un soporte de navegador más amplio— será clave para mantener SPAs centradas en el rendimiento en un ecosistema web competitivo.