Cómo medir las Métricas web con tu herramienta de estadísticas actual
Tener la capacidad de medir el rendimiento en el mundo real y generar informes sobre él páginas es fundamental para diagnosticar y mejorar el rendimiento a lo largo del tiempo. Sin campo datos, Es imposible saber con seguridad si los cambios que realiza en su sitio están logrando los resultados deseados.
Muchos monitoreos de usuarios reales populares (RUM) de proveedores de estadísticas admiten las métricas de Métricas web esenciales (así como muchas otras Métricas web). Si estás actualmente usas una de estas herramientas de análisis de RUM, estás en condiciones de evaluar qué tan bien las páginas de tu sitio cumplen con las Métricas web esenciales recomendadas umbrales y evitar regresiones en el futuro.
Aunque recomendamos usar una herramienta de estadísticas compatible con las Métricas web esenciales métricas, si la herramienta analítica que estás utilizando actualmente no las admite, puedes no necesitan cambiar. Casi todas las herramientas de análisis ofrecen definir y medir los valores personalizados métricas o eventos, lo que significa que pueden usar tu proveedor actual de estadísticas para medir las Métricas web esenciales métricas y agregarlas a tus informes y paneles de estadísticas existentes.
En esta guía, se analizan las prácticas recomendadas para medir las métricas web esenciales (o cualquier métrica personalizada) con una herramienta de estadísticas interna o de terceros. También puede servir como guía para los proveedores de estadísticas que deseen agregar compatibilidad con las Métricas web esenciales a su servicio.
Cómo utilizar métricas o eventos personalizados
Como se mencionó anteriormente, la mayoría de las herramientas de análisis te permiten medir datos personalizados. Si el de Google Cloud es compatible con esto, deberías poder medir cada uno de los Métricas de Android vitals que usan este mecanismo
Medir métricas o eventos personalizados en una herramienta de estadísticas es, por lo general, un proceso de tres pasos:
- Definir o registro la métrica personalizada en el administrador de la herramienta (si es necesario). (Nota: No todas los proveedores de estadísticas requieren que las métricas personalizadas se definan con anticipación).
- Calcula el valor de la métrica en tu código JavaScript de frontend.
- Envía el valor de la métrica a tu backend de Analytics y asegúrate de que el nombre o el ID sean Coincida con lo que se definió en el paso 1 (nuevamente, si es necesario).
Consulta la documentación de los pasos 1 y 3 en la documentación instrucciones. Para el paso 2, puedes usar la web-vitals para y calcular el valor de cada una de las métricas de Métricas web esenciales.
En la siguiente muestra de código, se indica lo fácil que es realizar un seguimiento de estas métricas en código y enviarlas a un servicio de análisis.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Evitar promedios
Resulta tentador sumar un rango de valores para una métrica de rendimiento calculando un promedio. Los promedios parecen convenientes a primera vista, ya que son un un resumen ordenado de una gran cantidad de datos, pero deberías resistir la tentación de confiar para interpretar el rendimiento de la página.
Los promedios son problemáticos porque no representan la sesión de un solo usuario. Valores atípicos en cualquier rango de la distribución puede sesgar el promedio de formas engañosas.
Por ejemplo, es posible que un pequeño grupo de usuarios use redes o dispositivos extremadamente lentos. que se encuentran dentro del rango máximo de valores, pero que no cuentan con suficientes valores para influir en el promedio de una forma que sugiera que hay un problema.
Siempre que sea posible, confía en los percentiles en lugar de los promedios. Percentiles de un de rendimiento para una métrica de rendimiento determinada, describe mejor el rango completo de del usuario para tu sitio web. Esto te permite enfocarte en subconjuntos de experiencias reales, que le brindarán más información que un solo valor podría.
Asegúrate de informar una distribución
Cuando hayas calculado los valores de cada una de las métricas a tu servicio de análisis usando una métrica o un evento personalizados, el siguiente paso es para crear un informe o panel en el que se muestren los valores recopilados.
Para asegurarte de cumplir con las Core Web Vitals recomendadas umbrales, necesitarás el informe para mostrar el valor de cada métrica en el percentil 75.
Si su herramienta analítica no ofrece informes de cuantiles como una función integrada pero probablemente aún puedas obtener estos datos manualmente si generas un informe que enumere cada valor de métrica ordenado en orden ascendente. Una vez que se genera este informe, 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 de esa métrica, y este será el caso, sin importar cómo segmentes los datos (por tipo de dispositivo, tipo de conexión, país, etc.).
Si tu herramienta de análisis no ofrece un nivel de detalle de los informes a nivel de la métrica de forma predeterminada, probablemente logre el mismo resultado si su herramienta es compatible con los grupos personalizados dimensiones. Si estableces un un valor de dimensión personalizada único para cada instancia de métrica individual de la que realices un seguimiento Deberías poder generar un informe desglosado por métrica individual instancias, si incluyes la dimensión personalizada en la configuración del informe. Dado que cada instancia tendrá un valor de dimensión único, no se producirá ningún agrupamiento.
El Informe de Métricas web es un ejemplo de esta técnica que utiliza Google Analytics. El código del sea de código abierto, para que los desarrolladores puedan consultarlo como un ejemplo de las técnicas descritas en este sección.
Envía tus datos en el momento adecuado
Algunas métricas de rendimiento pueden calcularse una vez que termina de cargarse la página mientras que otros (como CLS) consideran la vida útil completa de la página, y solo final una vez que la página haya comenzado a descargarse.
Sin embargo, esto puede ser un problema, ya que tanto beforeunload como unload
los eventos no son confiables (especialmente en dispositivos móviles) y su uso no es
recomendado
(ya que pueden impedir que una página sea apta para la opción
Caché).
En el caso de las métricas que hacen un seguimiento de la duración total de una página, es mejor enviar
valor actual de la métrica es durante el evento visibilitychange, siempre que
el estado de visibilidad de la página cambia a hidden. Esto se debe a que, una vez que
el estado de visibilidad cambie a hidden; no hay garantía de que cualquier secuencia de comandos en
esa página podrá volver a ejecutarse. Esto es especialmente cierto en los dispositivos móviles
sistemas en los que la app de navegador se puede cerrar sin ninguna devolución de llamada de la página
se está despediendo.
Ten en cuenta que, por lo general, los sistemas operativos para dispositivos móviles activan visibilitychange.
cuando se cambia de pestaña, de aplicación o se cierra la aplicación del navegador.
También activan el evento visibilitychange cuando cierran una pestaña o navegan a
una nueva página. Esto hace que el evento visibilitychange sea mucho más confiable que el
Eventos unload o beforeunload.
Supervisa el rendimiento en el tiempo.
Una vez que hayas actualizado tu implementación de Analytics para hacer un seguimiento y generar informes las métricas de las Métricas web esenciales, el próximo paso es hacer un seguimiento de los cambios afectan el rendimiento con el paso del tiempo.
Cómo controlar la versión de tus cambios
Un enfoque simple (y, en última instancia, poco confiable) para hacer un seguimiento de los cambios es implementar cambia a producción y, luego, asume que todas las métricas recibidas después de las fechas de implementación corresponden al nuevo sitio y todas las métricas recibidas antes de de implementación del proyecto correspondan al sitio anterior. Sin embargo, hay varios factores (incluido el almacenamiento en caché en la capa HTTP, service worker o CDN) puede evitar que de trabajar.
Un enfoque mucho mejor es crear una versión única para cada cambio implementado y hacer un seguimiento de esa versión en tu herramienta de estadísticas. La mayoría de las herramientas de estadísticas son compatibles configurar una versión. De lo contrario, puede crear una dimensión personalizada y establecer esa dimensión a la versión implementada.
Experimentar
Puedes ir un paso más allá haciendo un seguimiento de múltiples versiones (o experimentos) al mismo tiempo.
Si tu herramienta de estadísticas te permite definir grupos experimentales, usa esa función. De lo contrario, puedes utilizar dimensiones personalizadas para garantizar que cada uno de los valores de tu métrica se pueden asociar a un grupo experimental en particular en tus informes.
Con la experimentación en marcha en tus analíticas, puedes lanzar realizar un cambio experimental en un subconjunto de usuarios y comparar el rendimiento de que cambian el rendimiento de los usuarios del grupo de control. Una vez que tengas confianza en que un cambio realmente mejora el rendimiento, puedes implementarlo para todos los usuarios.
Asegúrate de que la medición no afecte el rendimiento
Cuando se mide el rendimiento en usuarios reales, es absolutamente fundamental que cualquier el código de medición de rendimiento que ejecutas no tiene un impacto negativo el rendimiento de tu página. Si es así, cualquier conclusión que intentes sacar sobre cómo el rendimiento afecta a su empresa no será confiable, ya que nunca se sabe si la presencia del código de análisis en sí tiene el mayor impacto negativo.
Siempre sigue estos principios cuando implementes código RUM Analytics en tu sitio de producción:
Difiere las estadísticas
El código de Analytics siempre se debe cargar de forma asíncrona y sin bloqueo. por lo general, debe cargarse en último lugar. Si cargas tu código de análisis en un de manera negativa, puede afectar el LCP.
Todas las APIs utilizadas para medir
las métricas de Core Web Vitals
diseñados para admitir la carga asíncrona y diferida de secuencias de comandos (mediante el
buffered), por lo que
no es necesario apresurarse
para que los scripts se carguen con anticipación.
Si estás midiendo una métrica que no se puede calcular más adelante en el
cronograma de carga de la página, deberías intercalar solo el código que se debe ejecutar antes de lo previsto.
en el <head> de su documento (de modo que no sea un bloqueo de procesamiento
) y aplaza el resto. No cargues todos tus
Analytics de manera temprana
porque una métrica lo requiere.
No crees tareas largas
El código de Analytics suele ejecutarse en respuesta a las entradas del usuario, pero si tu código lleva a cabo muchas mediciones del DOM o usa otras APIs que requieren un uso intensivo del procesador. el código de análisis puede causar una respuesta deficiente a las entradas. Además, si El archivo JavaScript que contiene tu código de análisis es grande y lo ejecuta. Puede bloquear el subproceso principal y afectar negativamente la Interaction to Next Paint (INP) de una página.
Usa APIs sin bloqueo
APIs como
sendBeacon()
y
requestIdleCallback()
se diseñaron específicamente para ejecutar tareas no esenciales de una manera en la que
bloquear tareas críticas para el usuario.
Estas APIs son excelentes herramientas para usar en una biblioteca de análisis de RUM.
En general, todos los píxeles contadores de estadísticas se deben enviar con la API de sendBeacon()
(si está disponible), y todo el código de medición analítica pasivo se debe ejecutar durante
períodos de inactividad.
No hagas un seguimiento de más de lo que necesitas
El navegador expone muchos datos de rendimiento, pero el hecho de que los datos se no significa necesariamente que debas grabarlo y enviarlo a tu en servidores de Google Analytics.
Por ejemplo, la API de Resource Timing proporciona datos detallados de tiempos para cada recurso cargado en tu página. Sin embargo, es poco probable que todos esos datos sean necesariamente o útiles para tal fin. lo que mejora el rendimiento de carga de los recursos.
En resumen, no solo realice un seguimiento de los datos porque están allí, asegúrese de que los datos se utilizarán antes de consumir recursos mediante su seguimiento.