Lighthouse y su simulación

Lighthouse no mide tu página en condiciones lentas: la carga a toda velocidad y después simula cómo habría ido en condiciones lentas, aplicando un modelo. Esa decisión de diseño explica a la vez su gran virtud, que es la reproducibilidad, y sus fallos característicos. Conocer el modelo es lo que separa leer un informe de creerse un informe.

El perfil por defecto

Lighthouse aplica limitación de red para emular una conexión móvil que corresponde aproximadamente al percentil 85 de velocidad de conexión móvil, incluso cuando lo ejecutas sobre fibra.

El preajuste estándar para móvil es:

• Latencia: 150 ms
• Caudal: 1,6 Mbps de bajada y 750 Kbps de subida
• Pérdida de paquetes: ninguna

Ese perfil se llama actualmente Slow 4G en la interfaz, y antes se llamaba Fast 3G. Representa aproximadamente el 25% inferior de las conexiones 4G y el 25% superior de las 3G. Coincide con el preajuste “Mobile 3G - Fast” de WebPageTest y, por su menor latencia, resulta algo más rápido para algunas páginas que el preajuste 4G de esa herramienta.

En cuanto a CPU, Lighthouse aplica por defecto un multiplicador constante de 4x, lo cual mueve una ejecución típica desde el rango de escritorio de gama alta hasta el rango de móvil de gama media.

Ese multiplicador tiene un problema conceptual que la propia documentación reconoce: a diferencia de la red, donde la latencia y el caudal son objetivos, la limitación de CPU es relativa al hardware anfitrión. Un 4x sobre un portátil potente y un 4x sobre un equipo modesto no producen el mismo entorno emulado. Por eso Lighthouse calcula y guarda en cada informe un índice de referencia del rendimiento de la CPU del equipo, que aparece al pie con el rótulo de potencia de CPU y memoria. Estos son los rangos aproximados publicados:

Si tu equipo cae fuera del rango esperado, el multiplicador de 4x no te lleva donde crees, y conviene ajustarlo con la opción --throttling.cpuSlowdownMultiplier. Cuando Lighthouse detecta que se está ejecutando en un equipo poco potente con la configuración por defecto, añade una advertencia al informe sugiriendo calibrar.

Los cuatro tipos de limitación de red

Entender por qué Lighthouse eligió simulación exige conocer las alternativas.

Limitación simulada. Es el modo por defecto de Lighthouse, tanto en la línea de comandos como en PageSpeed Insights y en el panel de Lighthouse de las herramientas de desarrollo. Carga la página sin limitar y después aplica un modelo que estima cómo habría ido con la red y la CPU limitadas, usando los datos observados en esa carga sin limitar. Es muy rápido y muy determinista. A cambio, predecir rutas de ejecución alternativas es imperfecto: hay casos límite en los que el modelo se equivoca.

Limitación a nivel de petición, también llamada limitación de DevTools. Es la que aplica el panel de red de las herramientas de desarrollo: añade retardo y limita el caudal petición a petición. El problema conceptual es que en una conexión móvil real la latencia actúa a nivel de paquete, no de petición, así que el modelo no es muy fiel. Lighthouse aplica multiplicadores correctores para acercarlo.

Limitación a nivel de proxy. Es razonable pero no ideal, porque no afecta al tráfico UDP y por tanto no modela bien HTTP/3.

Limitación a nivel de paquete. Es la más fiel a una red real, porque actúa donde de verdad actúa la red. A cambio introduce más varianza que las anteriores. Es lo que usa WebPageTest, y lo que conviene para una investigación profunda.

Si quieres limitación a nivel de paquete en tu propia máquina, el paquete @sitespeed.io/throttle es la opción más usable en macOS y Linux. Requiere permisos de administrador, como todos los conformadores de tráfico a nivel de paquete, y afecta a toda la interfaz de red de la máquina, no solo al navegador.

npm install @sitespeed.io/throttle -g

# Aplicar el perfil recomendado a toda la maquina.
throttle --up 768 --down 1638 --rtt 150

# Ejecutar Lighthouse con su limitacion de red desactivada,
# conservando la de CPU, porque la red ya la aplica el sistema.
lighthouse --throttling-method=devtools \
  --throttling.requestLatencyMs=0 \
  --throttling.downloadThroughputKbps=0 \
  --throttling.uploadThroughputKbps=0 \
  https://example.com

# Quitar la limitacion cuando termine.
throttle --stop

Un detalle de la interfaz que confunde a mucha gente: en el panel de Lighthouse de las herramientas de desarrollo, con la limitación simulada por defecto, el botón para ver la traza original muestra valores que no coinciden con las métricas del informe. No es un error: la traza es anterior a la simulación. Si quieres que la traza y el informe cuadren, cambia el método a limitación de DevTools en los ajustes.

Cómo se construye la puntuación

La puntuación de rendimiento es una media ponderada de varias métricas de laboratorio, cada una convertida antes en una puntuación de 0 a 100 mediante una curva log-normal calibrada con datos reales de la web.

Tres consecuencias de esa construcción, todas importantes:

La curva no es lineal. Ganar 200 milisegundos cuando estás mal apenas mueve la puntuación; ganarlos cuando estás cerca del umbral la mueve mucho. Por eso la relación entre “he mejorado X” y “la puntuación ha subido Y” es errática.

La puntuación se redondea. Diferencias de uno o dos puntos entre ejecuciones son ruido, no señal. Cualquier comparación seria necesita varias ejecuciones y mirar la mediana.

Las métricas del laboratorio no son las de campo. La puntuación incluye métricas que no son Core Web Vitals, y no incluye el INP, porque en laboratorio no hay interacciones. Un sitio puede puntuar 95 y tener un INP de campo desastroso.

La sección de oportunidades y diagnósticos es, en cambio, bastante más útil que el número, y merece la pena filtrarla por métrica. En particular, el diagnóstico del elemento del Largest Contentful Paint muestra el desglose por subpartes, que es la información más accionable del informe.

Qué le puedes creer a Lighthouse

Un resumen honesto de la fiabilidad por tipo de dato.

La regla que se deriva: cree lo que Lighthouse observa, desconfía de lo que Lighthouse estima. Los elementos identificados, los recursos bloqueantes y el desglose son observaciones. Los ahorros y la puntuación son modelos.