Lighthouse calcula la puntuación de rendimiento a partir de puntuaciones de métricas ponderadas, no del número de advertencias del informe. Cada medición pasa primero por una curva de puntuación, por lo que la relación entre milisegundos ahorrados y puntos ganados no es lineal. Para comparar resultados, mantén constantes la versión de Lighthouse, el perfil de dispositivo, la limitación de recursos y el estado de la página, y examina varias ejecuciones junto con datos de usuarios reales.
Revisa la versión antes de interpretar los pesos
La última versión del software que figuraba en el proyecto Lighthouse al comprobarlo el 17 de octubre de 2026 era v13.5.0. Esto no determina qué versión utilizó una solicitud concreta de PageSpeed Insights o tu instalación de Chrome. Los calendarios de distribución y el navegador instalado pueden diferir. Para comparar, importa la versión registrada en el informe.
También hay una distinción documental que conviene conservar. La página general de puntuación de Chrome sigue identificando su tabla habitual como «Lighthouse 10». La configuración de la rama principal inspeccionada para este artículo contiene los mismos cinco pesos distintos de cero. No se pudo verificar el archivo de configuración etiquetado v13.5.0. Por tanto, la tabla describe la configuración principal inspeccionada y el modelo documentado de Lighthouse 10, no una configuración v13.5.0 verificada por separado. Para una auditoría con versión fijada, inspecciona su JSON como se muestra más adelante.
Estos son los pesos comprobados en esas dos fuentes.
| Métrica | Peso | Qué describe |
|---|---|---|
| First Contentful Paint (FCP) | 10% | Cuándo aparece el primer contenido que cumple los criterios |
| Speed Index (SI) | 10% | La rapidez con que se completa el contenido visible durante la carga |
| Largest Contentful Paint (LCP) | 25% | Cuándo aparece el mayor elemento visible que cumple los criterios |
| Total Blocking Time (TBT) | 30% | Las partes bloqueantes de las tareas largas del hilo principal durante la ventana medida |
| Cumulative Layout Shift (CLS) | 25% | El movimiento inesperado medido durante la carga auditada |
La configuración inspeccionada también incluye INP con peso cero. Una puntuación de navegación estándar no es, por tanto, una puntuación de INP. TBT ayuda a localizar trabajo del hilo principal que merece investigación, pero sustituir el INP de usuarios reales por TBT cambia la pregunta que se responde.
Un cambio en la organización del informe no implica un cambio de puntuación. Lighthouse 13 agrupó auditorías antiguas en estadísticas; su anuncio indicó expresamente que esto no modificaba la puntuación de rendimiento. Que desaparezca un nombre antiguo no demuestra que el problema haya dejado de importar.
Convierte las mediciones en puntuaciones antes de promediar
El valor de LCP es una duración. CLS no tiene unidades. Sumarlos directamente no tendría una interpretación útil. Lighthouse transforma primero cada medición en su propia puntuación y después combina las puntuaciones según sus pesos.
Google describe distribuciones de puntuación logarítmico-normales basadas en datos de HTTP Archive. Por eso, mejoras iguales en una medición no siempre producen ganancias iguales de puntos. Cerca de una parte pronunciada de la curva, una mejora puede notarse mucho; cerca del máximo, una mejora similar puede apenas cambiar el entero mostrado. Tampoco son intercambiables las puntuaciones móviles y de escritorio: difieren sus configuraciones y expectativas de puntuación.
Como ejemplo exclusivamente aritmético, imagina que todas las puntuaciones permanecen iguales salvo TBT, cuya puntuación normalizada mejora 10 puntos en una escala de 0 a 100. Con un peso del 30%, su aportación al total aumenta 3 puntos antes del redondeo. Es un cálculo hipotético, no una prueba de rendimiento ni una promesa sobre un cambio de código.
Distingue entre el valor de una métrica y su puntuación. Eliminar 100 milisegundos de trabajo no añade 100 puntos ni una cantidad fija de puntos. Influyen el valor inicial, la curva, la ventana de medición y las demás métricas. Una optimización también puede modificar varias métricas a la vez, lo que dificulta aún más las predicciones sencillas.
Utiliza la explicación oficial de la puntuación para entender el modelo. Elige el trabajo técnico con los valores de tu informe. Un pequeño cambio de puntuación puede acompañar una mejora importante en un elemento lento, especialmente si otra métrica sigue limitando el total.
Las advertencias señalan causas, no descuentos directos
Una hoja de estilos que bloquea el renderizado no conlleva una penalización universal de un número fijo de puntos. Su efecto depende de si retrasa contenido que participa en las métricas. Del mismo modo, una advertencia de JavaScript sin usar señala trabajo posiblemente prescindible; su etiqueta no es una métrica ponderada adicional.
Esto evita dos errores habituales. Eliminar todas las advertencias visibles no equivale a mejorar la experiencia. Además, sumar los ahorros estimados de varias estadísticas no produce un ahorro total fiable: pueden solaparse, depender de la misma cadena de solicitudes o cambiar la planificación del navegador al aplicarse juntas.
Examina la cascada de solicitudes y la línea temporal del hilo principal. Que la imagen principal se descubra tarde es distinto de que se descubra pronto pero se descargue despacio. Si JavaScript monopoliza el hilo principal, empieza por reducir el tiempo de ejecución de JavaScript en lugar de volver a comprimir una imagen que ya es pequeña.
Conserva las métricas individuales aunque se solicite una única puntuación. Un total superior puede ocultar una regresión. Por ejemplo, una mejora de CLS puede compensar una entrega de contenido más lenta en el promedio ponderado. El total no determina por sí solo si esa compensación es aceptable.
Controla las condiciones que provocan variaciones
Lighthouse mide un sistema en funcionamiento. La actividad de CPU en segundo plano, extensiones, anuncios variables, experimentos, caché, rutas de red y carga del servidor pueden modificar cada ejecución. Un navegador con código inyectado por una extensión no observa la misma carga de trabajo que un navegador limpio.
La limitación de recursos introduce otra frontera. La limitación simulada estima el rendimiento desde una traza observada, mientras que la aplicada restringe la ejecución. Un resultado obtenido con un método no debe tratarse como repetición exacta del obtenido con otro. Mantén el método y regístralo.
Una misma URL puede devolver experiencias diferentes. Un aviso de consentimiento, una sesión iniciada, contenido geográfico o un experimento modifican el DOM, las solicitudes y los scripts. Registra el estado probado en vez de suponer que la URL identifica todo el experimento. Prueba por separado estados importantes que existan en producción.
Una primera visita sin caché y una visita repetida merecen atención separada. Una fuente o un script en caché cambia la ruta crítica; una respuesta HTML almacenada puede cambiar los tiempos del servidor. Conserva la política de caché entre referencia y candidato. No compares una referencia en frío con un candidato en caliente y atribuyas toda la diferencia al código.
Para comparar localmente, utiliza un equipo estable y sin carga innecesaria. Cierra aplicaciones pesadas, evita auditorías simultáneas y usa un perfil limpio. Mantén la configuración energética. Así reduces ruido evitable, pero no conviertes un portátil en una muestra representativa de todos los visitantes.
Ejecuta una comparación reproducible por línea de comandos
La CLI permite guardar juntos comando, versión y salida. Requiere una instalación compatible de Node.js y Chrome o Chromium. Comprueba los requisitos de la versión seleccionada antes de instalarla. Los comandos siguientes fijan la versión observada durante la investigación; son ilustrativos y no se ejecutaron contra example.com para este artículo.
Guarda cinco informes JSON separados con la misma versión y la configuración móvil predeterminada.
mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
npx --yes [email protected] https://example.com/ --only-categories=performance --chrome-flags="--headless" --output=json --output-path="lighthouse-reports/mobile-${run}.json"
doneCinco ejecuciones son una muestra inicial práctica, no una garantía estadística ni un requisito oficial de aprobación. Aplica el mismo procedimiento a referencia y candidato. Si hay mucha dispersión, investiga su causa antes de interpretar una diferencia pequeña como progreso.
Lee la versión, los pesos distintos de cero y la puntuación en el informe guardado, sin inferirlos de una captura.
// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';
const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));Ejecuta el script sobre el primer informe.
node inspect-lighthouse.mjs lighthouse-reports/mobile-1.jsonLa puntuación JSON está normalizada: 0.9 corresponde a 90 antes del formato de presentación. Conserva los informes completos, no solo los totales. Sus ajustes y métricas permiten explicar diferencias posteriormente. Para escritorio, crea otra serie con --preset=desktop; no mezcles sus resultados con los móviles.
Utiliza medianas sin ocultar la dispersión
Ordena las puntuaciones repetidas y comunica el valor central como mediana sencilla. Conserva también el mínimo, el máximo y las métricas individuales. La mediana reduce la influencia de una ejecución excepcionalmente rápida o lenta, pero no corrige una prueba mal controlada.
No fabriques un «mejor informe» combinando el LCP más rápido de una ejecución, el TBT más bajo de otra y el CLS mínimo de una tercera. Esa combinación nunca ocurrió. Conserva un informe representativo y el conjunto completo para mantener visibles las relaciones entre mediciones.
Una comparación útil incluye URL y revisión, estado, versiones del navegador y Lighthouse, perfil, método de limitación, cantidad de ejecuciones, mediana y dispersión de las métricas relevantes. Añade el cambio estudiado y cualquier diferencia ambiental conocida. El resultado se convierte en evidencia reproducible, no en un número sin contexto.
PageSpeed Insights, DevTools y la CLI pueden utilizar versiones y entornos distintos. La guía de PageSpeed Insights explica su informe. Cuando dos herramientas discrepan, compara primero sus ajustes y estados; no supongas que una está equivocada porque ofrece la puntuación inferior.
Convierte la puntuación en la siguiente medición útil
Una puntuación de 100 es un resultado de laboratorio redondeado bajo condiciones concretas, no un certificado de rapidez para cada visitante. No comprueba todas las rutas, interacciones, lenguas, sesiones o dispositivos. Pueden quedar fuera cambios de diseño posteriores e interacciones lentas.
Mantén juntos los datos de campo y de laboratorio. Utiliza pruebas controladas para explicar un cambio rápidamente y mediciones reales para comprobar si beneficia a la audiencia prevista. Sus diferencias pueden revelar una condición que falta en las pruebas sin invalidar ninguno de los conjuntos.
En la siguiente iteración, elige una métrica lenta, identifica su causa en solicitudes o hilo principal y realiza un cambio revisable. Guarda una referencia repetible con el analizador de PageSpeed cuando esté configurado, o con la CLI anterior. Continúa con la guía de optimización de velocidad adecuada cuando la medición indique la causa. El objetivo útil es una mejora demostrada que resista pruebas repetidas y llegue a los usuarios.
