Cómo montar un experimento web: laboratorio frente a datos de campo

Cambias el formato de la imagen principal, pasas PageSpeed Insights, la puntuación sube ocho puntos y lo das por bueno. Al día siguiente vuelves a pasarlo y ha bajado cinco. Sin un método, cualquier cambio parece funcionar o fallar según el momento en que mires. Aquí tienes una forma modesta pero ordenada de montar un experimento en una web pequeña: qué anotar antes, qué herramienta responde a cada pregunta y cuánto esperar antes de leer los datos de usuarios reales.

Antes de tocar nada: la hipótesis por escrito

Un experimento empieza con una frase que se pueda refutar. «Quiero que la web vaya más rápida» no sirve. «Si sirvo la imagen principal en AVIF con fetchpriority="high", el LCP móvil de la ficha de producto bajará de 3,4 s a menos de 2,5 s» sí sirve: nombra el cambio, la métrica, el tipo de dispositivo, la página y el resultado esperado.

Escribirla antes tiene una ventaja práctica: te obliga a elegir la métrica correcta. Si el cambio afecta a la carga de una imagen, mira LCP; si afecta al JavaScript que responde a clics, mira INP en campo y TBT (Total Blocking Time, tiempo total de bloqueo) en laboratorio; si toca la reserva de espacio de un anuncio, mira CLS. Los umbrales de cada una están en LCP, INP y CLS: qué miden y con qué umbrales se evalúan.

Una variable cada vez

Si en el mismo despliegue comprimes imágenes, quitas un plugin y cambias de tipografía, y el LCP mejora, no sabrás cuál de las tres cosas ayudó, ni si una de ellas empeoró algo que las otras compensaron. La regla es aburrida y eficaz: un cambio por experimento. Si tienes prisa, al menos agrupa cambios que actúen sobre métricas distintas y anota cuál esperas que mueva cada una.

Laboratorio y campo responden preguntas distintas

Según la documentación de PageSpeed Insights (PSI), los datos de laboratorio se generan con Lighthouse simulando la carga de la página en un único dispositivo y con unas condiciones de red fijas; los datos de campo vienen de usuarios reales de Chrome, en dispositivos y redes variados, agregados en el informe CrUX (Chrome UX Report). La consecuencia, que web.dev desarrolla en su artículo sobre las diferencias entre ambos, es que no tienen por qué coincidir y que ninguno de los dos es «el bueno»: cada uno sirve para algo.

La ventana de 28 días de CrUX

PSI indica que sus datos de campo describen la experiencia de los usuarios durante el periodo de recogida de los 28 días anteriores y que se actualizan a diario. Es una ventana que se desplaza: cada día entra un día nuevo y sale el más antiguo. Si cambias algo el día 0, el día 7 sólo una cuarta parte de la ventana refleja la versión nueva; el día 14, la mitad; hasta el día 28 la ventana no contiene únicamente datos posteriores al cambio (suponiendo tráfico constante).

Además, si la URL no tiene suficientes muestras, PSI recurre a los datos del origen completo (todas las páginas del sitio), y si el origen tampoco llega, no muestra datos de campo. En una web con poco tráfico, eso significa que a menudo no podrás medir en CrUX una página concreta.

web-vitals: no esperar a CrUX

La biblioteca web-vitals (repositorio GoogleChrome/web-vitals) expone funciones como onLCP, onINP y onCLS que reciben el valor medido en el navegador de cada visitante. Tú decides adónde enviarlo: a tu analítica o a un registro propio. Su ventaja para experimentar es que puedes separar datos por fecha exacta del despliegue y por página, sin la mezcla de la ventana de 28 días. Su compilación de atribución (web-vitals/attribution) añade qué elemento causó el valor, útil para saber qué imagen fue el LCP o qué nodo se desplazó.

import {onLCP, onINP, onCLS} from 'web-vitals';

function enviar(metrica) {
  navigator.sendBeacon('/vitals', JSON.stringify({
    nombre: metrica.name,
    valor: metrica.value,
    pagina: location.pathname
  }));
}
onLCP(enviar);
onINP(enviar);
onCLS(enviar);

El endpoint /vitals es un ejemplo: necesitas algo en el servidor que guarde esos datos, y calcular tú el percentil 75 por día y por plantilla.

La línea base

Sin una medida previa no hay comparación. La línea base se toma en las mismas condiciones que usarás después: misma URL, mismo tipo de dispositivo, misma herramienta y misma configuración. En laboratorio, la documentación de variabilidad de Lighthouse recomienda no fiarse de una ejecución suelta y usar valores agregados, como la mediana; según ese documento, la mediana de cinco ejecuciones es el doble de estable que una sola. En Por qué PageSpeed Insights da una puntuación distinta cada vez tienes el cálculo detallado.

En campo, anota el p75 de CrUX del día del cambio, para móvil y escritorio por separado, y guarda una captura: dentro de 28 días ese número ya no estará en pantalla.

Plantilla de registro de experimento

Una hoja de cálculo o un archivo de texto basta. Lo que importa es rellenarla antes del cambio y no retocarla después para que cuadre.

Ejemplo trabajado (hipotético)

Tres errores que invalidan el experimento

Cambiar tres cosas a la vez

Es el error más común porque los despliegues reales mezclan cambios. Si no puedes evitarlo, anota todo lo que entró en ese despliegue, incluidas actualizaciones de plugins o del tema, y acepta que el resultado es del conjunto, no de cada pieza.

Comparar móvil con escritorio

Lighthouse en móvil simula un dispositivo de gama media con red lenta; en escritorio usa otra configuración mucho más rápida. CrUX también separa los datos por tipo de dispositivo. Una línea base de escritorio comparada con un resultado de móvil no mide nada. Fija el tipo de dispositivo en la plantilla y respétalo en cada lectura.

Leer un solo test

Una ejecución aislada de Lighthouse puede variar varios puntos sin que la página cambie: red, carga del servidor, anuncios distintos en cada carga. Una lectura de CrUX el día 3 tampoco vale, porque la ventana todavía es casi toda antigua. Medianas en laboratorio y ventana completa en campo.

Lista de comprobación antes de dar un resultado por bueno

• La hipótesis estaba escrita antes del cambio, con métrica, página, dispositivo y valor esperado.
• Sólo cambió una variable, o están anotadas todas las que cambiaron.
• Línea base y resultado usan la misma herramienta, configuración y tipo de dispositivo.
• En laboratorio se comparan medianas de al menos cinco ejecuciones.
• En campo han pasado 28 días desde el despliegue, o tienes datos propios de web-vitals separados por fecha.
• Las métricas de control (por ejemplo, CLS si tocaste imágenes) no han empeorado.
• El resultado y la decisión quedaron escritos, también si el experimento falló.

Cuándo no merece la pena tanto rigor: si el problema es evidente (una imagen de 4 MB en la portada, un script bloqueante olvidado), arréglalo y ya está. El método sirve para decisiones con coste o con dudas, como elegir entre dos maneras de cargar fuentes o decidir cuánto JavaScript admite una plantilla. Para lo segundo, el siguiente paso es Presupuesto de rendimiento: cómo calcularlo con números.