Saltar al contenido principal
Dev

Mejores prácticas para medir Web Vitals en el campo

Cómo medir Web Vitals con su herramienta de análisis actual.


Actualizado

Tener la capacidad de medir e informar sobre el rendimiento real de sus páginas es fundamental para diagnosticar y mejorar el rendimiento a lo largo del tiempo. Sin datos de campo, es imposible saber con certeza si los cambios que está realizando en su sitio realmente están logrando los resultados deseados.

Muchos populares Monitoreo de usuarios reales (RUM) Los proveedores de análisis ya admiten las métricas de Core Web Vitals en sus herramientas (así como muchas otras Web Vitals). Si actualmente está utilizando una de estas herramientas de análisis de RUM, está en excelente forma para evaluar qué tan bien las páginas de su sitio cumplen con los umbrales recomendados de Core Web Vitals y evitar regresiones en el futuro.

Si bien recomendamos utilizar una herramienta de análisis que admita las métricas de Core Web Vitals, si la herramienta de análisis que está utilizando actualmente no las admite, no es necesario que cambie. Casi todas las herramientas de análisis ofrecen una forma de definir y medir métricas personalizadas o
eventos, lo que significa que probablemente puede usar su proveedor de análisis actual para medir las métricas de Core Web Vitals y agregarlas a sus informes y paneles de análisis existentes.

Esta guía analiza las mejores prácticas para medir las métricas de Core Web Vitals (o cualquier métrica personalizada) con una herramienta de análisis interna o de terceros. También puede servir como una guía para los proveedores de análisis que deseen agregar soporte de Core Web Vitals a su servicio.

Utilice métricas o eventos personalizados

Como se mencionó anteriormente, la mayoría de las herramientas de análisis le permiten medir datos personalizados. Si su herramienta de análisis lo admite, debería poder medir cada una de las métricas de Core Web Vitals utilizando este mecanismo.

La medición de eventos o métricas personalizadas en una herramienta de análisis es generalmente un proceso de tres pasos:

  1. Definir o registrar
    la métrica personalizada en el administrador de su herramienta (si es necesario). (Nota: no todos los proveedores de análisis requieren que se definan métricas personalizadas con anticipación).
  2. Calcule el valor de la métrica en su código JavaScript frontend.
  3. Envíe el valor de la métrica a su backend de análisis, asegurándose de que el nombre o ID coincida con lo que se definió en el paso 1 (nuevamente, si es necesario).

Para los pasos 1 y 3, puede consultar la documentación de su herramienta de análisis para obtener instrucciones. Para el paso 2, puede utilizar el
web-vitals Biblioteca de JavaScript para calcular el valor de cada una de las métricas de Core Web Vitals.

El siguiente ejemplo de código muestra lo fácil que puede ser rastrear estas métricas en el código y enviarlas a un servicio de análisis.

import {getCLS, getFID, getLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}

getCLS(sendToAnalytics);
getFID(sendToAnalytics);
getLCP(sendToAnalytics);

Asegúrese de poder informar una distribución

Una vez que haya calculado los valores para cada una de las métricas de Core Web Vitals y los haya enviado a su servicio de análisis utilizando una métrica o un evento personalizado, el siguiente paso es crear un informe o panel que muestre los valores que se han recopilado.

Para asegurarse de que cumple con los umbrales recomendados de Core Web Vitals, necesitará que su informe muestre el valor de cada métrica en el percentil 75.

Si su herramienta de análisis no ofrece informes de cuantiles como una función incorporada, probablemente aún pueda obtener estos datos manualmente generando un informe que enumere todos los valores de métricas ordenados en orden ascendente. Una vez que se genera este informe, el resultado que es el 75% del camino a través de la lista completa y ordenada de todos los valores en ese informe será el percentil 75 para esa métrica, y este será el caso sin importar cómo segmente sus datos ( por tipo de dispositivo, tipo de conexión, país, etc.).

Si su herramienta de análisis no le brinda granularidad de informes a nivel de métricas de forma predeterminada, probablemente pueda lograr el mismo resultado si su herramienta de análisis admite dimensiones personalizadas. Al establecer un valor de dimensión personalizado único para cada instancia de métrica individual de la que realiza un seguimiento, debería poder generar un informe, desglosado por instancias de métrica individuales, si incluye la dimensión personalizada en la configuración del informe. Dado que cada instancia tendrá un valor de dimensión único, no se producirá ninguna agrupación.

Por ejemplo, el siguiente histograma se generó a partir de Google Analytics utilizando la técnica descrita anteriormente (dado que Google Analytics no admite informes de cuantiles en ninguno de sus informes estándar). Los datos se consultaron utilizando el
API de informes de análisis y se muestra mediante una biblioteca de visualización de datos de JavaScript:

lcp-histogram-3164921

Consejo: el web-vitals La biblioteca proporciona un ID para cada instancia de métrica informada, lo que facilita la creación de distribuciones en la mayoría de las herramientas de análisis. Ver el
Metric documentación de la interfaz para obtener más detalles.

Envíe sus datos en el momento adecuado

Algunas métricas de rendimiento se pueden calcular una vez que la página ha terminado de cargarse, mientras que otras (como CLS) consideran la vida útil completa de la página y solo son definitivas una vez que la página ha comenzado a descargarse.

Sin embargo, esto puede ser problemático, ya que tanto el beforeunload y unload
Los eventos no son confiables (especialmente en dispositivos móviles) y su uso es no recomendado
(ya que pueden evitar que una página sea elegible para la Caché hacia atrás).

Para las métricas que rastrean la vida útil completa de una página, es mejor enviar el valor actual de la métrica durante el visibilitychange evento, siempre que el estado de visibilidad de la página cambie a hidden. Esto se debe a que, una vez que el estado de visibilidad de la página cambia a hidden: No hay garantía de que ningún script de esa página pueda ejecutarse de nuevo. Esto es especialmente cierto en los sistemas operativos móviles donde la aplicación del navegador en sí se puede cerrar sin que se active ninguna devolución de llamada de página.

Tenga en cuenta que los sistemas operativos móviles generalmente activan visibilitychange
evento al cambiar de pestaña, cambiar de aplicación o cerrar la aplicación del navegador. También disparan el visibilitychange evento al cerrar una pestaña o navegar a una nueva página. Esto hace que el visibilitychange evento mucho más confiable que el
unload o beforeunload eventos.

Gotchas!

Debido a algunos errores del navegador, hay algunos casos en los que visibilitychange el evento no dispara. Si está creando su propia biblioteca de análisis, es importante estar al tanto de estos errores. Tenga en cuenta que el web-vitals
La biblioteca de JavaScript tiene en cuenta todos estos errores.

Supervisar el rendimiento a lo largo del tiempo

Una vez que haya actualizado su implementación de análisis para rastrear e informar sobre las métricas de Core Web Vitals, el siguiente paso es rastrear cómo los cambios en su sitio afectan el rendimiento a lo largo del tiempo.

Versión de sus cambios

Un enfoque ingenuo (y en última instancia poco confiable) para rastrear cambios es implementar cambios en la producción y luego asumir que todas las métricas recibidas después de la fecha de implementación corresponden al nuevo sitio y todas las métricas recibidas antes de la fecha de implementación corresponden al sitio anterior. Sin embargo, cualquier número de factores (incluido el almacenamiento en caché en la capa HTTP, trabajador de servicio o CDN) puede evitar que esto funcione.

Un enfoque mucho mejor es crear una versión única para cada cambio implementado y luego rastrear esa versión en su herramienta de análisis. La mayoría de las herramientas de análisis admiten la configuración de una versión. Si el suyo no lo hace, puede crear una dimensión personalizada y establecer esa dimensión en su versión implementada.

Ejecutar experimentos

Puede llevar el control de versiones un paso más allá al realizar un seguimiento de varias versiones (o experimentos) al mismo tiempo.

Si su herramienta de análisis le permite definir grupos de experimentos, use esa función. De lo contrario, puede usar dimensiones personalizadas para asegurarse de que cada uno de los valores de sus métricas se pueda asociar con un grupo de experimentos en particular en sus informes.

Con la experimentación en su lugar de análisis, puede implementar un cambio experimental en un subconjunto de sus usuarios y comparar el rendimiento de ese cambio con el rendimiento de los usuarios del grupo de control. Una vez que tenga la confianza de que un cambio realmente mejora el rendimiento, puede implementarlo para todos los usuarios.

Los grupos de experimentos siempre deben establecerse en el servidor. Evite utilizar cualquier herramienta de experimentación o prueba A / B que se ejecute en el cliente. Por lo general, estas herramientas bloquearán la representación hasta que se determine el grupo de experimentos de un usuario, lo que puede ser perjudicial para sus tiempos de LCP.

Asegúrese de que la medición no afecte el rendimiento

Al medir el rendimiento en usuarios reales, es absolutamente fundamental que cualquier código de medición de rendimiento que esté ejecutando no afecte negativamente el rendimiento de su página. Si es así, cualquier conclusión que intente sacar sobre cómo su desempeño afecta su negocio no será confiable, ya que nunca sabrá si la presencia del código analítico en sí mismo está teniendo el mayor impacto negativo.

Siga siempre estos principios al implementar el código de análisis de RUM en su sitio de producción:

Aplazar sus análisis

El código de análisis siempre debe cargarse de forma asincrónica y sin bloqueo y, por lo general, debe cargarse en último lugar. Si carga su código de análisis de forma bloqueante, puede afectar negativamente a LCP.

Todas las API utilizadas para medir las métricas de Core Web Vitals se diseñaron específicamente para admitir la carga de scripts diferida y asincrónica (a través del
buffered flag), por lo que no hay necesidad de apresurarse para cargar sus scripts antes de tiempo.

En el caso de que esté midiendo una métrica que no se pueda calcular más adelante en la línea de tiempo de carga de la página, debe incluir solamente el código que debe ejecutarse temprano en el <head> de su documento (por lo que no es una solicitud de bloqueo de procesamiento) y posponga el resto. No cargue todos sus análisis de forma anticipada solo porque una única métrica lo requiera.

No crees tareas largas

El código de análisis a menudo se ejecuta en respuesta a la entrada del usuario, pero si su código de análisis está realizando muchas mediciones DOM o utilizando otras API intensivas en el procesador, el código de análisis en sí puede causar una respuesta de entrada deficiente. Además, si el archivo JavaScript que contiene su código de análisis es grande, ejecutar ese archivo puede bloquear el hilo principal y afectar negativamente a FID.

Utilice API sin bloqueo

API como
sendBeacon()
y
requestIdleCallback()
están diseñados específicamente para ejecutar tareas no críticas de una manera que no bloquee las tareas críticas para el usuario.

Estas API son excelentes herramientas para usar en una biblioteca de análisis de RUM.

En general, todas las balizas analíticas deben enviarse utilizando el sendBeacon() API (si está disponible) y todo el código de medición de análisis pasivo deben ejecutarse durante los períodos de inactividad.

Para obtener orientación sobre cómo maximizar el uso del tiempo de inactividad, sin dejar de garantizar que el código se pueda ejecutar con urgencia cuando sea necesario (como cuando un usuario está descargando la página), consulte la
inactivo-hasta-urgente
patrón.

No rastree más de lo que necesita

El navegador expone una gran cantidad de datos de rendimiento, pero el hecho de que los datos estén disponibles no significa necesariamente que deba registrarlos y enviarlos a sus servidores de análisis.

Por ejemplo, el API de tiempo de recursos
proporciona datos de tiempo detallados para cada recurso cargado en su página. Sin embargo, es poco probable que todos esos datos sean necesarios o útiles para mejorar el rendimiento de la carga de recursos.

En resumen, no se limite a rastrear los datos porque están allí, asegúrese de que los datos se utilizarán antes de consumir recursos para rastrearlos.

R Marketing Digital