Los análisis que importan

Durante mucho tiempo he sido escéptico a la hora de citar porcentajes de uso global del navegador para justificar el uso de las funciones del navegador. No importa cuál sea el uso global de un navegador, aparte del material de un cóctel nerd. El uso que importa es el que utilizan los usuarios de su sitio , y eso puede ser muy diferente de un sitio a otro.

Esa idea de rastrear el uso real del concepto real de su sitio ha rondado por mi cabeza los últimos días. Y no se trata sólo de cosas como “No puedo usar CSS grid porque IE 11 todavía tiene un 1,42% de uso global” , se trata de medir métricas que son importantes para su sitio, sin importar cuáles sean.

Las métricas de rendimiento son importantes. Cuando realiza pruebas de rendimiento, gran parte de ellas son lo que llamaría pruebas sintéticas . Un navegador automatizado carga su sitio y rastrea lo que encuentra a medida que se carga, como el momento de una cosa, el tamaño de los activos, la cantidad de activos, etc. Información sintética como esta me viene a la mente cuando dedico toneladas de tiempo al rendimiento. ” Apuesto a que puedo deshacerme de esta solicitud adicional “, pienso. ” Apuesto a que puedo optimizar este activo un poco más “. Y las herramientas de rendimiento que utilizamos nos informan este tipo de datos fácilmente. ¿Qué tamaño tiene nuestro paquete JavaScript? ¿Cuál es nuestra “pintura con mayor contenido”? ¿Cuál es nuestra puntuación de rendimiento de Lighthouse? Todas las cosas que están relacionadas con el rendimiento, pero que no miden la experiencia real del usuario .

Déjalo reposar por un segundo.

Hay otros análisis que podemos recopilar en un sitio, como análisis de uso. Por ejemplo, podríamos colocar Google Analytics en un sitio y no hacer nada más que instalar el fragmento genérico. Esto nos dirá cosas como qué páginas son las más populares, cuánto tiempo pasan las personas en el sitio y qué países generan más tráfico. Esos son análisis de usuarios reales, pero es información analítica muy genérica .

Si espera obtener datos analíticos más útiles en su sitio, debe pensarlo un poco más desde el principio. ¿Que quieres saber? Tal vez quieras saber con qué frecuencia las personas usan la Función X. O quieres saber cuántos archivos han subido esta semana. O cuántos mensajes han enviado. O cuántas veces han hecho clic en el botón de estrella. Esto es algo que le indica cómo le está yendo a su sitio. El seguimiento analítico genérico no hará eso; Tendrás que escribir un poco de JavaScript para capturar e informar sobre esas cosas. Se necesita un poco de esfuerzo para obtener los análisis que realmente le interesan.

Ahora aplique eso a las herramientas de rendimiento.

En lugar de pruebas sintéticas genéricas, ¿por qué no medir los aspectos que son realmente importantes para su sitio específico ? Un aspecto de esto es RUM, es decir, “Monitoreo de usuarios reales”. Entonces, en lugar de que una sola prueba sintética sea la fuente de todas las pruebas de rendimiento en su sitio, está rastreando a los usuarios reales que realmente usan el sitio en sus dispositivos reales. Eso tiene mucho sentido para mí, pero aparte de su lógica, desbloquea algunos datos importantes.

Por ejemplo, uno de los Web Core Vitals de Google , que pronto afectará el SEO de nuestras páginas, incluye una métrica llamada First Input Delay (FID) y debes recopilar datos a través de JavaScript¹ en tu página para usarlo.

Otro Web Core Vital es la “Pintura con contenido más grande”, que es un intento fascinante de lograr una métrica de rendimiento más significativa. Imagine una métrica como “iniciar renderizado” o la pintura de la primera página. ¿Eso es interesante? Más o menos. Al menos le indica al usuario que algo está sucediendo (probablemente). Sin embargo, es posible que esa primera representación no sea contenido realmente útil, como el titular y el cuerpo de un artículo de noticias. Entonces, esta métrica adivina cuál es probablemente ese contenido útil y lo mide. Muy inteligente.

Pero, ¿por qué adivinar? Entiendo por qué Google tiene que adivinar. Tienen que medir el LCP en millones de sitios y proporcionar mediciones genéricamente útiles. Pero en su propio sitio (nuevamente, donde los análisis enfocados realmente importan) podemos decirle a las herramientas de rendimiento qué elementos nos importan y registrar cuándo se representan . Personalmente, me interesaría saber cuándo se muestra el artículo en este sitio. Con el tiempo de renderizado del héroe de SpeedCurve , podría hacer algo como:

main elementtiming="article"/main!-- or focus on the top of the page, like the "hero" timing suggests --header elementtiming="hero"/header

Ahora estoy midiendo lo que es importante para mi sitio y no sólo números genéricos.

De manera similar, FID es genial y todo eso, pero ¿por qué no activar un evento de JavaScript que informe a las herramientas de rendimiento cuando suceden cosas que son importantes para su sitio ? Por ejemplo, en CodePen, lo haríamos cuando el editor esté listo para usarse. ¡Eso se llama User Timing y es una maldita especificación W3C !

Editors.init();performance.mark("Editors are initialized.");

Este tipo de análisis que requieren algo de esfuerzo son definitivamente mejores que la tarifa estándar. Claro, un presupuesto de rendimiento que le advierte cuando supera los 200 KB de JavaScript es excelente, pero un presupuesto de rendimiento que le advierte cuando una característica principal de su aplicación no está lista hasta 1,4 segundos cuando su presupuesto es de 1,1 segundos es mucho más importante.

1. Digo esto porque estaba tratando de hacer un gráfico en SpeedCurve de los tres Web Core Vitals, y no puedes agregar FID a menos que tengas LUX ejecutándose, que es su cosa de RUM. Uf, fueron muchas siglas, lo siento.