Por qué PageSpeed Insights da una puntuación distinta cada vez

Pasas PageSpeed Insights a la misma URL tres veces seguidas y obtienes 82, 76 y 85. No has tocado nada. La documentación de Lighthouse lo reconoce sin rodeos: la puntuación de rendimiento tiende a cambiar por la variabilidad propia de la web y de las redes, aunque la página no haya cambiado. Entender de dónde sale ese ruido evita dos errores opuestos: celebrar una subida que es casualidad y perder una tarde persiguiendo una bajada que tampoco existe.

Dos informes en una misma pantalla

Antes de hablar de variación conviene separar lo que muestra PSI. Según su documentación, la parte superior presenta datos de campo: experiencias reales de usuarios de Chrome (CrUX) durante los 28 días anteriores, con el percentil 75 de LCP, INP y CLS y la evaluación de Core Web Vitals. Debajo aparece el informe de laboratorio: una carga simulada con Lighthouse en un único dispositivo y unas condiciones de red fijas, de donde sale la puntuación de 0 a 100.

La puntuación que baila es la de laboratorio. Los datos de campo se actualizan a diario pero cubren una ventana de 28 días, así que no cambian por pulsar el botón otra vez. Si tu página no tiene suficiente tráfico, PSI muestra los datos del origen completo o ninguno. En Cómo montar un experimento web se explica cuándo usar cada parte.

Cómo se calcula la puntuación

Lighthouse convierte el valor bruto de cada métrica en una subpuntuación de 0 a 1 mediante una curva logarítmico-normal construida con datos reales de sitios web, y después hace una media ponderada. En Lighthouse 10 y posteriores (la versión que usa PSI hoy) los pesos son estos:

Dos consecuencias prácticas. Primera: TBT, LCP y CLS suman el 80 %, así que son las que más mueven el número. Segunda: TBT es la métrica más sensible al ruido, porque depende de cuánto JavaScript se ejecute y de lo cargada que esté la CPU en ese momento. Una página con mucho JavaScript de terceros tendrá puntuaciones más inestables que una estática. Ojo: INP no forma parte de la puntuación; es una métrica de campo y en laboratorio no hay usuario que interactúe.

Los colores son fijos: de 0 a 49 se considera deficiente, de 50 a 89 necesita mejorar y de 90 a 100 es buena. Una página cerca de un límite, por ejemplo en 88–91, cambiará de color con frecuencia sin que haya pasado nada.

De dónde sale la variación

El documento de variabilidad de Lighthouse enumera las fuentes y estima su impacto. Algunas las controlas tú y otras no:

• Red local y de Internet. La latencia y el ancho de banda reales cambian de una carga a otra. La limitación simulada (en móvil, 150 ms de RTT y 1,6 Mbps de bajada) suaviza parte del efecto, pero no todo.
• CPU del equipo que ejecuta la prueba. Si lanzas Lighthouse desde tu portátil mientras compilas o tienes veinte pestañas abiertas, TBT empeora. Con PSI la prueba corre en servidores de Google, que también tienen carga variable.
• Extensiones y antivirus. En Lighthouse dentro de Chrome, las extensiones inyectan código en la página. La documentación recomienda aislar el entorno de extensiones y antivirus y, si se puede, usar un equipo dedicado a las pruebas.
• Servidor web. Un tiempo de respuesta que oscila, por ejemplo, entre 200 y 900 ms según la carga o el estado de la caché arrastra FCP, LCP y Speed Index.
• No determinismo de la página. Pruebas A/B que sirven variantes distintas, contenido personalizado, carruseles con imágenes aleatorias.
• Anuncios y scripts de terceros. Cada carga puede recibir una creatividad distinta, más o menos pesada, con más o menos JavaScript, y en un tamaño que desplace o no el contenido. Es habitual que una página con anuncios muestre más dispersión que la misma página sin ellos.

Ejemplo: cinco ejecuciones, media frente a mediana

Qué recomienda la documentación de Lighthouse

El documento de variabilidad aconseja no fijar umbrales sobre pruebas sueltas y usar valores agregados: la mediana, el percentil 90 o incluso el mínimo y el máximo. Según ese texto, la mediana de cinco ejecuciones es el doble de estable que una ejecución. Para automatizarlo propone Lighthouse CI, que puede lanzar varias ejecuciones y quedarse con la representativa, por ejemplo con npx -p @lhci/cli lhci collect --url https://example.com -n 5.

Un matiz: Lighthouse CI no elige la mediana de la puntuación, sino la ejecución más cercana a la mediana de ciertas métricas (la función computeMedianRun del propio Lighthouse). Para una comprobación manual, la mediana de la puntuación y de cada métrica por separado es suficiente.

La misma documentación sugiere reducir el ruido en origen: ejecutar desde la misma red, aislar el navegador de extensiones y antivirus, usar servidores dedicados en integración continua (los entornos de CI gratuitos y las instancias «ampliables» o burstable suelen ser volátiles) y preferir varias máquinas pequeñas a una grande cuando se lanzan pruebas en paralelo.

Ruta de decisión ante un cambio de puntuación

1. ¿Es una sola ejecución? Repite hasta tener al menos cinco y calcula la mediana. Si la diferencia con la mediana anterior es de pocos puntos, trátala como ruido.
2. ¿La mediana cambió de verdad? Mira qué métrica la movió. Si es TBT, revisa scripts de terceros y anuncios; si es LCP, la imagen o el texto principal y el tiempo de servidor; si es CLS, espacio reservado para anuncios, imágenes y fuentes (ver Imágenes ligeras y sin saltos de diseño).
3. ¿Cambió algo en la página? Despliegues, plugins, campañas publicitarias nuevas. Si nada cambió y la mediana bajó, comprueba el servidor a distintas horas.
4. ¿Qué dicen los datos de campo? Son los que reflejan a tus usuarios y los que usa Search Console. Una puntuación de laboratorio de 70 con Core Web Vitals aprobados en campo no es una emergencia; una de 95 con LCP de campo en rojo sí merece atención.

Cuándo no merece la pena perseguir el número

La puntuación de Lighthouse resume una carga simulada, no la experiencia de tus visitantes. Si tu sitio ya aprueba Core Web Vitals en campo y la mediana de laboratorio oscila entre 85 y 92, es mejor dedicar el tiempo a contenido o a un experimento con hipótesis clara que a rascar tres puntos. Y si necesitas un control automático que no se dispare por ruido, fija límites sobre la mediana y sobre métricas o tamaños concretos, no sobre una ejecución: es lo que se trata en Presupuesto de rendimiento: cómo calcularlo con números.

• Mínimo cinco ejecuciones por versión, misma URL, mismo tipo de dispositivo.
• Comparar medianas, no ejecuciones sueltas ni medias con valores atípicos.
• Anotar la versión de Lighthouse que figura al pie del informe.
• Navegador sin extensiones o PSI; nada pesado ejecutándose en paralelo.
• Mirar qué métrica se movió antes de mirar la puntuación.
• Contrastar siempre con la sección de datos de campo.