Cómo medir las Métricas web con tu herramienta de estadísticas actual
Tener la capacidad de medir y generar informes sobre el rendimiento real de tus páginas es fundamental para diagnosticar y mejorar el rendimiento con el tiempo. Sin los datos de campo, es imposible saber con certeza si los cambios que realizas en tu sitio realmente logran los resultados deseados.
Muchos proveedores de estadísticas populares de supervisión de usuarios reales (RUM) ya admiten las métricas de Métricas web esenciales en sus herramientas (así como muchos otros métricas web). Si 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 los umbrales recomendados de las métricas web esenciales y evitar regresiones en el futuro.
Si bien recomendamos usar una herramienta de estadísticas que admita las métricas de las métricas principales de la Web, si la herramienta de estadísticas que usas actualmente no las admite, no es necesario que 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 las métricas principales de la Web 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 de las Métricas web esenciales (o cualquier métrica personalizada) con una herramienta de estadísticas propia 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 análisis admite esta función, deberías poder medir cada una de las métricas de las Métricas web esenciales con este mecanismo.
La medición de métricas o eventos personalizados en una herramienta de análisis 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 las métricas personalizadas con anticipación).
- Calcula el valor de la métrica en tu código de JavaScript del 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 (otra vez, si es necesario).
Para los pasos 1 y 3, puedes consultar la documentación de tu herramienta de estadísticas para 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 de las métricas web esenciales.
En el siguiente ejemplo de código, se muestra lo fácil que puede ser hacer 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);
Evita los promedios
Es tentador sumar un rango de valores para una métrica de rendimiento mediante el 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 debes resistir la tentación de depender de ellos para interpretar el rendimiento de la página.
Los promedios son problemáticos porque no representan la sesión de ningún usuario. Los valores atípicos en cualquier rango de la distribución pueden sesgar el promedio de manera engañosa.
Por ejemplo, es posible que un pequeño grupo de usuarios tenga redes o dispositivos extremadamente lentos que estén cerca del rango máximo de valores, pero no representen suficientes sesiones de usuario para afectar el promedio de una manera que sugiera que hay un problema.
Siempre que 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 de tu sitio web. Esto te permite enfocarte en subconjuntos de experiencias reales, lo que te brindará más estadísticas que un solo valor.
Asegúrate de poder denunciar una distribución
Una vez que hayas calculado los valores de cada una de las métricas de métricas web esenciales y los hayas enviado a tu servicio de estadísticas con una métrica o un evento personalizados, el siguiente paso es crear un informe o panel que muestre los valores recopilados.
Para asegurarte de cumplir con los umbrales recomendados de las Métricas web esenciales, tu informe deberá mostrar el valor de cada métrica en el percentil 75.
Si tu herramienta de análisis no ofrece informes de cuantiles como una función integrada, es probable que aún puedas obtener estos datos de forma manual si generas un informe que enumere cada valor de métrica ordenado de forma ascendente. Una vez que se genere este informe, el resultado que represente el 75% de la lista completa y ordenada de todos los valores de ese informe será el percentil 75 para esa métrica, y esto ocurrirá sin importar cómo segmentes tus datos (por tipo de dispositivo, tipo de conexión, país, etcétera).
Si tu herramienta de análisis no te brinda la granularidad de los informes a nivel de las métricas de forma predeterminada, es probable que puedas obtener el mismo resultado si tu herramienta de análisis admite dimensiones personalizadas. Si configuras un valor de dimensión personalizada único para cada instancia de métrica individual de la que realizas un seguimiento, deberías poder generar un informe desglosado por instancias de métrica individuales 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 realizará ninguna agrupación.
El informe 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 usarlo 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 el CLS) consideran todo el ciclo de vida 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 (en especial, en dispositivos móviles) y su uso no se recomienda (ya que pueden impedir que una página sea apta para la Memoria caché atrás/adelante).
Para las métricas que hacen un seguimiento de toda la vida útil de una página, lo mejor es enviar el valor actual de la métrica durante el evento visibilitychange
, cada vez 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 ninguna secuencia de comandos de esa página pueda 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 activen devoluciones de llamada de página.
Ten en cuenta que, por lo general, los sistemas operativos para dispositivos móviles activan el evento visibilitychange
cuando se cambia de pestaña, de app o se cierra la app del navegador.
También activan el evento visibilitychange
cuando se cierra una pestaña o se navega 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 de las Métricas web esenciales y generar informes sobre ellas, el siguiente paso es hacer un seguimiento de cómo los cambios en tu sitio afectan el rendimiento a lo largo del tiempo.
Cómo crear una versión de tus cambios
Un enfoque ingenuo (y, en última instancia, poco confiable) para hacer un seguimiento de los cambios es implementarlos en producción y, luego, suponer que todas las métricas recibidas después de la fecha de implementación corresponden al sitio nuevo y todas las métricas recibidas antes de la fecha de implementación corresponden al sitio anterior. Sin embargo, cualquier cantidad de factores (incluido el almacenamiento en caché en la capa HTTP, el trabajador de servicio o la CDN) puede impedir que esto funcione.
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 estadísticas admiten la configuración de una versión. Si la tuya no lo hace, puedes crear una dimensión personalizada y configurarla en la versión implementada.
Experimentar
Puedes llevar el control de versiones un paso más allá haciendo un seguimiento de varias versiones (o experimentos) al mismo tiempo.
Si tu herramienta de estadísticas te permite definir grupos de experimentos, usa 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.
Con la experimentación implementada en tus estadísticas, puedes lanzar un cambio experimental a un subconjunto de tus usuarios y comparar el rendimiento de ese cambio con el rendimiento de los usuarios del grupo de control. Una vez que tengas la seguridad de que un cambio realmente mejora el rendimiento, puedes lanzarlo para todos los usuarios.
Asegúrate de que la medición no afecte el rendimiento
Cuando se mide el rendimiento en usuarios reales, es fundamental que el código de medición de rendimiento que se ejecuta no afecte negativamente el rendimiento de tu página. Si es así, cualquier conclusión que intentes sacar sobre cómo tu 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.
Siempre sigue estos principios cuando implementes el código de estadísticas de RUM en tu sitio de producción:
Aplaza tus estadísticas
El código de Analytics siempre debe cargarse de forma asíncrona y no bloqueante, y, por lo general, debe cargarse de último. Si cargas tu código de estadísticas de una manera que bloquee el contenido, puede afectar negativamente el LCP.
Todas las APIs que se usan para medir las métricas de las métricas web esenciales se diseñaron específicamente para admitir la carga de secuencias de comandos asíncronas y diferidas (a través de la marca buffered
), por lo que no es necesario apresurarse para que se carguen 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 la página, debes intercalar solo el código que se debe ejecutar antes en el <head>
de tu documento (para que no sea una solicitud de bloqueo de renderización) y aplazar el resto. No cargues todas tus estadísticas con anticipación solo porque una sola métrica lo requiera.
No crees tareas largas
El código de estadísticas suele ejecutarse en respuesta a las entradas del usuario, pero si realiza muchas mediciones de DOM o usa otras APIs que requieren mucho procesamiento, el código de estadísticas puede provocar una baja capacidad de respuesta de las entradas. Además, si el archivo JavaScript que contiene tu código de estadísticas es grande, ejecutarlo puede bloquear el subproceso principal y afectar negativamente la interacción con la siguiente pintura (INP) de una página.
Usa APIs no bloqueantes
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 del usuario.
Estas APIs son excelentes herramientas para usar en una biblioteca de estadísticas de RUM.
En general, todos los píxeles contadores de estadísticas deben enviarse con la API de sendBeacon()
(si está disponible) y todo el código de medición de estadísticas pasivas debe ejecutarse durante los períodos inactivos.
No realices un seguimiento de más de lo que necesitas
El navegador expone muchos 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 Resource Timing API 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 hagas un seguimiento de los datos porque están allí, asegúrate de que se usarán antes de consumir recursos para hacer un seguimiento de ellos.