Experimentar con la medición de navegaciones suaves

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

Desde su lanzamiento, la iniciativa Métricas web esenciales busca 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 se carga. 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 miden los 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 utilizada para crear el sitio no debería afectar la puntuación que proporciona el sitio con buen rendimiento.

La realidad es siempre un poco más complicada que lo ideal, y la popular arquitectura de aplicación de una sola página nunca fue completamente 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 utilizan las denominadas "navegaciones en segundo plano", donde 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 y enviando URL anteriores en el historial del navegador para permitir que los botones para ir hacia atrás y adelante funcionen como espera el usuario.

Muchos frameworks de JavaScript usan este modelo, pero cada uno de forma diferente. Debido a 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 encuentra la línea que debe trazarse entre una interacción en la página actual en comparación con considerarla como una página nueva?

El equipo de Chrome ha estado considerando este desafío durante un tiempo y está buscando estandarizar una definición de lo que es una "navegación en segundo plano" y cómo se pueden medir las Métricas web esenciales para esto, de manera similar a como se miden los sitios web implementados en la arquitectura convencional de varias páginas (MPA). Aunque aún se encuentra en las etapas iniciales, el equipo ahora está listo para hacer que lo que ya se implementó esté disponible de forma más amplia para que los sitios experimenten con él. Esto permitirá que los sitios proporcionen comentarios sobre el enfoque hasta ahora.

¿Qué es una navegación suave?

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

  • Una acción del usuario inicia la navegación.
  • La navegación genera un cambio visible en la URL para el usuario y un cambio en el historial.
  • La navegación produce un cambio de DOM.

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

¿Cómo implementa Chrome la navegación en software?

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

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 la navegación en Chrome?

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

  • Los eventos adicionales de FP, FCP y LCP se pueden reemitir para las navegaciones en software. El Informe sobre la experiencia del usuario en Chrome (CrUX) ignorará estos valores adicionales, pero esto podría afectar cualquier supervisión de la medición de usuarios reales (RUM) de tu sitio. Consulta con tu proveedor de RUM si tienes alguna duda sobre si esto afectará las mediciones. Consulta la sección sobre cómo medir las Métricas web esenciales para las navegaciones en software.
  • 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 el uso de 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 navegadores basados en Chromium, algunas (FCP, LCP) sí lo están en otros navegadores, y es posible que no todos se hayan actualizado a la versión más reciente de los navegadores basados en Chromium. Por lo tanto, ten en cuenta que es posible que algunos usuarios no informen las métricas de navegación en software.
  • 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.

Si deseas obtener más información para medir las métricas de las navegaciones en software, consulta la sección Cómo medir las Métricas web esenciales por navegación en software.

¿Cómo habilito la navegación en Chrome?

Las navegaciones en software no están habilitadas de forma predeterminada en Chrome, pero están disponibles para la experimentación cuando se habilita esta función de forma explícita.

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

¿Cómo puedo medir las navegaciones en línea?

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

Cómo informar navegaciones en software

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

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

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

Se puede usar el atributo navigationId del PerformanceEntry adecuado para vincular el evento a la URL correcta. Esto se puede buscar 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 debe usarse para informar las métricas según la URL correcta, en lugar de la URL actual que es posible que haya usado en el pasado.

Cómo obtener los startTime de las navegaciones en software

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 valor startTime es el tiempo de la interacción inicial (por ejemplo, un clic en un botón) que inició la navegación en software.

Todos los tiempos de rendimiento, incluidos los de las navegaciones en software, se informan como un tiempo a partir de la fase "difícil" inicial tiempo de navegación de la página. Por lo tanto, el tiempo de inicio de la navegación en software es necesario para definir los tiempos de referencia de los tiempos de la métrica de carga de la navegación suave (por ejemplo, LCP) en relación con este tiempo.

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

Para incluir entradas de métricas de navegación en software, debes incluir includeSoftNavigationObservations: true en la llamada 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 en software en Chrome. Esta habilitación explícita a nivel del observador de rendimiento es para garantizar que los observadores de rendimiento existentes no se sorprendan por estas entradas adicionales, ya que se deben tener en cuenta algunas consideraciones adicionales cuando se intentan medir las Métricas web esenciales para las navegaciones en software.

Los tiempos se devolverán con respecto a la versión “difícil” original. hora de inicio de la navegación. Por lo tanto, para calcular el LCP para una navegación en software, por ejemplo, deberás tomar el tiempo de LCP y restar el tiempo de inicio de navegación en software adecuado como se detalló anteriormente para obtener un tiempo relativo a la navegación en pantalla. 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 a lo largo del ciclo de vida de la página; por ejemplo, el LCP puede cambiar hasta que se produce una interacción. El CLS y el INP pueden actualizarse hasta que salgas de la página. Por lo tanto, cada "navegación" (incluida la navegación original) quizás deba finalizar las métricas de la página anterior a medida que ocurre cada nueva navegación de software. Esto significa que la etapa inicial “difícil” las métricas de navegación pueden finalizarse antes de lo habitual.

De manera similar, cuando comiences a medir las métricas para la nueva navegación en software de estas métricas de larga duración, deberás “restablecer” las métricas. o "reinicializado" y tratarse como métricas nuevas, sin memoria de los valores que se establecieron para las “páginas” anteriores.

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

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

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 en pantalla. En la carga inicial de la página, se marcará la imagen del banner como el elemento de LCP y se basará en el tiempo de LCP. Para las navegaciones en software posteriores, el texto que aparece debajo será el elemento más grande pintado después de la navegación en pantalla 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 en pantalla, la imagen del banner será una pintura nueva y, por lo tanto, será apta para considerarse como elemento de LCP.

Como se muestra en este ejemplo, el elemento LCP para la navegación en software se puede informar de manera diferente según cómo se carga 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.

¿Cómo se mide el TTFB?

El tiempo hasta el primer byte (TTFB) de una carga de página convencional representa el tiempo 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 de la nueva página? ¿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 se trata de una solicitud no relacionada con la navegación en software desde la perspectiva del usuario (por ejemplo, se trata de una solicitud de estadísticas)?

Un método más sencillo es informar un TTFB de 0 para las navegaciones en software, 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 en software.

En el futuro, es posible que admitamos formas más precisas de saber qué solicitud es la "solicitud de navegación" de la navegación en software y podrán tener mediciones más precisas del TTFB. Pero eso no forma parte del experimento actual.

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

Durante este experimento, se recomienda seguir midiendo las Métricas web esenciales de la manera actual, en función de criterios "estrictos" las navegaciones de páginas para que coincidan con lo que CrUX medirá y sobre lo que informará como el conjunto de datos oficial de la iniciativa de Métricas web esenciales.

Además de estas navegaciones en software, se deben medir las navegaciones en software para permitirte ver cómo se podrían medir en el futuro y darte la oportunidad de enviar 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 dar forma a la API en el futuro.

Para medir ambos, debes conocer los nuevos eventos que se emitan en el modo de navegación en software (por ejemplo, varios eventos de FCP y LCP adicionales) y manejarlos de forma adecuada. Para ello, finaliza estas métricas en el momento adecuado, a la vez que ignoras los eventos futuros que solo se aplican a las navegaciones de software.

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

La forma más fácil de tener en cuenta todos los matices es usar la biblioteca de JavaScript de web-vitals, que tiene compatibilidad experimental con navegaciones en software en un soft-navs branch separado (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';

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 en función de la URL correcta como se indicó anteriormente.

La biblioteca web-vitals informa las siguientes métricas para las navegaciones en software:

Métrica Detalles
TTFB Informado como 0.
FCP Solo se informa el primer FCP de la página.
LCP Es el tiempo del siguiente procesamiento de imagen con contenido más grande, en relación con el tiempo de inicio de la navegación suave. No se consideran las pinturas existentes de la navegación anterior. Por lo tanto, el LCP será >= 0. Como siempre, esto se informará cuando se realice una interacción o cuando la página pase a segundo plano, ya que solo entonces se podrá finalizar el LCP.
CLS La ventana de cambios más grande entre los tiempos de navegación. Como es habitual, esto ocurre cuando la página pasa a segundo plano, ya que solo entonces se puede finalizar el CLS. Se informa un valor 0 si no hay cambios.
INP El INP entre los tiempos de navegación. Como siempre, esto se informará cuando se realice una interacción o cuando la página pase a segundo plano, ya que solo entonces se podrá finalizar el INP. No se informa un valor 0 si no hay interacciones.

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

Este experimento de navegación en software es exactamente eso: un experimento. Queremos evaluar la heurística y ver si reflejan con mayor precisión la experiencia del usuario antes de tomar cualquier decisión sobre si se integrará o no en la iniciativa de Métricas web esenciales. Nos entusiasma la posibilidad de que se lleve a cabo este experimento, pero no podemos garantizarte cuándo reemplazará las mediciones actuales o cuándo.

Valoramos las capacidades de comentarios sobre el experimento, la heurística utilizada y si crees que refleja con mayor precisión la experiencia. El repositorio de GitHub de navegación suave es el mejor lugar para enviar esos comentarios, aunque los errores individuales con la implementación de Chrome deben informarse en la Herramienta de seguimiento de errores de Chrome.

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

También se debe determinar cómo se informarán exactamente las navegaciones en CrUX si este experimento tendrá éxito. No es necesariamente una realidad que recibirán el mismo tratamiento que las actuales "difíciles" de navegación.

En algunas páginas web, las navegaciones de 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 se parezcan más a una carga parcial de contenido adicional.

Por lo tanto, es posible que decidamos informar estas navegaciones en CrUX por separado o, tal vez, ponderarlas cuando calculemos las Métricas web esenciales de una página o un grupo de páginas determinados. A medida que evoluciona la heurística, es posible que también se pueda excluir por completo la navegación de carga parcial.

El equipo se está concentrando en la heurística y la implementación técnica, lo que nos permitirá evaluar el éxito de este experimento, por lo que no se ha tomado ninguna decisión al respecto.

Comentarios

Estamos buscando activamente comentarios sobre este experimento en los siguientes lugares:

Registro de cambios

Debido a que esta API es experimental, se le están produciendo varios cambios, más que con las APIs estables. Puedes consultar el Registro de cambios de la heurística de navegación en software para obtener más detalles.

Conclusión

El experimento de navegaciones suaves es un enfoque emocionante 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 falta en nuestras métricas. Si bien este experimento aún está en sus primeras etapas y aún queda mucho por hacer, poner el progreso a disposición de la comunidad web en general con el que pueda experimentar es un paso importante. Recopilar los comentarios de este experimento es otra parte crucial del experimento, por lo que recomendamos encarecidamente a aquellos interesados en este desarrollo que aprovechen esta oportunidad para ayudar a dar forma a la API y asegurarse de que sea representativa de lo que esperamos poder medir con esto.

Agradecimientos

Miniatura de Jordan Madrid en Unsplash