Experimentar con la medición de navegaciones suaves

Barry Pollard

Yoav Weiss

Desde su lanzamiento, la iniciativa de Métricas web esenciales buscó medir la experiencia real del usuario en 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 web esenciales se crearon como métricas centradas en el usuario, una evolución sobre las métricas técnicas existentes, como DOMContentLoaded o load, que mide los tiempos que, a menudo, no se relacionan con la forma en que los usuarios perciben el rendimiento de la página. Por lo tanto, la tecnología que se use para crear el sitio no debería afectar la puntuación que le proporcione el sitio en cuestión.

La realidad siempre es un poco más complicada de lo ideal, y la popular arquitectura de aplicación de una sola página nunca estuvo completamente respaldada por las 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, se mantiene la ilusión de una arquitectura de página web convencional modificando la URL e insertando URL anteriores en el historial del navegador para permitir que los botones para retroceder y avanzar funcionen como el usuario espera.

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

El equipo de Chrome ha estado considerando este desafío desde hace ya un tiempo y busca estandarizar una definición de lo que es una "navegación suave" y cómo se pueden medir las Métricas web esenciales al respecto, de una manera similar a como se miden los sitios web implementados en la arquitectura convencional de varias páginas (MPA). Aunque todavía se encuentra en las primeras etapas, el equipo está listo para permitir que los sitios experimenten lo que ya se implementó. Esto permitirá que los sitios proporcionen comentarios sobre el enfoque hasta ahora.

¿Qué es una navegación suave?

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

• La navegación se inicia mediante una acción del usuario.
• La navegación genera un cambio de URL visible para el usuario y un cambio en el historial.
• La navegación genera un cambio de DOM.

En el caso de algunos sitios, estas heurísticas pueden generar falsos positivos (que los usuarios realmente no considerarían que ocurrió una "navegación") o falsos negativos (cuando el usuario considera que se produjo una "navegación" a pesar de no cumplir con estos criterios). Agradecemos los comentarios sobre la heurística sobre el repositorio de especificaciones de navegación en segundo plano.

¿Cómo implementa Chrome las navegaciones suaves?

Una vez que se habilite la heurística de navegación simple (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 en segundo plano.
• La API de rendimiento proporcionará acceso a una entrada de tiempo soft-navigation, como lo emite el evento PerformanceTiming soft-navigation.
• Se restablecerán las métricas First Paint (FP), First Contentful Paint (FCP) y Largest Contentful Paint (LCP) y se volverán a emitir en los próximos casos adecuados. (Nota: Aún no se implementaron FP y FCP).
• Se agregará un atributo navigationId a cada tiempo de rendimiento (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event y layout-shift) correspondientes a la entrada de navegación con la que estaba relacionado el evento, lo que permitirá calcular el Cambio de diseño acumulado (CLS) y la Interacción con Next Paint (INP).

Estos cambios permitirán que las Métricas web esenciales (y algunas de las métricas de diagnóstico asociadas) se midan por navegación de página, aunque se deben considerar algunos matices.

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

A continuación, se muestran algunos de los cambios que los propietarios de los sitios deben tener en cuenta después de habilitar esta función:

• Los eventos de FP, FCP y LCP adicionales se pueden reemitir para las navegaciones suaves. El Informe sobre la experiencia del usuario en Chrome (CrUX) ignorará estos valores adicionales, pero esto puede afectar cualquier supervisión de medición del usuario real (RUM) en tu sitio. Consulta con tu proveedor de RUM si tienes dudas sobre si esto afectará esas mediciones. Consulta la sección sobre cómo medir las Métricas web esenciales para las navegaciones en segundo plano.
• Es posible que el nuevo atributo navigationID (y opcional) de tus entradas de rendimiento deba considerarse en el código de la aplicación mediante estas entradas.
• Solo los navegadores basados en Chromium serán compatibles con este nuevo modo. Si bien muchas de las métricas más recientes solo están disponibles en los navegadores basados en Chromium, algunas (FCP y LCP) están disponibles en otros navegadores, y es posible que no todos los usuarios hayan actualizado los navegadores basados en Chromium a la versión más reciente. Por lo tanto, ten en cuenta que es posible que algunos usuarios no informen métricas de navegación en segundo plano.
• Como se trata de una nueva función experimental que no está habilitada de forma predeterminada, los sitios deben probarla para asegurarse de que no haya otros efectos secundarios no deseados.

Para obtener más información sobre cómo medir las métricas de las navegaciones en segundo plano, consulta la sección Cómo medir las Métricas web esenciales por navegación de software.

¿Cómo habilito las navegaciones automáticas en Chrome?

Las navegaciones suaves no están habilitadas de forma predeterminada en Chrome, pero están disponibles para la experimentación en Chrome 110 si se habilita explícitamente esta función.

Para los desarrolladores, esto se puede habilitar activando la marca Funciones de la plataforma web experimental en chrome://flags/#enable-experimental-web-platform-features o usando el argumento de línea de comandos --enable-experimental-web-platform-features cuando se inicien Chrome.

En el caso de un sitio web que quiera habilitar esta función para que todos los visitantes vean el impacto, hay una prueba de origen que se está ejecutando desde Chrome 117. Para habilitarla, regístrate en la prueba y agrega un metaelemento con el token de prueba de origen en el encabezado HTML o HTTP. Consulta la publicación Comienza a usar las pruebas de origen para obtener más información.

Los propietarios de los sitios pueden optar por incluir la prueba de origen en sus páginas para todos los usuarios o solo para un subconjunto de usuarios. Ten en cuenta la sección de implicaciones anterior sobre cómo esto cambia la forma en que se pueden informar tus métricas, especialmente si se habilita esta prueba de origen para una gran proporción de tus usuarios. Ten en cuenta que CrUX continuará informando las métricas de la manera existente, independientemente de este parámetro de configuración de navegación en segundo plano, por lo que esas implicaciones no lo afectan. También se debe tener en cuenta que las pruebas de origen también se limitan a habilitar funciones experimentales en un máximo del 0.5% de todas las cargas de páginas de Chrome durante un período promedio de 14 días, pero esto solo debería ser un problema para los sitios muy grandes.

¿Cómo puedo medir las navegaciones suaves?

Una vez que se habilite el experimento de navegaciones en segundo plano, las métricas se informarán con la API de PerformanceObserver como de costumbre. Sin embargo, hay algunas consideraciones adicionales que se deben tener en cuenta para estas métricas.

Cómo informar navegaciones en segundo plano

Puedes usar un PerformanceObserver para observar las navegaciones de baja calidad. A continuación, se muestra un ejemplo de fragmento de código que registra entradas de navegación de software en la consola, incluidas las navegaciones de software 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 toda la página de la navegación anterior.

Informa las métricas con la URL adecuada.

Dado que las navegaciones suaves solo se pueden ver después de que ocurren, algunas métricas deberán finalizarse en este evento y, luego, informarse para la URL anterior, ya que la URL actual ahora reflejará la URL actualizada para la nueva página.

Se puede usar el atributo navigationId del PerformanceEntry adecuado para vincular el evento con la URL correcta. Puedes buscarlo con la API de PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Este pageUrl se debe usar para informar las métricas con la URL correcta, en lugar de la URL actual que posiblemente se usó en el pasado.

Cómo obtener el startTime de las navegaciones suaves

La hora de inicio de la navegación se puede obtener de la siguiente manera:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

El startTime es el tiempo de la interacción inicial (por ejemplo, un clic en un botón) que inició la navegación táctil.

Todos los tiempos de rendimiento, incluidos los de las navegaciones suaves, se informan como una hora a partir del tiempo de navegación "difícil" inicial de la página. Por lo tanto, el tiempo de inicio de la navegación en segundo plano es necesario para establecer el modelo de referencia de los tiempos de la métrica de carga de esta navegación (por ejemplo, LCP), en relación con este tiempo.

Mide las Métricas web esenciales por navegación en segundo plano

Para incluir entradas de métricas de navegación suave, debes incluir includeSoftNavigationObservations: true en la llamada a observe de tu observador de rendimiento.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Se necesita la marca includeSoftNavigationObservations adicional en el método observe, además de habilitar la función de navegación táctil en Chrome. Esta habilitación explícita a nivel del observador de rendimiento tiene como objetivo garantizar que los observadores de rendimiento existentes no se sorprendan con estas entradas adicionales, ya que se deben tener en cuenta algunas consideraciones adicionales cuando se intenta medir las Métricas web esenciales para las navegaciones de software.

Aun así, se devolverán los tiempos en relación con la hora de inicio de la navegación "difícil" original. Por lo tanto, para calcular el LCP de una navegación en segundo plano, por ejemplo, deberás tomar la sincronización del LCP y restar la hora de inicio correspondiente según se detallado anteriormente para obtener un tiempo relativo a la navegación en segundo plano. Por ejemplo, para LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Tradicionalmente, algunas métricas se miden durante la vigencia 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 salgas de la página. Por lo tanto, es posible que cada "navegación" (incluida la original) deba finalizar las métricas de la página anterior a medida que se produce cada navegación suave nueva. Esto significa que las métricas de navegación iniciales "difíciles" podrían finalizarse antes que de costumbre.

Del mismo modo, al comenzar a medir las métricas para la nueva navegación de software 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 establecidos para las “páginas” anteriores.

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

FP, FCP y LCP para navegaciones suaves solo medirán pinturas nuevas. Esto puede generar un LCP diferente, por ejemplo, de una carga en frío de esa navegación suave a una carga suave.

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

Como muestra este ejemplo, el elemento LCP para la navegación táctil se puede informar de manera diferente según cómo se cargue la página; del mismo modo, cuando se carga una página con un vínculo de anclaje más abajo en ella, se puede generar un elemento LCP diferente.

¿Cómo se mide el TTFB?

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

Para una navegación suave, esta es una pregunta más complicada. ¿Debemos medir la primera solicitud que se hace para la página nueva? ¿Qué sucede si todo el contenido ya existe en la app y no hay solicitudes adicionales? ¿Qué pasa si esa solicitud se hace de antemano con una carga previa? ¿Qué pasa si una solicitud no relacionada con la navegación de software desde la perspectiva del usuario (por ejemplo, es una solicitud de análisis)?

Un método más simple es informar el TTFB de 0 para las navegaciones en segundo plano, de manera similar a lo que recomendamos para los restablecimientos de la caché atrás/adelante. Este es el método que la biblioteca web-vitals usa actualmente para las navegaciones en segundo plano.

En el futuro, podríamos admitir formas más precisas de saber qué solicitud es la "solicitud de navegación" de la navegación táctil y podremos tener mediciones de TTFB más precisas. Pero eso no forma parte del experimento actual.

¿Cómo se miden los valores antiguos y nuevos?

Durante este experimento, te recomendamos que sigas midiendo tus Métricas web esenciales de la manera actual, según las navegaciones de páginas "difíciles" para que coincidan con lo que CrUX medirá y mostrará como el conjunto de datos oficial de la iniciativa de Métricas web esenciales.

Además de estas, se deben medir las navegaciones suaves para que puedas ver cómo se podrían medir en el futuro y para darte la oportunidad de proporcionar comentarios al equipo de Chrome sobre cómo funciona esta implementación en la práctica. Esto los ayudará a ti y al equipo de Chrome a definir la API en el futuro.

Para medir ambos, debes estar al tanto de los nuevos eventos que se pueden emitir en el modo de navegación en segundo plano (por ejemplo, varios eventos de FCP y LCP adicionales) y manejarlos de forma adecuada finalizando estas métricas en el momento apropiado, a la vez que ignoras los eventos futuros que solo se aplican a las navegaciones de software.

Usa la biblioteca de web-vitals para medir las Métricas web esenciales de las navegaciones en segundo plano

La forma más fácil de tener en cuenta todos los matices es usar la biblioteca de JavaScript web-vitals, que tiene compatibilidad experimental con las navegaciones en segundo plano en un soft-navs branch independiente (que también está disponible en npm y unpkg). Se puede medir de la siguiente manera (reemplazando 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';

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});

Asegúrate de que las métricas se informen con la URL correcta como se indicó anteriormente.

La biblioteca web-vitals informa las siguientes métricas sobre las navegaciones en segundo plano:

¿Estos cambios formarán parte de las mediciones de las Métricas web esenciales?

Este experimento de navegación suave es exactamente eso: un experimento. Queremos evaluar las heurísticas y ver si reflejan de forma más precisa la experiencia del usuario antes de decidir si se integrará en la iniciativa de Métricas web esenciales. Estamos muy entusiasmados con la posibilidad de este experimento, pero no podemos garantizar que reemplazará las mediciones actuales ni cuándo lo hará.

Valoramos los comentarios de los desarrolladores web sobre el experimento, las heurísticas utilizadas y si consideras que reflejan 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 en la implementación de Chrome deben informarse en la Herramienta de seguimiento de errores de Chrome.

¿Cómo se informarán las navegaciones de software en CrUX?

También se debe determinar cómo se informarán exactamente las navegaciones de baja calidad en CrUX, si este experimento tiene éxito. No es necesariamente un hecho que se traten de la misma manera que las navegaciones "difíciles" actuales.

En algunas páginas web, las navegaciones por software son casi idénticas a las cargas de páginas completas en lo que respecta al usuario, y el uso de la tecnología de aplicación de una sola página es solo un detalle de implementación. En otros, es posible que sean más parecidos a una carga parcial de contenido adicional.

Por lo tanto, es posible que decidamos informar estas navegaciones de software por separado en CrUX o, quizás, ponderarlas cuando calculemos las Métricas web esenciales de una página o un grupo de páginas determinados. También es posible que podamos excluir por completo la navegación suave de carga parcial, a medida que evoluciona la heurística.

En la actualidad, el equipo se está concentrando en la implementación técnica y heurística, lo que nos permitirá evaluar el éxito de este experimento, por lo que no se tomó ninguna decisión sobre estos aspectos.

Comentarios

Esperamos recibir comentarios sobre este experimento en los siguientes lugares:

• La estandarización y la heurística de las navegaciones suaves.
• Problemas de implementación de Chrome de esas heurísticas
• Comentarios generales sobre métricas web en web-vitals-feedback@googlegrouops.com.

Registro de cambios

Como esta API está en fase experimental, se le aplican varios cambios, más que con las APIs estables. Para obtener más información, puedes ver el Registro de cambios de la heurística de navegación suave.

Conclusión

El experimento de navegaciones suaves es un enfoque interesante sobre cómo la iniciativa de Métricas web esenciales podría evolucionar para medir un patrón común en la Web moderna que actualmente falta en nuestras métricas. Si bien este experimento se encuentra en sus primeras etapas, y aún queda mucho por hacer, hacer que el progreso esté disponible hasta ahora para que la comunidad web más amplia experimente con él es un paso importante. La recopilación de los comentarios de este experimento es otra parte fundamental del experimento, por lo que recomendamos a aquellos interesados en este desarrollo que aprovechen esta oportunidad para ayudar a diseñar la API y asegurarse de que sea representativa de lo que esperamos poder medir con esto.

Agradecimientos

Imagen en miniatura de Jordan Madrid en Unsplash