Auditoría técnica de velocidad con Lighthouse y PageSpeed Insights

La guía de Core Web Vitals de este mismo sitio explica qué mide cada métrica (LCP, INP, CLS) y qué la hace fallar técnicamente. Esta guía va sobre otra cosa: el proceso y las herramientas con las que se audita la velocidad de una web, y los errores de interpretación que llevan a "arreglar" un número sin haber entendido primero qué está midiendo ese número. Lighthouse y PageSpeed Insights se confunden constantemente porque comparten motor, pero responden preguntas distintas, y tratarlos como intercambiables es la causa más habitual de decisiones de optimización mal dirigidas.

Cómo puntúa Lighthouse: una simulación, no una medición del mundo real

Lighthouse ejecuta una única carga simulada de la página en una instancia de Chrome sin interfaz (headless), bajo condiciones de red y CPU fijadas de antemano, y calcula una puntuación de 0 a 100 combinando varias métricas con pesos distintos. En las versiones actuales de Lighthouse la categoría de rendimiento pondera aproximadamente así: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% y Speed Index 10%. La combinación no es una media lineal: usa una curva de distribución log-normal calibrada contra datos reales de HTTP Archive, lo que significa que mejorar de 40 a 50 puntos es mucho más fácil que mejorar de 90 a 95, aunque el ahorro de tiempo real en milisegundos sea parecido en ambos tramos.

Esa curva es la razón por la que perseguir "100 en Lighthouse" como objetivo en sí mismo suele ser mal uso del tiempo: los últimos puntos exigen un esfuerzo desproporcionado frente al beneficio real para el usuario, y ese esfuerzo casi siempre está mejor invertido en otras páginas de la plantilla que todavía están en el tramo donde cada mejora cuenta mucho.

PageSpeed Insights: laboratorio y campo en la misma pantalla

PageSpeed Insights (PSI) no es una herramienta distinta de Lighthouse: ejecuta Lighthouse por debajo para generar la parte de "experiencia de laboratorio", pero además consulta el Chrome User Experience Report (CrUX) para mostrar, en la misma pantalla, la "experiencia real de los usuarios" agregada de los últimos 28 días. Es la única diferencia real entre ambas herramientas, y es una diferencia decisiva: el informe de campo (CrUX) es el que Google usa como señal de posicionamiento, no el de laboratorio.

Un matiz técnico que se pasa por alto a menudo: CrUX reporta percentil 75 (p75), no la media. Cuando PSI dice que el LCP de campo es "2.1 s", significa que el 75% de las visitas reales tuvieron un LCP igual o mejor que ese valor, no que ese sea el tiempo típico. Y si una URL concreta no recibe tráfico suficiente para tener datos propios en CrUX (umbral mínimo de muestra que Google no publica con exactitud), PSI recurre automáticamente a los datos agregados de todo el origen (dominio completo), que pueden no representar bien a esa página en particular, sobre todo si el resto del sitio tiene un perfil de rendimiento muy distinto.

Cómo leer las secciones "Oportunidades" y "Diagnósticos"

Un informe de Lighthouse separa las recomendaciones en dos bloques con lógica distinta. Las oportunidades (Opportunities) son optimizaciones con una estimación de ahorro en milisegundos o kilobytes calculada específicamente para esa carga ("Elimina recursos que bloquean el renderizado: ahorro estimado 480 ms"). Los diagnósticos (Diagnostics) son señales informativas sin una estimación de ahorro directa, pero que indican riesgo (tamaño del DOM, desglose del trabajo del hilo principal, tiempo de ejecución de JavaScript).

El error de lectura más frecuente es sumar los ahorros estimados de varias oportunidades como si fueran acumulables de forma lineal. No lo son: cada estimación se calcula de forma aislada, asumiendo que solo se corrige ese problema concreto, así que si dos oportunidades compiten por el mismo cuello de botella (por ejemplo, dos recursos distintos bloqueando el mismo hilo principal), arreglar ambas no suma sus dos ahorros por separado, porque el segundo arreglo ya encuentra parte del camino despejado por el primero.

Oportunidad                              Ahorro estimado
Elimina recursos que bloquean render.    480 ms
Reduce el JavaScript sin usar            310 ms
Sirve imágenes en formatos de próx. gen. 220 ms

Suma ingenua: 1.010 ms
Ahorro real esperado tras aplicar las 3: bastante menor,
porque las tres compiten por el mismo hilo principal
y por la misma conexión de red.

La trampa del laboratorio rápido con campo lento (y al revés)

Es habitual que un sitio recién optimizado saque 95 en Lighthouse y siga mostrando un LCP de campo mediocre en PageSpeed Insights, y la razón casi nunca es un error de medición sino una diferencia real de condiciones. Lighthouse simula un perfil fijo (aproximado a un móvil de gama media con una conexión 4G limitada) en una única ejecución con caché vacía. El dato de campo, en cambio, agrega semanas de visitas de usuarios reales con toda la variedad de dispositivos, redes rurales o saturadas, y navegadores desactualizados que el laboratorio no reproduce. En negocios con clientela dispersa geográficamente, ese desajuste entre un laboratorio optimista y un campo real más duro es extremadamente común y no indica que la optimización haya fallado, sino que representa peor a la parte más lenta de la audiencia real.

El caso contrario también ocurre: un sitio con un lab score mediocre puede mostrar un dato de campo mejor de lo esperado, normalmente porque una parte grande del tráfico real son visitas repetidas con la caché del navegador ya caliente (activos ya descargados en visitas anteriores), mientras que Lighthouse siempre arranca desde una caché completamente vacía y penaliza esa primera carga en frío que en la práctica muchos usuarios no experimentan.

Perfiles de estrangulamiento: por qué la comparación solo vale si el perfil es el mismo

Lighthouse aplica por defecto estrangulamiento simulado (simulated throttling): en vez de ralentizar de verdad la red y la CPU durante la carga, ejecuta la página sin restricciones y aplica después un modelo matemático sobre la traza capturada para estimar cómo se habría comportado con una conexión y una CPU más limitadas. Es más rápido de ejecutar y razonablemente preciso, pero es una estimación, no una medición directa. La alternativa es el estrangulamiento aplicado (vía DevTools Protocol), que sí ralentiza de verdad la red y la CPU durante la ejecución: más lento de correr y con más varianza entre ejecuciones, pero más fiel a un dispositivo real limitado.

El perfil de CPU por defecto en el modo móvil de Lighthouse aplica una ralentización de 4x sobre la CPU de la máquina que ejecuta la prueba, para aproximar el rendimiento de un móvil de gama media. Esto tiene una consecuencia práctica importante: comparar una puntuación de Lighthouse obtenida en un portátil potente sin ese estrangulamiento contra otra obtenida con el perfil móvil estándar no es una comparación válida, aunque ambas usen la "misma herramienta". Para que dos auditorías sean comparables entre sí (antes/después de un cambio, o entre dos páginas del mismo sitio) hace falta fijar el mismo perfil de dispositivo, el mismo tipo de estrangulamiento y, si es posible, repetir cada ejecución varias veces y quedarse con la mediana, porque una sola ejecución de Lighthouse tiene una varianza notable incluso en la misma máquina y el mismo momento, atribuible a ruido del sistema operativo y de la propia red.

Automatizar Lighthouse en CI: detectar regresiones antes de publicar

Ejecutar Lighthouse manualmente de vez en cuando detecta problemas ya publicados, pero no evita que se publiquen. La forma de convertirlo en una salvaguarda real es ejecutarlo en el pipeline de integración continua contra cada cambio, con un presupuesto de rendimiento (performance budget) que falle la build si una métrica empeora por encima de un umbral. La CLI de Lighthouse permite lanzarlo sin interfaz gráfica y exportar el resultado en JSON:

npm install -g lighthouse
lighthouse https://www.midominio.com/ \
  --output json --output-path ./informe.json \
  --preset=desktop --throttling-method=devtools

Para regresión continua, Lighthouse CI (LHCI) añade encima la comparación automática contra una build de referencia y un fichero de aserciones que define los umbrales aceptables:

// lighthouserc.js
module.exports = {
  ci: {
    collect: { numberOfRuns: 3, url: ['https://staging.midominio.com/'] },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.85 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'total-blocking-time': ['warn', { maxNumericValue: 300 }],
      },
    },
    upload: { target: 'temporary-public-storage' },
  },
};

Con numberOfRuns: 3 se ejecuta la auditoría tres veces y se usa la mediana, reduciendo el ruido de una ejecución aislada. Integrado como paso obligatorio en un pipeline (GitHub Actions, GitLab CI o similar), esto convierte una regresión de rendimiento en un fallo de build visible antes del despliegue, en vez de un hallazgo posterior en producción que hay que revertir.

Preguntas frecuentes