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 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 tu herramienta de estadísticas admite esto, deberías poder medir cada una de las métricas de Core Web Vitals 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).
Consulta la documentación de tu herramienta de estadísticas para obtener las instrucciones sobre los pasos 1 y 3. 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 ninguna. 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 se encuentre en redes o dispositivos extremadamente lentos y se acerque al rango máximo de valores, pero no se tengan en cuenta suficientes sesiones de usuario como para generar un impacto en el promedio de una manera que sugiera que hay un problema.
Siempre que sea posible, confía en los percentiles en lugar de los 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 para cada una de las métricas de las Métricas web esenciales y los hayas enviado a tu servicio de estadísticas mediante 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 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 estadísticas no te proporciona un nivel de detalle de 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 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 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 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 un problema, 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 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 se puede cerrar la app del navegador 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 cuando 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 que 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. De lo contrario, puedes crear una dimensión personalizada y configurarla en tu 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 tu métrica se pueda asociar a un grupo experimental específico 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í, las conclusiones que intentes sacar sobre cómo tu rendimiento afecta a tu empresa no serán confiables, 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 código de estadísticas RUM en tu sitio de producción:
Aplaza tus estadísticas
El código de Analytics siempre debe cargarse de forma asíncrona y sin bloqueo y, en general, debe cargarse en último lugar. Si cargas tu código de estadísticas de forma bloqueada, el LCP puede verse afectado.
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 Analytics a menudo se ejecuta en respuesta a las entradas del usuario. Sin embargo, si tu código de estadísticas realiza muchas mediciones del DOM o usa otras APIs que hacen un uso intensivo de los procesadores, el código de estadísticas en sí puede causar una respuesta deficiente a 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 bloquea tareas críticas para el 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 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 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.