Cómo medir las navegaciones secundarias

Barry Pollard

Michal Mocny

Fecha de publicación: 1 de febrero de 2023; última actualización: 20 de septiembre de 2026

Desde su lanzamiento, la iniciativa de las Métricas web esenciales buscó 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 tiempos que, a menudo, no estaban relacionados con la forma en que los usuarios percibían el rendimiento de la página. Por este motivo, la tecnología que se usa para compilar el sitio no debería afectar la puntuación, siempre que el sitio tenga un buen rendimiento.

La realidad siempre es un poco más compleja que el ideal, y la popular arquitectura de aplicación de una sola página nunca ha sido totalmente compatible con las métricas de Métricas web esenciales. 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 JavaScript cambia el contenido de la página. 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 retroceso y avance funcionen como el usuario espera.

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", medir esto 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 considerado este desafío durante un 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 esto, de una manera similar a como se miden los sitios web implementados en la arquitectura convencional de varias páginas (MPA).

Realizamos varias mejoras en la propuesta en función de los comentarios de los desarrolladores y lanzamos dos nuevas APIs de rendimiento para ayudar a resolver este problema a partir de Chrome 151. Además, pusimos a disposición las métricas de navegación suave en el Informe sobre la experiencia del usuario en Chrome (CrUX) como métricas experimentales.

¿Qué es una navegación suave?

Se nos ocurrió 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 de URL visible para el usuario.
• La interacción genera un cambio visual en la pantalla.

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 se produjo 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 las Herramientas para desarrolladores con las navegaciones suaves

Agregamos compatibilidad con las navegaciones suaves al panel Rendimiento de las Herramientas para desarrolladores en la vista Métricas en tiempo real y en la vista de seguimiento con compatibilidad con Estadísticas y marcadores:

¿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 estructurada.
• Esta entrada de soft-navigation incluirá un navigationId, la URL nueva en el atributo name y un interactionId de la interacción de inicio.
• Se emitirán una o más entradas de interaction-contentful-paint después de las interacciones que causen un renderizado con contenido. Esto contendrá una entrada largestContentfulPaint que se puede usar para medir el Largest Contentful Paint (LCP) de 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 en la sección Informa las métricas en 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, esto 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 se hayan producido antes de que se realice 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 volver a consultar las entradas antiguas después de que se finaliza una navegación suave. Ten en cuenta que la entrada que muestra getLargestInteractionContentfulPaint() es una copia exacta de la entrada de 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 es cuando se produjo el procesamiento de imagen, pero estos procesamientos de imagen deben medirse con respecto al nuevo navigationId.
• La entrada soft-navigation también incluirá paintTime y presentationTime como el FCP para esa navegación.
• Ten en cuenta que las entradas interaction-contentful-paint también se emitirán después de interacciones adicionales, pero el LCP de una URL debe restringirse a las entradas interaction-contentful-paint que coincidan con las navegaciones de software interactionId para excluirlas y también solo a las propiedades largestContentfulPaint dentro de eso.

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áginas, 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:

• Supervisar las entradas de soft-navigation permite "dividir" las entradas de rendimiento en cada "navegación".
• Las métricas de CLS y el INP ya se pueden segmentar según tu criterio, en lugar de medirse durante todo el ciclo de vida de la página, pero la función de navegación suave proporciona una medición estandarizada de cuándo sucede esto, independientemente de la tecnología subyacente que se use.
• La entrada largest-contentful-paint se finaliza en una interacción (que es necesaria para iniciar una navegación suave), por lo que solo se puede usar para medir el LCP de la navegación "completa" inicial. Esto significa que no cambiará cuando se midan las navegaciones suaves, por lo que la LCP de la carga de página inicial, 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 de las navegaciones de una sola página. Para ello, se debe consultar la propiedad largestContentfulPaint que se encuentra 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 particular, aquellos que usen otros navegadores o versiones de Chrome anteriores a la 151. Ten en cuenta que es posible que algunos usuarios no informen las métricas basadas en la navegación suave, incluso si informan 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 en función de 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 Cómo medir las Core Web Vitals por navegación suave.

¿Cómo habilito las navegaciones suaves en Chrome?

La función de navegaciones suaves está habilitada de forma predeterminada a partir de Chrome 151.

Detección de funciones de la compatibilidad con la API de Soft Navigations

Puedes usar el siguiente código para probar si la API es compatible:

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

O alternativamente:

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

¿Cómo puedo medir las navegaciones suaves?

Cuando se admite, las métricas se pueden informar con la API de PerformanceObserver, como con otras métricas. Sin embargo, hay algunas consideraciones adicionales que se deben tener en cuenta para estas métricas.

Informa las navegaciones suaves

Puedes usar un PerformanceObserver para observar las navegaciones suaves. A continuación, se muestra un fragmento de código de ejemplo que registra las 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 });

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

Informa las métricas en relación con la URL adecuada.

Cuando se detecta una navegación suave, se deben finalizar las Core Web Vitals de la página anterior y, luego, informarlas para la URL anterior. Además, se debe iniciar una nueva supervisión para la URL nueva.

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

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

Denuncia la URL correcta para 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 el navigationId y registrarse como LCP para esa URL:

• El primer problema es que se pueden emitir entradas de interaction-contentful-paint antes de que se produzca la navegación suave si se produce una renderización antes de la actualización de la URL. En estos casos, la navigationId será para la URL anterior. Si la URL se actualiza primero, el procesamiento de imagen completará la navegación suave y, en ese caso, la entrada soft-navigation se emitirá primero, 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á de solo el LCP para las navegaciones suaves. Solo queremos considerar las renderizaciones de la carga de navegación suave para la 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 navigationId antiguos y filtrará las entradas de interaction-contentful-paint que no se deben tener en cuenta para el LCP.

Además, primero debes procesar la función getLargestInteractionContentfulPaint() de las entradas soft-navigation para controlar las entradas interaction-contentful-paint que se produjeron antes de que se emita soft-navigation entries.

Obtén 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 Core Web Vitals se informan como un tiempo desde el tiempo de Navegación de páginas "completa" inicial. Por lo tanto, la hora 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 startTime es el momento de la interacción inicial (por ejemplo, un clic en un botón) que inició la navegación suave. Esto es un poco diferente de las "navegaciones completas", 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 la hora 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. La FCP se puede emitir en función de la entrada presentationTime, y la LCP se puede inicializar en la entrada getLargestInteractionContentfulPaint(). INP y CLS deben inicializarse en 0, como lo harían para una carga de página.

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

Los tiempos se seguirán devolviendo en relación con la hora de inicio de la navegación "hard" 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 restar la hora de inicio de la navegación suave adecuada, como se detalló anteriormente, para obtener un tiempo relativo a la navegación suave.

Tradicionalmente, algunas métricas se miden durante toda la vida de la página: por ejemplo, el LCP 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 "hard" iniciales pueden finalizar antes de lo habitual cuando se miden las Core Web Vitals con navegaciones "soft".

Del mismo modo, cuando se comiencen a medir las métricas de 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 lo que es el procesamiento "más grande", la interacción con el siguiente procesamiento o el cambio de diseño 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) solo medirá las pinturas nuevas y solo las pinturas asociadas con la interacción que causó la navegación. Esto puede generar un LCP diferente entre una carga en frío de esa navegación suave y una carga suave.

Por ejemplo, toma una página que incluya una imagen de banner grande que sea el elemento LCP, pero el texto que aparece debajo cambia con cada navegación suave. La carga inicial de la página marcará la imagen del banner como el elemento de LCP y basará el tiempo de LCP en eso. En las navegaciones de software posteriores, el texto que aparece debajo será el elemento más grande que se renderice después de la navegación de software y será el nuevo elemento de 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, se podrá considerar 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. Cualquier pintura nueva debido a esa animación de fondo no se consideraría para el LCP de la nueva navegación suave. Sin embargo, es posible que se consideren para el LCP si la página se volvió a cargar desde esta URL.

Como se muestra en estos ejemplos, el elemento LCP de la navegación suave se puede informar 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 puede dar como resultado un elemento LCP diferente para las navegaciones duras.

¿Cómo se mide el TTFB?

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

En el caso de una navegación suave, esta es una pregunta más compleja. ¿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 una solicitud no está relacionada con la navegación suave desde la perspectiva del usuario (por ejemplo, si es una solicitud de estadísticas)?

Un método más sencillo es informar un TTFB de 0 para las navegaciones suaves, de manera similar a como recomendamos para los restablecimientos 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 quieran medir ambas métricas dividiendo los datos por navegaciones suaves y por navegaciones duras. Esto permitiría realizar comparaciones entre navegadores y tendencias históricas.

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

En el caso de CLS y INP, esto significa medirlos durante todo el ciclo de vida de la página, como se hace actualmente, y dividir la cronología por separado según las navegaciones suaves para medir los valores de CLS y INP por separado para el nuevo.

Luego, las métricas se deberían enviar y almacenar dos veces para su análisis.

Usa la biblioteca web-vitals para medir las Core Web Vitals de las navegaciones suaves

La forma más sencilla de tener en cuenta todos los matices es usar la biblioteca de JavaScript web-vitals, que admite navegaciones suaves a partir de la versión 6.0.0. 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 informes las métricas con la URL correcta, como se indicó anteriormente, ya que incluyen tanto el navigationId como un navigationURL en las entradas proporcionadas a la devolución de llamada.

La biblioteca 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 según las experiencias de los usuarios reales. Por lo tanto, el objetivo es incluirlas en las mediciones de las Métricas web esenciales que exponen todas las herramientas después de que se lance la API.

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

Lanzamos versiones experimentales de las métricas de Core Web Vitals en CrUX. Estas finalizan las métricas de CLS y de INP de la "navegación completa" después de la primera navegación suave y también incluyen mediciones adicionales de LCP, CLS y de INP para cada navegación suave. Planeamos convertir estas métricas experimentales en métricas estables en mayo de 2027. Para obtener más información, consulta la entrada de blog Métricas experimentales de navegación suave ahora disponibles en CrUX.

¿Cómo controlar las navegaciones suaves en otros navegadores?

Las navegaciones suaves son difíciles de detectar de forma programática en los navegadores que no admiten la API, que es el motivo por el que trabajamos en esta API.

Es posible usar la API de Navigation para supervisar los cambios de URL que pueden permitir la división de la INP por URL (y, de manera similar, el CLS, aunque solo es de Chromium en este momento, por lo que no se mediría de todos modos). Sin embargo, esto no aborda las métricas de renderización (FCP y LCP), que solo se pueden aproximar.

Al mismo tiempo, creemos que las estadísticas que ofrece esta API son demasiado valiosas como para ignorarlas, tanto para medir el tiempo de las navegaciones suaves como para atribuir las métricas a la navegación correcta. Te recomendamos que uses esta nueva API, a pesar de la falta de compatibilidad entre navegadores en este momento. Al igual que cuando se lanzaron las Core Web Vitals, los problemas identificados y las soluciones de rendimiento probablemente afectarán a todos los navegadores, incluso si la visibilidad se limita solo a los navegadores basados en Chromium por el momento.

Seguiremos trabajando en el proceso de estandarización y colaborando con los demás proveedores de navegadores para demostrar la importancia de esta API.

Comentarios

Buscamos activamente comentarios sobre esta API en los siguientes lugares:

• Los comentarios sobre la API se deben enviar como problemas en GitHub.
• Los errores en la implementación de Chromium se deben informar en la Herramienta de seguimiento de errores de Chrome, si aún no es uno de los problemas conocidos.
• Los comentarios generales sobre las Web Vitals se pueden compartir en web-vitals-feedback@googlegroups.com.

Si tienes dudas, no te preocupes demasiado. Preferimos recibir los 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 desarrolló esta API, se realizaron varios cambios, más que con las APIs estables. Puedes consultar el registro de cambios de las navegaciones suaves para obtener más detalles.

Conclusión

La función de navegaciones suaves es un enfoque interesante de 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 nos entusiasma el potencial de esta API.

Agradecimientos

Imagen en miniatura de Jordan Madrid en Unsplash

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