Publicado: 31 de julio de 2025
A partir de Chrome 139, se lanzará una nueva prueba de origen para la API de Soft Navigations con la que ya hemos experimentado. Esta prueba de origen permite que los sitios prueben la API en su sitio con usuarios reales para realizar pruebas de 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 y, luego, actualizar la URL en la barra de direcciones (con un estado del historial para permitir navegaciones suaves hacia atrás y hacia adelante). Para el usuario, se ven igual que las navegaciones convencionales, pero, para el 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", tal como las usan los sitios de aplicaciones de una sola página (SPA). Como no se produce una navegación de página real en una navegación suave, esto significa que JavaScript debe administrar manualmente ciertas acciones que normalmente se producirían en 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 medir las Métricas web esenciales, no son posibles para estas navegaciones.
La API de Soft Navigation permite observar las navegaciones suaves. Si bien el código JavaScript que inicia la navegación suave (por lo general, un framework de JavaScript) sabe cuándo ocurre una navegación, otros códigos JavaScript y el navegador en sí no lo sabrán.
Métricas web esenciales y SPA
Uno de los principales objetivos de la API de Soft Navigation es permitir la medición de las Métricas web esenciales para las SPA. Las métricas web esenciales se miden tanto con el navegador (para que aparezcan en las herramientas, como el Informe sobre la experiencia del usuario en Chrome) como con las bibliotecas de JavaScript de la supervisión de usuarios reales (RUM).
Los frameworks de JavaScript podrían medir algunos aspectos de las métricas web esenciales. En particular, Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS) se basan en elementos primitivos (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, otras métricas, como el Procesamiento de imagen con contenido más grande (LCP), solo las emite el navegador en función de la navegación de la página y se finalizan después de la interacción.
Cómo la API de Soft Navigation permite medir las Métricas web esenciales para las SPA
La primera iteración de la API de Soft Navigation vinculó la heurística de navegación suave con un restablecimiento del LCP. Después de restablecerse, el LCP se puede volver a emitir para las navegaciones suaves en el caso de una nueva pintura con contenido, lo que permite medir esta métrica para las 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 el "pintado con contenido" después de las interacciones. Por el momento, solo se emite para las navegaciones suaves, pero, si se habilita para todas las interacciones, se abren otros casos de uso potenciales más allá del LCP.
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 de la navegación para la que es 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, cuando se emita la entrada de rendimiento, la URL ya habrá cambiado. Incluir la navegación con la entrada facilita mucho la medición de las Métricas web esenciales 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é usar una heurística?
La API de Soft Navigation considera que se produce una navegación suave cuando sucede lo siguiente:
- Se produce una interacción basada en el usuario (no se tienen en cuenta las actualizaciones de URL sin interacción del usuario).
- … lo que genera 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 en el historial.
La API adopta este enfoque basado en la heurística en lugar de permitir que un framework de JavaScript "emita" una navegación suave o se compile sobre 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 de una navegación suave incluso sin una interacción del usuario o una actualización del DOM que consideremos como una navegación que vería el usuario. También pueden actualizar la URL en diferentes momentos: al inicio de la interacción o solo al final cuando se completa, o en cualquier estado intermedio.
En lugar de depender de las opciones de frameworks, 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 métricas web esenciales para las 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 que usan 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 y verificar si la heurística coincide correctamente con tus expectativas sobre cuándo se produjo una navegación suave. ¿Hay casos en los que la API no informa sobre las navegaciones suaves cuando consideras que ocurrieron? Por el contrario, ¿la API se repite en navegaciones que no consideras que son navegaciones suaves?
Entre los ejemplos que hemos visto que causan problemas, se incluyen los casos en los que 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). En ambos casos, se explica que no coinciden 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 parece que se cumplen las heurísticas, pero la API aún no reconoce la navegación suave.
Además, queremos comprender si esta API y el nuevo elemento Interaction to Contentful Paint abordan el caso de uso principal de permitir la medición de las Métricas web esenciales para las SPA.
Queremos que la API sea lo más útil posible, y es mucho más fácil lograrlo 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 les interese medir el rendimiento web de estos sitios que prueben esta API y nos cuenten cómo les funciona.
Cómo probar
La API se puede probar de forma local con opciones de línea de comandos o marcas de Chrome. 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 sobre 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 de web-vitals.
Comentarios
Estamos buscando activamente comentarios sobre este experimento en los siguientes lugares:
- Los comentarios sobre la API deben plantearse como problemas en GitHub.
- Si hay errores en la implementación de Chromium, se deben registrar en el sistema de seguimiento de problemas de Chrome, si aún no se encuentran entre los problemas conocidos.
- Puedes compartir comentarios generales sobre las métricas web vitales en web-vitals-feedback@googlegroups.com.
Si tienes dudas, no te preocupes demasiado. Preferimos recibir comentarios en cualquiera de los dos lugares y con gusto clasificaremos los problemas en ambos lugares y los redireccionaremos a la ubicación correcta.