Cómo medir las navegaciones secundarias

Barry Pollard

Michal Mocny

Fecha de publicación: 1 de febrero de 2023; última actualización: 24 de junio de 2026

Desde su lanzamiento, la iniciativa de Métricas web esenciales ha buscado medir la experiencia real del usuario de un sitio web, en lugar de los detalles técnicos detrás de cómo se crea o carga un sitio web. Las tres métricas de Core Web Vitals se crearon como métricas centradas en el usuario, una evolución de las métricas técnicas existentes, comoDOMContentLoaded o load, que medían los tiempos que a menudo no estaban relacionados con la forma en que los usuarios percibían el rendimiento de la página. Por lo tanto, la tecnología utilizada para crear el sitio no debería afectar la puntuación, siempre y cuando el sitio tenga un buen rendimiento.

La realidad siempre es un poco más compleja que el ideal, y las métricas de Métricas web esenciales nunca admitieron por completo la popular arquitectura de aplicación de una sola página. En lugar de cargar páginas web individuales y distintas a medida que el usuario navega por el sitio, estas aplicaciones web usan las llamadas "navegaciones suaves", en las que el contenido de la página se cambia con JavaScript. En estas aplicaciones, la ilusión de una arquitectura de página web convencional se mantiene alterando la URL y enviando las URLs anteriores al historial del navegador para permitir que los botones de atrás y adelante funcionen como el usuario esperaría.

Muchos frameworks de JavaScript usan este modelo, pero cada uno de una manera diferente. Dado que esto está fuera de lo que el navegador tradicionalmente entiende como una "página", medirlo siempre ha sido difícil: ¿dónde se debe trazar la línea entre una interacción en la página actual y considerarla como una página nueva?

El equipo de Chrome ha estado considerando este desafío durante algún tiempo y busca estandarizar una definición de lo que es una "navegación suave" y cómo se pueden medir las Core Web Vitals para este tipo de navegación, de manera similar a como se miden los sitios web implementados en la arquitectura convencional de varias páginas (MPA).

Implementamos varias mejoras en la propuesta en función de los comentarios de los desarrolladores y nuestro objetivo es lanzar dos nuevas APIs de rendimiento para ayudar a resolver este problema a partir de Chrome 151.

¿Qué es la navegación suave?

Creamos la siguiente definición de navegación suave:

• La navegación se inicia con una acción del usuario.
• La navegación genera un cambio visible en la URL para el usuario.
• La interacción genera una pintura visible.

En algunos sitios, esta definición puede generar falsos positivos (que los usuarios no considerarían realmente como una "navegación") o falsos negativos (en los que el usuario sí considera que hubo una "navegación" a pesar de no cumplir con estos criterios). Agradecemos tus comentarios en el repositorio de especificaciones de navegación suave.

Compatibilidad de DevTools con las navegaciones suaves

Agregamos compatibilidad con las navegaciones suaves en el panel Rendimiento de las Herramientas para desarrolladores en la vista de registro:

Puedes ver marcadores para las navegaciones suaves y el LCP, ambos marcados con un * para ayudar a diferenciarlos de las entradas de navegación dura habituales. Esta opción está habilitada de forma predeterminada y es independiente de los cambios en la API de rendimiento que analizaremos a continuación. Es una forma rápida de probar si la detección de navegaciones suaves funciona correctamente en tu sitio.

Por el momento, solo se muestran las marcas de tiempo de la navegación suave y el LCP en la vista de seguimiento. Más adelante, se agregarán otras métricas (por ejemplo, LCP) y compatibilidad en la vista de Métricas en vivo.

¿Cómo implementa Chrome las navegaciones suaves para los desarrolladores web?

Una vez que se habilite la función de navegación suave (más información en la siguiente sección), Chrome cambiará la forma en que informa algunas métricas de rendimiento:

• Se emitirá un evento soft-navigation PerformanceTiming después de que se detecte cada navegación no definitiva.
• Esta entrada soft-navigation incluirá un navigationId, la nueva URL en el atributo name, así como un interactionId de la interacción iniciadora.
• Se emitirán una o más entradas de interaction-contentful-paint después de las interacciones que provoquen una pintura con contenido. Contendrá una entrada largestContentfulPaint que se puede usar para medir el Largest Contentful Paint (LCP) en las navegaciones suaves.
• El atributo navigationId se agrega a cada uno de los tiempos de rendimiento (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event y layout-shift). Esto corresponde a la entrada de navegación en la que se emitió el evento. Ten en cuenta que, cuando estas entradas abarcan navegaciones suaves, pueden contener el navigationId anterior o siguiente, según el momento en que se emitió la entrada. Obtén más información sobre este tema en la sección Informa las métricas en relación con la URL adecuada.
• El soft-navigation incluirá una función getLargestInteractionContentfulPaint() para recuperar la entrada de interaction-contentful-paint más grande para esa navegación. Luego, se puede usar como el LCP inicial para esa navegación, y ese LCP se puede actualizar a medida que se observan más entradas de interaction-contentful-paint para esa interacción. Ten en cuenta que esto reemplaza un atributo largestInteractionContentfulPaint disponible en pruebas de origen anteriores.
• Es posible que algunas entradas de interaction-contentful-paint hayan ocurrido antes de que se produzca la navegación suave (si la actualización de la URL no se produce hasta después de esas renderizaciones). En estos casos, la función getLargestInteractionContentfulPaint() evita la necesidad de almacenar en búfer y revisar las entradas anteriores después de que se finaliza una navegación suave. Ten en cuenta que la entrada que devuelve getLargestInteractionContentfulPaint() es una copia exacta de la entrada interaction-contentful-paint más grande en el momento en que se emitió, por lo que es posible que esa entrada haya usado el navigationId anterior, ya que fue cuando se produjo el procesamiento de imagen, pero estos procesamientos de imagen se deben medir en función del nuevo navigationId.
• La entrada soft-navigation también incluirá paintTime y presentationTime como el FCP para esa navegación.
• Ten en cuenta que también se emitirán entradas de interaction-contentful-paint después de más interacciones, pero el LCP de una URL debe restringirse a las entradas de interaction-contentful-paint que coincidan con las navegaciones suaves interactionId para excluir estas y también solo a las propiedades de largestContentfulPaint dentro de ellas.

Estos cambios permitirán que las Core Web Vitals —y algunas de las métricas de diagnóstico asociadas— se midan por navegación de página, aunque hay algunos matices que se deben tener en cuenta.

¿Cuáles son las implicaciones de habilitar las navegaciones suaves en Chrome?

Estos son algunos de los cambios que los propietarios de sitios deben tener en cuenta después de habilitar esta función:

• El monitoreo de las entradas de soft-navigation permite "segmentar" las entradas de rendimiento en cada "navegación".
• Las métricas de CLS y INP ya se pueden segmentar a tu discreción, en lugar de medirse durante todo el ciclo de vida de la página, pero la función de navegación suave proporciona una medida estandarizada de cuándo ocurre esto, independientemente de la tecnología subyacente que se utilice.
• La entrada largest-contentful-paint se finaliza en una interacción (lo cual es necesario para iniciar una navegación suave), por lo que solo se puede usar para medir el LCP de la navegación "dura" inicial. Esto significa que no cambiará cuando se midan las navegaciones suaves, por lo que el LCP de la carga de página inicial y de navegación dura se puede medir como siempre.
• La nueva entrada interaction-contentful-paint que se emitirá a partir de las interacciones se puede usar para medir el LCP en las navegaciones suaves si se observa la propiedad largestContentfulPaint dentro de ella, pero hay algunas consideraciones sobre cómo usar esta entrada que analizaremos en este artículo.
• Ten en cuenta que no todos los usuarios admitirán esta función de navegación suave, en especial los que usen versiones anteriores de Chrome y otros navegadores. Ten en cuenta que es posible que algunos usuarios no registren las métricas basadas en la navegación suave, incluso si registran las métricas de Core Web Vitals.

Consulta con tu proveedor de RUM si admite la medición de las Métricas web esenciales por navegación suave. Muchos planean probar este nuevo estándar y tendrán en cuenta las consideraciones anteriores. Mientras tanto, algunos proveedores también permiten mediciones limitadas de las métricas de rendimiento basadas en sus propias heurísticas.

Para obtener más información sobre cómo medir las métricas de las navegaciones suaves, consulta la sección sobre cómo medir las Core Web Vitals por navegación suave.

¿Cómo habilito las navegaciones suaves en Chrome?

El objetivo es que la función de navegación suave esté habilitada de forma predeterminada en Chrome 151, pero está disponible para pruebas antes de eso si se habilita explícitamente.

En el caso de los desarrolladores, pueden habilitar esta opción activando la marca en chrome://flags/#soft-navigation-heuristics. También se puede habilitar con los argumentos de la línea de comandos de --enable-features=SoftNavigationHeuristics cuando se inicia Chrome. Si habilitas la marca chrome://flags/#enable-experimental-web-platform-features, también se habilitan las navegaciones suaves.

Algunos propietarios de sitios web también habilitaron esta función en sus sitios antes del lanzamiento a través del proceso de prueba de origen. Ten en cuenta que la forma de la API cambió durante el desarrollo de la función y que la función final que se lanzó difiere de las pruebas de origen anteriores, como se detalla en el Registro de cambios de Soft Navigations.

Detecta la compatibilidad con la API de Soft Navigations

Puedes usar el siguiente código para probar si se admite la API:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Ten en cuenta que supportedEntryTypes se inmoviliza en el primer uso, por lo que, si un token de prueba de origen insertado en la página agrega de forma dinámica la compatibilidad con las navegaciones suaves, es posible que se muestre el valor original, antes de que se active esa función.

En este caso, se puede usar la siguiente alternativa mientras las navegaciones suaves aún no se admiten de forma predeterminada y se encuentran en este estado de transición:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

¿Cómo puedo medir las navegaciones suaves?

Una vez que se habilite la detección de navegaciones suaves, las métricas se registrarán con la API de PerformanceObserver, como sucede con otras métricas. Sin embargo, hay algunas consideraciones adicionales que se deben tener en cuenta para estas métricas.

Cómo informar navegaciones suaves

Puedes usar un PerformanceObserver para observar las navegaciones suaves. A continuación, se muestra un ejemplo de fragmento de código que registra entradas de navegación suave en la consola, incluidas las navegaciones suaves anteriores en esta página con la opción buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Se puede usar para finalizar las métricas de página de ciclo de vida completo de la navegación anterior.

Informa las métricas en la URL correspondiente

Cuando se detecta una navegación suave, se deben finalizar las Métricas web esenciales de la página anterior y, luego, se deben registrar para la URL anterior. Además, se debe iniciar el nuevo monitoreo para la URL nueva.

El atributo name de la entrada soft-navigation adecuada contendrá la nueva URL para la que se deben informar las métricas, y navigationId será la referencia única para esta navegación (ya que se puede visitar la misma URL varias veces durante la vida útil de una aplicación de una sola página).

Este valor se debe establecer como cada entrada de soft-navigation y se debe usar para informar las métricas hasta que se reciba la siguiente entrada de soft-navigation.

Denuncia la URL correcta de interaction-contentful-paint

Se necesitan consideraciones adicionales para calcular el LCP a partir de las entradas de interaction-contentful-paint, ya que no todas las entradas de interaction-contentful-paint se deben asignar con navigationId ni se deben informar como LCP para esa URL:

• El primer problema es que las entradas de interaction-contentful-paint se pueden emitir antes de que se produzca la navegación suave si se produce una pintura antes de la actualización de la URL. En estos casos, el navigationId será para la URL anterior. Si primero se actualiza la URL, la pintura completará la navegación suave y, en ese caso, primero se emitirá la entrada soft-navigation y la interaction-contentful-paint tendrá la URL nueva.
• El segundo problema es que, en interaction-contentful-paint, se seguirán emitiendo entradas para las interacciones más recientes, ya que el alcance de esta métrica de rendimiento se extiende más allá del LCP para las navegaciones suaves. Solo queremos tener en cuenta las renderizaciones de la carga de navegación suave para el LCP y no las de las interacciones posteriores.

Por lo tanto, se debe usar interactionId en lugar de navigationId para asignar entradas de interaction-contentful-paint a soft-navigation-entries y obtener la URL correcta. Esto controlará las entradas con navigationIds antiguos y filtrará las entradas de interaction-contentful-paint que no se deben tener en cuenta para el LCP.

Además, debes considerar procesar la función getLargestInteractionContentfulPaint() de las entradas soft-navigation también, para controlar con mayor facilidad las entradas interaction-contentful-paint que ocurren antes de que se emita soft-navigation entries.

Cómo obtener el startTime de las navegaciones suaves

Todos los tiempos de rendimiento, incluidos los de las navegaciones suaves, y las entradas que se usan para calcular las métricas de Métricas web esenciales se registran como un tiempo desde el tiempo de navegación inicial de la página "dura". Por lo tanto, el tiempo de inicio de la navegación suave se debe restar de los tiempos de las métricas de carga de la navegación suave (por ejemplo, LCP) para informarlos en relación con este tiempo de navegación suave.

La hora de inicio de la navegación se puede obtener de manera similar asignando la entrada soft-navigation adecuada y usando su startTime.

El objeto startTime es la hora de la interacción inicial (por ejemplo, un clic en un botón) que inició la navegación suave. Esto es algo diferente a las "navegaciones duras", en las que la "hora de inicio" es cuando la página nueva se "confirma" en el navegador y después de que se ejecuta parte del código del controlador de eventos. Los tiempos de inicio de la navegación suave también incluyen ese código del controlador de eventos, ya que medimos desde el tiempo de inicio de la interacción.

Mide las Métricas web esenciales por navegación suave

Para medir Core Web Vitals, escucha las entradas de soft-navigation y restablece las métricas cuando las recibas. El FCP se puede emitir en función de la entrada presentationTime y el LCP se puede inicializar en la entrada getLargestInteractionContentfulPaint(). El INP y el CLS deben inicializarse en 0, como lo harían para una carga de página.

Luego, el LCP, el INP y el CLS se pueden medir y supervisar como de costumbre (con la excepción de usar interaction-contentful-paint para que el LCP proporcione las coincidencias de interactionId). El interactionId se puede usar para nombrar las entradas a una URL como se mencionó anteriormente.

Los tiempos seguirán devolviéndose en relación con la hora de inicio de navegación "fija" original. Por lo tanto, para calcular el LCP de una navegación suave, por ejemplo, deberás tomar el tiempo de interaction-contentful-paint y restarle el tiempo de inicio de navegación suave adecuado, como se detalló anteriormente, para obtener un tiempo relativo a la navegación suave.

Tradicionalmente, algunas métricas se miden a lo largo de la vida útil de la página: el LCP, por ejemplo, puede cambiar hasta que se produce una interacción. El CLS y el INP se pueden actualizar hasta que se abandone la página, independientemente de las interacciones. Por lo tanto, las métricas de la navegación anterior deben finalizarse a medida que se produce cada nueva navegación suave. Esto significa que las métricas de navegación "duras" iniciales pueden finalizar antes de lo habitual cuando se miden las Core Web Vitals con navegaciones suaves.

Del mismo modo, cuando se comience a medir las métricas para la nueva navegación suave de estas métricas de larga duración, las métricas deberán "restablecerse" o "reinicializarse" y tratarse como métricas nuevas, sin memoria de los valores que se establecieron para las "páginas" anteriores. Es decir, se restablece la comprensión de cuál es la pintura, la interacción con la siguiente pintura o el cambio de diseño "más grande" para permitir que se vuelva a medir desde cero.

¿Cómo se debe tratar el contenido que permanece igual entre las navegaciones?

El LCP para las navegaciones suaves (calculado a partir de interaction-contentful-paint) medirá solo las nuevas renderizaciones y solo las renderizaciones asociadas con la interacción que causó la navegación. Esto puede generar un LCP diferente, por ejemplo, desde una carga en frío de esa navegación suave a una carga suave.

Por ejemplo, toma una página que incluye una imagen de banner grande que es el elemento LCP, pero el texto debajo de ella cambia con cada navegación suave. La carga de página inicial marcará la imagen del banner como el elemento LCP y basará el tiempo de LCP en ella. En las navegaciones suaves posteriores, el texto que se encuentre debajo será el elemento más grande que se renderice después de la navegación suave y será el nuevo elemento LCP. Sin embargo, si la página se carga con un vínculo directo a la URL de navegación suave, la imagen del banner será una nueva pintura y, por lo tanto, será apta para considerarse como el elemento LCP.

Del mismo modo, una animación puede actualizar parte de la página de forma continua, sin relación con ninguna navegación suave que ocurra. Las nuevas renderizaciones debido a esa animación de fondo no se considerarían para el LCP de la nueva navegación suave. Sin embargo, se pueden considerar para el LCP si la página se volvió a cargar desde esta URL.

Como muestran estos ejemplos, el elemento LCP para la navegación suave se puede registrar de manera diferente según cómo se cargue la página, de la misma manera que cargar una página con un vínculo de anclaje más abajo en la página puede generar un elemento LCP diferente para las navegaciones duras.

¿Cómo se mide el TTFB?

El tiempo hasta el primer byte (TTFB) para la carga de una página convencional representa el tiempo que tardan en devolverse los primeros bytes de la solicitud original.

En el caso de la navegación suave, esta es una pregunta más difícil. ¿Deberíamos medir la primera solicitud realizada para la página nueva? ¿Qué sucede si todo el contenido ya existe en la app y no hay solicitudes adicionales? ¿Qué sucede si esa solicitud se realiza con anticipación con una carga previa? ¿Qué sucede si un usuario realiza una solicitud que no está relacionada con la navegación suave (por ejemplo, una solicitud de Analytics)?

Un método más simple es registrar un TTFB de 0 para las navegaciones suaves, de manera similar a lo que recomendamos para las restauraciones de la memoria caché atrás/adelante. Este es el método que usa la biblioteca web-vitals para las navegaciones suaves y el que recomendamos para esta métrica en este momento.

¿Deberías medir las Core Web Vitals con ambas metodologías?

Si bien estas nuevas APIs se limitan solo a los navegadores basados en Chromium, es posible que los sitios deseen medir ambos tipos de navegación segmentando por navegaciones suaves y continuando el segmentado por navegaciones duras. Esto permitiría realizar comparaciones entre navegadores y para las tendencias históricas.

En el caso del LCP, esto significa considerar solo las entradas de largest-contentful-paint para la ruta actual y las entradas de largest-contentful-paint y interaction-contentful-paint para la ruta nueva.

En el caso del CLS y el INP, esto significa medirlos en todo el ciclo de vida de la página, como se hace actualmente, y segmentar por separado la línea de tiempo por navegaciones suaves para medir valores de CLS y INP separados para la nueva.

Luego, las métricas se tendrían que balizar y almacenar dos veces para su análisis.

Usa la biblioteca web-vitals para medir las Métricas web esenciales en las navegaciones suaves

La forma más sencilla de tener en cuenta todos los matices es usar la biblioteca de JavaScript web-vitals, que tiene compatibilidad experimental con las navegaciones suaves en un soft-navs branch independiente (que también está disponible en npm y unpkg). Esto se puede medir de la siguiente manera (reemplaza doTraditionalProcessing y doSoftNavProcessing según corresponda):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

La biblioteca web-vitals también garantiza que las métricas se registren en la URL correcta como se mencionó anteriormente, ya que incluyen tanto el navigationId como un navigationURL en las entradas proporcionadas a la devolución de llamada.

La biblioteca de web-vitals informa las siguientes métricas para las navegaciones suaves:

¿Estos cambios formarán parte de las mediciones de Core Web Vitals?

El objetivo final es proporcionar un medio para medir mejor el rendimiento como experiencias de usuarios reales. Por lo tanto, sí, el objetivo es incluir estas métricas en las mediciones de Core Web Vitals que exponen todas las herramientas después del lanzamiento de la API.

Valoramos los comentarios de los desarrolladores web sobre la API y si creen que refleja con mayor precisión la experiencia. El repositorio de GitHub de navegación suave es el mejor lugar para proporcionar esos comentarios, aunque los errores individuales relacionados con la implementación de Chrome deben plantearse en la herramienta de seguimiento de errores de Chrome.

¿Cómo se registrarán las navegaciones suaves en CrUX?

También está pendiente determinar cómo se informarán exactamente las navegaciones suaves en CrUX una vez que se lance la función. Anunciaremos cómo cambiará CrUX cuando tengamos más información para compartir aquí.

Comentarios

Estamos buscando activamente comentarios sobre esta API 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 informar en el sistema de seguimiento de problemas de Chrome, si aún no se trata de uno de los problemas conocidos.
• Puedes compartir comentarios generales sobre las métricas web 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.

Registro de cambios

A medida que se desarrollaba esta API, se produjeron varios cambios en ella, más que con las APIs estables. Puedes consultar el registro de cambios de la navegación suave para obtener más detalles.

Conclusión

La función de Navegaciones suaves es un enfoque interesante sobre cómo podría evolucionar la iniciativa de Core Web Vitals para medir un patrón común en la Web moderna que falta en nuestras métricas. Recopilamos muchos comentarios de la comunidad web en general y recomendamos a quienes estén interesados en este desarrollo que aprovechen esta oportunidad para ayudar a definir las APIs y garantizar que representen lo que esperamos poder medir con ellas.

Agradecimientos

Imagen en miniatura de Jordan Madrid en Unsplash

Este trabajo es una continuación del trabajo que comenzó Yoav Weiss cuando estaba en Google. Agradecemos a Yoav por su trabajo en esta API.