Publicado el 20 de abril de 2026
Chrome planea lanzar la API de Soft Navigations con la que hemos estado experimentando más adelante este año. En preparación para ello, ofrecemos una prueba de origen más a partir de Chrome 147 hasta Chrome 149. Esta prueba incorpora los comentarios de pruebas anteriores en la forma final esperada de la API. Alentamos a los propietarios de sitios web interesados en esta función a que realicen una prueba final de la forma final esperada de la API antes de su lanzamiento.
¿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, mientras que la URL se actualiza en la barra de direcciones. Para los usuarios, estas navegaciones parecen iguales a las convencionales, pero, desde la perspectiva del navegador, la página sigue siendo la original.
Necesidad de la API de Soft Navigation
La API de Soft Navigations es una API propuesta para la detección de navegaciones suaves que usan los sitios de aplicación de una sola página (SPA). Dado que no se produce una navegación de página real en una navegación suave, 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 se produce una navegación, otros códigos JavaScript que usa el sitio (por ejemplo, los de Analytics) y el navegador en sí no lo sabrán.
Core Web Vitals 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 Core Web Vitals se miden tanto por el navegador (para que aparezcan en herramientas como el Chrome User Experience Report) como por los propietarios de sitios que utilizan soluciones de supervisión de usuarios reales (RUM).
Los frameworks de JavaScript pueden medir algunos aspectos de las Core Web Vitals para las SPA. 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 esas métricas. Sin embargo, otras métricas, como el Largest Contentful Paint (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 permite medir las Core Web Vitals para las SPA
La API de Soft Navigation introduce dos nuevas entradas de rendimiento:
- Una entrada de
SoftNavigationEntryque se emite cuando se cumplen todos los requisitos de navegación suave. Esto incluye uninteractionIdpara la interacción que causó la navegación suave, unnavigationIdúnico y unnameestablecido en la nueva URL y varios tiempos de pintura que se pueden usar para medir el primer procesamiento de imagen con contenido de la navegación suave. - Una entrada
InteractionContentfulPaintque permite medir varias pinturas con contenido de tamaño cada vez mayor después de las interacciones para medir el LCP en las navegaciones suaves.
Estas nuevas entradas se pueden observar con un PerformanceObserver usando los tipos soft-navigation y interaction-contentful-paint, respectivamente.
La API también expande cada una de las entradas de rendimiento largest-contentful-paint, interaction-contentful-paint, event-timing y layout-shift (y otras) para incluir un identificador, navigationId, que representa la navegación para la que es la entrada. Dado que los objetos PerformanceObserver no observan las entradas de rendimiento hasta que la página está inactiva, puede transcurrir un tiempo entre el evento que creó la entrada de rendimiento y tu observación de ella. Esto es especialmente cierto cuando la página está muy ocupada, por ejemplo, durante las navegaciones suaves. Este valor de navigationId ayuda a atribuir las entradas a la navegación correcta.
Algunas entradas de interaction-contentful-paint pueden ocurrir antes de la navegación y otras después. En lugar de tener que hacer un seguimiento de todas las pinturas que podrían generar una navegación suave, la entrada soft-navigation incluye una entrada largestInteractionContentfulPaint que es la pintura más grande que se vio hasta el momento.
En conjunto, estas permiten medir las Métricas web esenciales para lo siguiente:
- LCP: Se usa
largest-contentful-paintpara la carga de página inicial y las nuevas entradasinteraction-contentful-paintysoft-navigationpara las navegaciones suaves. - CLS: Se usan entradas de
layout-shifty se segmentan según las entradas desoft-navigationpara las navegaciones suaves. - INP: Se usan entradas de
eventy se segmentan según las entradas desoft-navigationpara las navegaciones suaves. - FCP: Se usa
first-contentful-paintpara la carga de página inicial y los detalles de los tiempos de pintura en las nuevas entradas desoft-navigationpara las navegaciones suaves.
Para obtener más detalles, consulta la documentación sobre Soft Navigations.
¿Cómo se activan las navegaciones suaves?
La API de Soft Navigation activa una navegación suave cuando ocurre lo siguiente:
- Se produce una interacción del usuario.
- … lo que genera una pintura visible del contenido para el usuario.
- … y se produce una actualización de la URL.
La API adopta este enfoque en lugar de permitir que un framework de JavaScript "emita" una navegación suave o se base en la API de Navigation por dos motivos:
- En primer lugar, esto incluye todos los sitios existentes de SPA sin que se requieran cambios en ellos.
- En segundo lugar, permite comprender de manera coherente qué constituye una navegación suave, independientemente de cómo un framework o un desarrollador manejen las navegaciones.
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 los usuarios considerarían una navegación. También pueden actualizar la URL en diferentes momentos: al inicio de la interacción, solo al final cuando se completa o en cualquier estado intermedio.
En lugar de depender de las opciones del framework y del desarrollador, la incorporación de la detección de navegación suave en el navegador establece una definición canónica que permite medir los Core Web Vitals para las navegaciones suaves a gran escala y hacer que estas mediciones sean comparables a gran escala.
Los frameworks y los desarrolladores también pueden ignorar la API de Soft Navigations y usar las APIs subyacentes de Event Timing y Layout Instability, así como la nueva entrada de rendimiento InteractionContentfulPaint para medir las métricas de rendimiento adicionales que elijan. Sin embargo, recomendamos usar la API para medir las Core Web Vitals y, así, habilitar una medición coherente en todos los sitios y las herramientas.
Se necesita ayuda para probar la API de Soft Navigation
Necesitamos tu ayuda para probar la API de Soft Navigations y determinar si coincide correctamente con tus expectativas sobre cuándo ocurre una navegación suave. ¿La API no informa las navegaciones suaves cuando considera que se produjeron? Por el contrario, ¿la API informa en exceso las navegaciones que no consideras como tales?
Qué cambió desde la última prueba de origen
El cambio principal en esta última iteración es la separación de InteractionContentfulPaint de las navegaciones suaves para habilitar otros casos de uso para esa entrada de rendimiento y el atributo largestInteractionContentfulPaint adicional para SoftNavigationEntry.
Desde la perspectiva del sitio web, la API ahora también incluye replaceState como navegaciones suaves porque recibimos sus comentarios de que es importante considerarlo como una navegación en muchas circunstancias. Nos interesa conocer cualquier otro caso en el que la API no reconozca una navegación suave.
También realizamos muchas otras mejoras en la implementación. Para quienes desean saber exactamente qué cambió en la última iteración, pueden consultar el registro de cambios de la navegación suave, que incluye un historial detallado de todos los cambios.
Queremos que la API sea lo más útil posible y estamos abiertos a realizar más cambios para que eso suceda. Es mucho más fácil implementar cambios en la API antes de su lanzamiento y de que 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 envíen sus comentarios al respecto.
Cómo probar
La API se puede probar de forma local con marcas de Chrome o opciones de línea de comandos. Además, puedes probarlo en el campo con la prueba de origen (obtén más información sobre las pruebas de origen).
Consulta nuestra documentación o el repositorio de GitHub para obtener más detalles técnicos sobre la API, en especial cómo medir las Métricas web principales.
Además, hay disponible una versión experimental de navegación suave de la biblioteca de web-vitals en GitHub y npm.
Para una prueba más simple, el panel Rendimiento de las Herramientas para desarrolladores de Chrome muestra la navegación suave en los registros de rendimiento a partir de Chrome 145, incluso sin habilitar la función:
Comentarios
Los comentarios sobre la API deben plantearse como problemas en GitHub, y los errores en la implementación de Chromium deben informarse en la herramienta de seguimiento de errores de Chrome. Si no sabes con certeza en qué categoría se incluye el comentario, no te preocupes demasiado. Preferimos recibir comentarios en cualquiera de los dos lugares, y clasificaremos los problemas en ambos lugares y los redirigiremos a la ubicación correcta.