Fecha de publicación: 31 de julio de 2025
Chrome lanzará una nueva prueba de origen desde Chrome 139 para la API de Soft Navigations con la que hemos estado experimentando anteriormente. Esta prueba de origen permite que los sitios prueben la API en su sitio con usuarios reales para probarla en el campo y proporcionar comentarios al equipo de Chrome.
¿Qué son las navegaciones suaves?
Una navegación suave se produce cuando JavaScript intercepta una navegación (por ejemplo, cuando se hace clic en un vínculo) y actualiza el contenido de la página existente, en lugar de cargar una página nueva. Luego, la URL se actualiza en la barra de direcciones (con un estado de historial para permitir navegaciones suaves hacia atrás y hacia adelante). Para el usuario, se ven igual que las navegaciones convencionales, pero en lo que respecta al navegador, la página sigue siendo la original.
Por qué se necesita la API de Soft Navigation
La API de Soft Navigations es una API propuesta para permitir la detección basada en heurísticas de las llamadas "navegaciones suaves" que usan los sitios de aplicaciones de una sola página (SPA). Como no se produce una navegación de página real para una navegación suave, esto significa que JavaScript debe administrar manualmente ciertas acciones que normalmente ocurrirían para una navegación. Algunas acciones, como la administración del historial de navegación, son posibles con las APIs actuales. Sin embargo, otras acciones, como la medición de las Métricas web esenciales, no son posibles para estas navegaciones.
La API de Soft Navigation permite la observación de navegaciones suaves. Si bien JavaScript que inicia la navegación suave (por lo general, un framework de JavaScript) sabe cuándo se produce una navegación, otros JavaScript y el navegador en sí no lo sabrán.
Métricas web esenciales y SPAs
Uno de los principales impulsores de la API de Soft Navigation es permitir la medición de las Core Web Vitals para las SPAs. El navegador mide las Métricas web esenciales (para mostrar en las herramientas, como el Informe sobre la experiencia del usuario en Chrome) y las bibliotecas de JavaScript de Real User Monitoring (RUM).
Los frameworks de JavaScript podrían medir algunos aspectos de las Core Web Vitals. En particular, Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS) se basan en primitivas (la API de Event Timing y la API de Layout Instability, respectivamente) que se pueden medir en cualquier período para calcular las métricas de INP y CLS. Sin embargo, debido a que el navegador informa y finaliza Largest Contentful Paint (LCP) en función de las navegaciones y las interacciones de la página, los frameworks de JavaScript no tienen visibilidad de nada más que el rendimiento de carga inicial para las SPAs.
Cómo la API de Soft Navigation permite la medición de las Métricas web esenciales para las SPAs
La primera iteración de la API de Soft Navigation combinó la heurística de navegación suave con un restablecimiento de LCP. Después de restablecerse, se puede volver a emitir LCP para navegaciones suaves para una nueva pintura con contenido, lo que permite medir esta métrica para navegaciones suaves.
Esta última iteración adopta un enfoque diferente y desacopla estos conceptos en la API de Soft Navigation y una nueva entrada de rendimiento de Interaction to Contentful Paint. La entrada interaction-contentful-paint mide la "pintura con contenido" después de las interacciones. Por ahora, solo se emite para navegaciones suaves, pero esto abre otros casos de uso potenciales más allá de LCP si se habilita para todas las interacciones.
La API también expandió cada una de las entradas de rendimiento largest-contentful-paint, interaction-contentful-paint, event-timing y layout-shift para incluir un identificador para la navegación de la entrada. Las entradas de rendimiento se emiten después del evento que miden, por lo general, durante el tiempo de inactividad. Esto significa que, a menudo, la URL habrá cambiado cuando se emita la entrada de rendimiento. Incluir la navegación con la entrada facilita mucho la medición de las Core Web Vitals para la URL determinada sin tener que hacer coincidir los tiempos de entrada de rendimiento con los tiempos de entrada de navegación suave.
¿Por qué una heurística?
La API de Soft Navigation considera una navegación suave cuando ocurre lo siguiente:
- Se produce una interacción basada en el usuario (las actualizaciones de URL sin una interacción del usuario no se tienen en cuenta).
- … lo que da como resultado una modificación del DOM y una pintura
- … y se produce una actualización de la URL
- Actualización de la URL, incluido un cambio de historial
La API adopta este enfoque basado en heurísticas en lugar de permitir que un framework de JavaScript "emita" una navegación suave o que se base en la API de Navigation, ya que esto permite una comprensión coherente de lo que constituye una navegación suave, independientemente del framework o de cómo lo use un desarrollador.
Los frameworks o los desarrolladores pueden actualizar la URL para una navegación suave, incluso sin una interacción del usuario o una actualización del DOM que consideremos lo que un usuario vería como una navegación. También pueden actualizar la URL en diferentes momentos: al comienzo de la interacción o solo al final cuando se completa, o en cualquier estado intermedio.
En lugar de depender de las opciones del framework, la incorporación de la detección de navegación suave en el navegador establece "heurísticas" canónicas (con tus comentarios de esta prueba de origen) que nos permitirán medir las Core Web Vitals para navegaciones suaves a gran escala y hacer que esas mediciones sean comparables a gran escala.
Los frameworks y los desarrolladores también pueden ignorar la heurística de la API de Soft Navigations y usar las APIs subyacentes de Event Timing, Layout Instability y Interaction to Contentful Paint para medir las métricas de rendimiento adicionales que deseen, pero recomendamos las Métricas web esenciales con la heurística para permitir la medición en todos los sitios.
Se necesita ayuda para probar la API de Soft Navigation
Necesitamos ayuda para probar la API de Soft Navigations para verificar si la heurística coincide correctamente con tus expectativas de cuándo se produjo una navegación suave. ¿Hay casos en los que la API no informa navegaciones suaves cuando consideras que se produjeron? Por el contrario, ¿la API repite en exceso las navegaciones que no consideras que sean suaves?
Entre los ejemplos que hemos visto que causan problemas, se incluyen cuando se actualiza una URL con replaceState en lugar de agregar un historial o cuando se produce una navegación que no inicia el usuario (por ejemplo, un cierre de sesión por tiempo de espera). Ambos casos se explican por no coincidir con la heurística, y el equipo de Chrome se siente cómodo con no incluirlos, pero queremos saber si los desarrolladores web están de acuerdo. En particular, queremos conocer los casos en los que la heurística parece cumplirse, pero la API aún no reconoce la navegación suave.
Además, queremos comprender si esta API y la nueva primitiva de Interaction to Contentful Paint abordan el caso de uso principal de permitir la medición de las Core Web Vitals para las SPAs.
Queremos que la API sea lo más útil posible, y eso es mucho más fácil de lograr antes de que se lance y los sitios comiencen a depender de una implementación. Por lo tanto, les pedimos a los desarrolladores de SPA y a quienes estén interesados en medir el rendimiento web de estos sitios que prueben esta API y nos informen cómo funciona.
Cómo realizar pruebas
La API se puede probar de forma local con marcas de Chrome o opciones de línea de comandos. Además, se puede probar en el campo con la prueba de origen.
Consulta nuestra documentación o el repositorio de GitHub para obtener más detalles técnicos de la API y, en particular, cómo medir las Core Web Vitals. Además, está disponible una versión experimental de navegación suave de la biblioteca web-vitals.
Comentarios
Buscamos activamente comentarios sobre este experimento en los siguientes lugares:
- Los comentarios sobre la API deben plantearse como problemas en GitHub.
- Los errores en la implementación de Chromium deben plantearse en el registro de errores de Chrome, si aún no es uno de los problemas conocidos.
- Los comentarios generales sobre las Métricas web esenciales se pueden compartir en web-vitals-feedback@googlegroups.com.
Si tienes dudas, no te preocupes demasiado. Preferimos recibir los comentarios en cualquier lugar y, con gusto, clasificaremos los problemas en ambos lugares y los redireccionaremos a la ubicación correcta.