Cómo medir las Métricas web con tu herramienta de estadísticas actual
Tener la capacidad de medir el rendimiento real de tus páginas y generar informes sobre él es fundamental para diagnosticar y mejorar el rendimiento a lo largo del tiempo. Sin los datos de campo, es imposible saber con certeza si los cambios que haces en el sitio realmente están logrando los resultados deseados.
Muchos proveedores de estadísticas populares de monitoreo de usuario real (RUM) ya admiten las Métricas web esenciales en sus herramientas (así como muchas otras Métricas web). Si actualmente usas una de estas herramientas de análisis de RUM, estás en condiciones de evaluar con qué eficacia las páginas de tu sitio cumplen con los umbrales recomendados de Métricas web esenciales y evitar regresiones en el futuro.
Si bien te recomendamos que uses una herramienta de estadísticas que admita las métricas web esenciales, si la herramienta de estadísticas que usas actualmente no las admite, no es necesario que la cambies. Casi todas las herramientas de estadísticas ofrecen una forma de definir y medir métricas personalizadas o eventos, lo que significa que es probable que puedas usar tu proveedor de estadísticas actual para medir las métricas de Métricas web esenciales 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.
Usa métricas o eventos personalizados
Como se mencionó anteriormente, la mayoría de las herramientas de análisis te permiten medir datos personalizados. Si tu herramienta de estadísticas lo admite, deberías poder medir cada una de las métricas de Métricas web esenciales con este mecanismo.
La medición de métricas o eventos personalizados en una herramienta de estadísticas suele ser un proceso de tres pasos:
- Define o registra la métrica personalizada en el administrador de tu herramienta (si es necesario). (Nota: No todos los proveedores de estadísticas requieren que se definan métricas personalizadas 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 estadísticas y asegúrate de que el nombre o el ID coincidan con lo que se definió en el paso 1 (de nuevo, si es necesario).
Para los pasos 1 y 3, puedes consultar la documentación de tu herramienta de estadísticas a fin de obtener instrucciones. En el paso 2, puedes usar la biblioteca de JavaScript web-vitals para calcular el valor de cada una de las 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 el código y enviarlas a un servicio de estadísticas.
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 a través del cálculo de un promedio. Los promedios parecen convenientes a primera vista, ya que son un resumen ordenado de una gran cantidad de datos, pero deberías resistir la necesidad de depender de ellos para interpretar el rendimiento de la página.
Los promedios son problemáticos porque no representan ninguna sesión de un solo usuario. Los valores atípicos en cualquier rango de la distribución pueden sesgar el promedio de maneras que son engañosas.
Por ejemplo, es posible que un pequeño grupo de usuarios esté en redes extremadamente lentas o en dispositivos que se acercan al rango máximo de valores, pero que no tienen en cuenta suficientes sesiones de usuario para afectar el promedio de una manera que sugiera que hay un problema.
Cuando sea posible, usa percentiles en lugar de promedios. Los percentiles de una distribución para una métrica de rendimiento determinada describen mejor la gama completa de experiencias del usuario para tu sitio web. Esto te permite enfocarte en subconjuntos de experiencias reales, lo que te brindará más estadísticas que un valor único.
Asegúrate de poder crear informes sobre una distribución
Una vez que calcules los valores de cada una de las métricas web esenciales y los envíes a tu servicio de estadísticas con una métrica o un evento personalizados, el siguiente paso es crear un informe o panel en el que se muestren los valores que se recopilaron.
Para asegurarte de que cumples con los umbrales recomendados de Métricas web esenciales, necesitarás que el informe muestre el valor de cada métrica en el percentil 75.
Si tu herramienta de estadísticas no ofrece informes de cuantil como una función integrada, es probable que aún puedas obtener estos datos de forma manual si generas un informe que enumere todos los valores de las métricas en orden ascendente. Una vez que se genere este informe, el resultado que será el 75% de la lista completa y ordenada de todos los valores de 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 te brinda un nivel de detalle de los informes a nivel de la métrica de forma predeterminada, es probable que puedas lograr el mismo resultado si tu herramienta de estadísticas admite dimensiones personalizadas. Si configuras un valor único y de dimensión personalizada para cada instancia de métrica individual de la que realices un seguimiento, deberías poder generar un informe desglosado por instancias de métricas individuales, si incluyes la dimensión personalizada en la configuración del informe. Como cada instancia tendrá un valor de dimensión único, no se producirá ninguna agrupación.
El Informe de Métricas web es un ejemplo de esta técnica que usa Google Analytics. El código del informe es de código abierto, por lo que los desarrolladores pueden consultarlo como ejemplo de las técnicas que se describen en esta sección.
Envía tus datos en el momento adecuado
Algunas métricas de rendimiento se pueden calcular una vez que la página termina de cargarse, mientras que otras (como CLS) consideran toda la vida útil de la página y solo son definitivas una vez que la página comienza a descargarse.
Sin embargo, esto puede ser problemático, ya que los eventos beforeunload y unload no son confiables (especialmente en dispositivos móviles) y su uso no se recomienda (ya que pueden evitar que una página sea apta para la Memoria caché atrás/adelante).
Para las métricas que realizan un seguimiento de toda la vida útil de una página, es mejor enviar el valor actual de la métrica durante el evento visibilitychange, 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 las secuencias de comandos de esa página puedan volver a ejecutarse. Esto es especialmente cierto en los sistemas operativos para dispositivos móviles en los que la app del navegador se puede cerrar sin que se active ninguna devolución de llamada de página.
Ten en cuenta que los sistemas operativos para dispositivos móviles suelen activar el evento visibilitychange cuando cambian de pestaña, cambias de app o cierras la app del navegador.
También activan el evento visibilitychange cuando cierran una pestaña o navegas a una página nueva. Esto hace que el evento visibilitychange sea mucho más confiable que los eventos unload o beforeunload.
Supervisa el rendimiento en el tiempo.
Una vez que hayas actualizado tu implementación de estadísticas para hacer un seguimiento de las métricas web esenciales y generar informes sobre ellas, el siguiente paso es hacer un seguimiento de cómo los cambios en el sitio afectan el rendimiento a lo largo del tiempo.
Establece la versión de tus cambios
Un enfoque simple (y, en última instancia, poco confiable) para realizar un seguimiento de los cambios es implementar los cambios en la producción y, luego, suponer que todas las métricas recibidas después de la fecha de implementación corresponden al sitio nuevo y que todas las métricas recibidas antes de la fecha de implementación corresponden al sitio anterior. Sin embargo, esto puede verse afectado por cualquier factor (incluido el almacenamiento en caché en la capa HTTP, el service worker o la CDN)
Un enfoque mucho mejor es crear una versión única para cada cambio implementado y, luego, hacer un seguimiento de esa versión en tu herramienta de estadísticas. La mayoría de las herramientas de análisis admiten la configuración de una versión. De lo contrario, puedes crear una dimensión personalizada y establecerla como tu versión implementada.
Experimentar
Puedes llevar el control de versiones un paso más allá si realizas el seguimiento de varias versiones (o experimentos) al mismo tiempo.
Si tu herramienta de estadísticas te permite definir grupos experimentales, utiliza esa función. De lo contrario, puedes usar dimensiones personalizadas para asegurarte de que cada uno de los valores de tus métricas se pueda asociar con un grupo experimental en particular en tus informes.
Cuando implementas la experimentación en tus estadísticas, puedes lanzar un cambio experimental en un subconjunto de tus usuarios y comparar su rendimiento con el de los usuarios en el grupo de control. Una vez que estés seguro de que un cambio realmente mejora el rendimiento, puedes implementarlo a todos los usuarios.
Asegúrate de que la medición no afecte el rendimiento
Cuando midas el rendimiento de usuarios reales, es absolutamente fundamental que cualquier código de medición de rendimiento que ejecutes no tenga un impacto negativo en el rendimiento de tu página. Si es así, cualquier conclusión que intentes sacar sobre cómo el rendimiento afecta a tu empresa no será confiable, ya que nunca sabrás si la presencia del código de estadísticas en sí es la que tiene el mayor impacto negativo.
Cuando implementes el código de estadísticas de RUM en tu sitio de producción, sigue siempre estos principios:
Aplaza tus estadísticas
El código de Analytics siempre debe cargarse de manera asíncrona y sin bloqueo y, por lo general, debe cargarse la última vez. Si cargas tu código de Analytics de manera bloqueada, es posible que el LCP se vea afectado de forma negativa.
Todas las APIs que se usan para medir las métricas web esenciales se diseñaron específicamente para admitir la carga asíncrona y diferida de secuencias de comandos (a través de la marca buffered), por lo que no es necesario apresurarse a cargar tus secuencias de comandos con anticipación.
En caso de que midas una métrica que no se pueda calcular más adelante en el cronograma de carga de página, debes intercalar solo el código que necesita ejecutarse con anticipación en el <head> de tu documento (de manera que no sea una solicitud de bloqueo de la renderización) y aplazar el resto. No cargues todas tus estadísticas con anticipación solo porque lo requiera una sola métrica.
No crear tareas largas
A menudo, el código de Analytics se ejecuta en respuesta a las entradas del usuario. Sin embargo, si tu código de Analytics realiza muchas mediciones del DOM o usa otras APIs que requieren un uso intensivo de los procesadores, el código de Analytics en sí puede generar una capacidad de respuesta deficiente para las entradas. Además, si el archivo JavaScript que contiene el código de estadísticas es grande, ejecutarlo puede bloquear el subproceso principal y afectar negativamente la Interaction to Next Paint (INP) de una página.
Usa APIs que no bloqueen
Las APIs como sendBeacon() y requestIdleCallback() están diseñadas específicamente para ejecutar tareas no críticas de una manera que no bloquee las tareas críticas para el usuario.
Estas APIs son excelentes herramientas para usar en una biblioteca de análisis 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 de estadísticas pasivas se debe ejecutar durante los períodos de inactividad.
No haga un seguimiento de 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 debas registrarlos y enviarlos a tus servidores de estadísticas.
Por ejemplo, la API de Resource Timing proporciona datos de tiempo detallados para cada recurso cargado en tu 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 solo realices un seguimiento de los datos porque están allí; asegúrate de que los datos se usarán antes de consumir recursos para realizar un seguimiento de ellos.