Lighthouse de Google

TL;DR — Lighthouse es una herramienta gratuita de Google que califica una página web de 0 a 100 en aspectos como velocidad y accesibilidad. Ejecuta la página en un “laboratorio” ralentizado — un teléfono lento simulado en una red lenta — por lo que la puntuación suele ser más baja de lo que tu sitio se siente. Es una gran lista de tareas para mejoras, pero una puntuación alta no te sube en los rankings de Google.

Qué es Lighthouse

Google Lighthouse es una herramienta gratuita y de código abierto del equipo detrás de Chrome. Lo apuntas a una URL, ejecuta una serie de comprobaciones en la página y te entrega un informe con puntuaciones en cuatro áreas: Rendimiento (qué tan rápido carga la página), Accesibilidad (¿pueden usarla personas con discapacidades?), Mejores prácticas (hygiene web general) y SEO (comprobaciones básicas de amabilidad con los buscadores).

Cada puntuación va de 0 a 100, con bandas de color para que sepas de un vistazo cómo te fue:

• 0–49 es rojo — deficiente
• 50–89 es naranja — necesita mejoras
• 90–100 es verde — bueno

Lo primero que debes entender

Lighthouse prueba tu página bajo condiciones falsas y ralentizadas — aproximadamente un teléfono de gama media en una conexión 4G lenta. Lo hace a propósito, para poder detectar problemas que los usuarios reales en dispositivos más lentos sentirían.

Por eso puedes ejecutar Lighthouse en un sitio que carga al instante en tu portátil rápido y aun así ver una puntuación de Rendimiento de 55. No estás viendo lo que tú experimentas — estás viendo lo que un teléfono económico en una red mediocre experimentaría. Información útil, pero no lo mismo.

Lighthouse no es PageSpeed Insights (exactamente)

Probablemente has visto Lighthouse sin saberlo. Cuando ejecutas una página a través de PageSpeed Insights (la herramienta web en pagespeed.web.dev), las puntuaciones de “laboratorio” que muestra son Lighthouse. PageSpeed Insights solo envuelve Lighthouse y añade un segundo conjunto de números de usuarios reales (llamados datos de campo, o el Chrome UX Report). Más sobre esa distinción en la versión Avanzada.

El gran mito que debes descartar

Una puntuación perfecta de Lighthouse no significa los mejores rankings. Lighthouse es una herramienta útil para encontrar cosas que arreglar, pero la puntuación en sí no es lo que Google usa para clasificarte. Los números de rendimiento que Google realmente considera para el ranking provienen de usuarios reales, no del laboratorio de Lighthouse. Perseguir un 100 es genial para tus visitantes — solo no esperes que sea un truco para los rankings.

¿Quieres los pesos de las métricas, por qué las puntuaciones saltan entre ejecuciones y exactamente cómo se relaciona Lighthouse con Core Web Vitals? Cambia a la pestaña Avanzado.

TL;DR — Lighthouse es una herramienta automatizada de código abierto que audita una página en condiciones de laboratorio (4G lenta simulada + aceleración de CPU 4×) y puntúa Rendimiento, Accesibilidad, Mejores prácticas y SEO — PWA se eliminó en Lighthouse 12. La puntuación de Rendimiento es un promedio ponderado de cinco métricas de laboratorio: TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, Speed Index 10 %. Bandas: 0–49 rojo, 50–89 naranja, 90–100 verde. Son datos de laboratorio, por lo que no es la señal de ranking de Core Web Vitals, no puede medir INP como lo hace el campo (usa TBT como proxy) y varía entre ejecuciones. Alimenta la mitad de laboratorio de PageSpeed Insights; PSI añade datos de campo de CrUX encima. Un 100 no compra rankings.

Qué es Lighthouse realmente

La propia frase de una línea de Google es la definición más limpia: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (traducción) «Lighthouse es una herramienta automatizada de código abierto para ayudarte a mejorar la calidad de las páginas web.» La mecánica es igual de simple — “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (traducción) «dale a Lighthouse una URL para auditar, ejecuta una serie de auditorías contra la página y luego genera un informe sobre qué tan bien se desempeñó la página.»

Hoy puntúa cuatro categorías: Rendimiento, Accesibilidad, Mejores prácticas y SEO. Si has leído guías más antiguas que dicen cinco, están desactualizadas — la categoría PWA se eliminó en Lighthouse 12 (alrededor de 2024), siguiendo los criterios de instalabilidad actualizados de Chrome. Así que si una publicación de blog aún cita una puntuación de PWA, esa es tu señal de que es anterior a la versión actual.

El marco crucial es una palabra: laboratorio. Lighthouse carga tu página en un entorno controlado y simulado, no desde tus visitantes reales. Ese único hecho explica casi toda la confusión que la gente tiene al respecto.

Cómo funciona Lighthouse: las condiciones de laboratorio

Por defecto, Lighthouse utiliza limitación simulada y limita de forma agresiva. Los valores predeterminados emulan aproximadamente un dispositivo móvil de gama media con una conexión 4G lenta:

• Red: el ajuste preestablecido móvil 4G lento: aproximadamente 150 ms de latencia y 1,6 Mbps de bajada / 750 Kbps de subida. Google lo describe como “the ~85th percentile mobile connection speed even when run on much faster fiber connections.” (traducción) «la velocidad de conexión móvil del percentil 85 aproximado, incluso al ejecutarse en conexiones de fibra mucho más rápidas».
• CPU: un multiplicador de CPU constante de 4×, que simula el procesador de un teléfono de gama media en tu hardware de escritorio más rápido.

Esto es intencional. Lighthouse no intenta decirte “así de rápido es tu sitio para todos”. Está sometiendo a la página a una prueba de esfuerzo contra un grupo más lento que la media para que salgan a la luz problemas que tu portátil rápido oculta. Es por eso que un sitio que te parece instantáneo puede obtener una puntuación de 60: tú eres un MacBook de alto rendimiento con fibra; la prueba es un Android económico con una red regular.

Un matiz que conviene tener claro: la limitación simulada (la predeterminada) no es lo mismo que la limitación de DevTools / aplicada. La limitación simulada modela cómo habría cargado la página en esas condiciones basándose en una observación inicial sin limitar; Google señala que este enfoque es “both very fast and deterministic.” (traducción) «muy rápido y determinista». La limitación estilo DevTools realmente ralentiza las solicitudes, lo que Google dice que es “not a sufficient model of a slow connection.” (traducción) «un modelo insuficiente de una conexión lenta». Para una medición repetible, se prefiere el modo simulado predeterminado.

La puntuación de rendimiento: cómo se calcula

La puntuación de rendimiento es “una media ponderada de las puntuaciones de las métricas”. Estos pesos se establecieron en Lighthouse 10 y siguen siendo la tabla publicada actual. Lighthouse 13 (lanzado en 2026) lo dice explícitamente: consolidó un conjunto de auditorías de rendimiento que no puntúan en “Insights” compartidos, también utilizados por el panel de rendimiento de DevTools, pero señala que “no hay cambios en la puntuación de rendimiento” en esa versión: la puntuación se basa en las métricas siguientes, no en los nombres de las auditorías, y esas no cambiaron. Cinco métricas componen la puntuación:

Algunas cosas que debes interiorizar aquí:

• TBT tiene el mayor peso (30 %). Es el proxy de laboratorio para la capacidad de respuesta. El retardo de la primera entrada (FID) ha desaparecido, y también métricas más antiguas como el tiempo hasta la interactividad y la primera pintura significativa: se han retirado.
• El índice de velocidad es una métrica de Lighthouse, no un Core Web Vital. Sigue contando un 10 % en la puntuación de rendimiento de Lighthouse aunque no sea uno de los CWV relevantes para el ranking de Google.
• Cada métrica se puntúa según una curva, no un umbral fijo. Lighthouse toma el valor bruto (normalmente en milisegundos) y lo mapea en una distribución log-normal construida a partir de datos reales del archivo HTTP. Los puntos de control de Google: el percentil 25 de esos datos aterriza en una puntuación de 50, y el percentil 8 aterriza en 90. Así que un 90+ significa que estás aproximadamente en el top ~8 % de las páginas en esa métrica, por lo que los últimos puntos son tan difíciles de ganar.
• Solo las puntuaciones de las métricas mueven el número. Las secciones de Oportunidades y Diagnósticos del informe son orientación: te dicen qué corregir, pero no cambian directamente la puntuación de rendimiento. Corregirlas mejora las métricas, y las métricas mueven la puntuación.

Por qué tu puntuación cambia entre ejecuciones

Esta es la queja que más escucho: “Lo ejecuté dos veces y obtuve 84 y luego 91, ¿está roto?” No. Google es explícito: “Gran parte de la variabilidad en tu puntuación general de rendimiento y en los valores de las métricas no se debe a Lighthouse.” Cuando el número cambia, normalmente se debe a que las condiciones subyacentes cambian:

• Pruebas A/B o anuncios diferentes que se muestran en cada carga
• Cambios en el enrutamiento de Internet: tanto en tu red local como en la ruta más larga entre regiones que sigue una solicitud
• El propio servidor web que responde a velocidades inconsistentes
• Probar en hardware diferente (un escritorio rápido frente a un portátil cansado): la limitación de la CPU es relativa a la máquina anfitriona, por lo que un multiplicador “4×” significa algo diferente en una máquina rápida que en una lenta
• Extensiones del navegador que inyectan JavaScript o solicitudes de red adicionales
• Software antivirus u otros procesos en segundo plano que compiten por los recursos

Por ejemplo: ejecuta la misma URL dos veces y una pasada carga un creativo de anuncio más pesado o detecta una respuesta del servidor más lenta: las auditorías de esa ejecución reflejan esa carga concreta, no un defecto que hayas introducido. Trátalo como una muestra única, no como un veredicto.

El modelo mental correcto, directamente de la documentación, es tratar el rendimiento como una distribución de puntuaciones, en lugar de un número único. Ejecútalo varias veces, idealmente en una ventana de incógnito con las extensiones desactivadas, en hardware y condiciones de red coincidentes, y observa el rango o la mediana, no un solo resultado. Cuando necesites comparar ejecuciones más adelante, anota la versión de Lighthouse, el modo de ejecución y el método de limitación junto con la puntuación; una puntuación de una versión o configuración diferente no es una comparación comparable, incluso si el número parece similar.

Cómo ejecutar Lighthouse de forma responsable

Usa Lighthouse como un diagnóstico controlado, no como un veredicto de un solo clic:

1. Prueba la URL exacta desplegada, no una plantilla diferente ni una compilación local sin publicar.
2. Coincide el perfil del dispositivo, el método de limitación, la versión de Lighthouse, el estado de la caché, la autenticación, el estado de consentimiento y la geografía de prueba para cada comparación.
3. Comienza cada ejecución con una navegación nueva. Redimensionar una página de escritorio ya cargada a una ventana móvil no reproduce una navegación móvil, una secuencia de solicitudes, ni una respuesta del servidor.
4. Ejecuta al menos tres veces. Informa la mediana como resultado principal y conserva las ejecuciones individuales, el rango, las marcas de tiempo, las advertencias y los seguimientos para que un valor atípico sea visible en lugar de descartarse silenciosamente.
5. Compara antes y después en las mismas condiciones. Si el servicio de prueba se ejecuta desde otra región, regístralo: la distancia de red añadida o un borde de CDN diferente puede cambiar los tiempos del servidor y de carga sin un cambio de código.
6. Comprueba CrUX por separado antes de hacer una afirmación sobre usuarios reales. Una mejor mediana de laboratorio respalda “este cambio mejoró esta prueba controlada”, no “los usuarios ahora superan las Core Web Vitals”.

La evidencia respalda conclusiones diferentes:

Esto sigue el propio modelo basado en distribución de Lighthouse para la variabilidad de puntuaciones y mantiene intacta la distinción entre laboratorio y campo. Evidence for this claim Lighthouse performance scores are weighted from lab metrics; 90–100 is good, 50–89 needs improvement, and 0–49 is poor. Scope: Current published Lighthouse performance-scoring model; metric weights can change by Lighthouse version. Confidence: high · Verified: 2026-07-14 Chrome Developers: Performance scoring

Lighthouse vs. PageSpeed Insights: la distinción que importa

Estos se confunden constantemente, así que sé preciso:

• Lighthouse es el motor. Produce datos de laboratorio: las puntuaciones de Rendimiento, Accesibilidad, Buenas prácticas y SEO.
• PageSpeed Insights es una interfaz web que ejecuta Lighthouse y añade datos de campo del Chrome UX Report (CrUX): Core Web Vitals reales de usuarios anónimos, que se muestran cuando hay suficientes datos para la URL o el origen.

Así que en PSI estás viendo dos conjuntos de datos diferentes lado a lado. La sección de “datos de campo” en la parte superior (usuarios reales, de CrUX) es separada de la sección de “datos de laboratorio” de Lighthouse debajo de ella, y con frecuencia no coinciden. Cuando alguien dice “mi puntuación de PageSpeed Insights”, casi siempre se refiere a la puntuación de Rendimiento de Lighthouse, no a los datos de campo.

Lighthouse y Core Web Vitals: cómo se relacionan

Lighthouse mide algunos Core Web Vitals en el laboratorio: informa LCP y CLS como métricas de laboratorio. Pero hay un límite estricto:

Lighthouse no puede medir INP como lo hace el campo. Interaction to Next Paint necesita interacciones de usuarios reales para medirse; no hay un usuario real haciendo clic en una ejecución de laboratorio. Así que Lighthouse usa Total Blocking Time como proxy de laboratorio para la capacidad de respuesta. TBT se correlaciona con INP, pero un TBT aprobado no garantiza un INP aprobado para usuarios reales. Están relacionados, no son lo mismo.

Este es el corazón de la brecha entre laboratorio y campo. Los datos de campo, de CrUX, que aparecen en Search Console y en la parte superior de PageSpeed Insights, son los que reflejan a los usuarios reales y los que alimentan las señales de experiencia de página de Google. Los datos de laboratorio de Lighthouse son para depurar y detectar regresiones antes de publicar. La propia guía de Google es “priorizar los datos de campo para comprender las experiencias de los usuarios en el mundo real” y usar “datos de laboratorio para depurar, probar funciones antes del despliegue”.

Dónde ejecutarlo

Mismo motor, diferentes superficies:

• Chrome DevTools: integrado en el navegador (el panel de Lighthouse). Ideal para páginas detrás de un inicio de sesión, ya que puedes auditar páginas autenticadas.
• PageSpeed Insights: la interfaz web sin instalación en pagespeed.web.dev; ejecuta Lighthouse y añade datos de campo de CrUX.
• CLI: npm install -g lighthouse, luego lighthouse <url>; se puede escribir en scripts.
• Módulo de Node: impórtalo programáticamente en tus propias herramientas y CI.
• Lighthouse CI: la configuración oficial para detectar regresiones de rendimiento en cada despliegue. El flujo de trabajo es recopilar → verificar → subir: collect ejecuta Lighthouse varias veces contra una URL (tres ejecuciones por defecto) y toma el informe mediano en lugar de confiar en una sola pasada; assert comprueba ese informe contra los umbrales que configures, establecidos en warn o error por categoría o métrica; upload almacena el informe para que puedas seguir las líneas de tendencia entre versiones. Trata los umbrales como la política de regresiones de tu equipo, no como un veredicto de datos de campo ni una garantía de clasificación: detectan “esto ha empeorado”, no certifican “esto es rápido para los usuarios”.
• Extensión de Chrome: existe, pero DevTools es la vía recomendada en el navegador.

Los flujos de trabajo de CLI y Node necesitan una instalación local de Chrome para funcionar.

Los mitos que merece la pena desmentir

• “Una puntuación de 100 en Lighthouse = mejores clasificaciones.” No. La puntuación de Rendimiento son datos de laboratorio; no es una señal de clasificación. Las señales de experiencia de página de Google usan datos de campo de Core Web Vitals (CrUX), e incluso eso es una señal ligera entre muchas: la relevancia y la calidad del contenido dominan. Apunta a una puntuación alta porque es buena para los usuarios, no porque sea una palanca de clasificación.
• “Lighthouse = datos de campo / lo que experimentan los usuarios reales.” No. Son condiciones de laboratorio limitadas, peores que lo que ven la mayoría de los usuarios reales. Los usuarios reales tienen cachés cálidas, bfcache y dispositivos variados. Lighthouse es una prueba de estrés de caso casi peor, no una lectura del usuario medio.
• “PageSpeed Insights es Lighthouse.” En parte. PSI ejecuta Lighthouse para la sección de laboratorio y añade CrUX para la sección de campo. Los números de campo, los vinculados a la experiencia de página, son de CrUX, no de Lighthouse.
• “La categoría PWA todavía cuenta.” No. PWA se eliminó como categoría puntuada en Lighthouse 12.

Conclusión

Lighthouse es una de las herramientas gratuitas más útiles en SEO técnico y rendimiento web: una forma rápida y repetible de encontrar qué está ralentizando una página y de protegerse contra regresiones en CI. Solo hay que mantenerlo a la altitud correcta: es un diagnóstico de laboratorio, no un veredicto sobre la experiencia del usuario real ni una puntuación de ranking. Úsalo para encontrar y corregir; usa datos de campo (CrUX, Core Web Vitals en Search Console) para juzgar si los usuarios reales están teniendo una buena experiencia.

Resumen de IA

Una versión condensada de la versión avanzada:

• Lighthouse = herramienta de auditoría de laboratorio automatizada y de código abierto del equipo de Chrome. Dale una URL; audita la página y puntúa Rendimiento, Accesibilidad, Buenas prácticas, SEO. PWA se eliminó en Lighthouse 12 (~2024).
• Laboratorio, no campo. Carga la página bajo una limitación simulada — aproximadamente 4G lento + CPU 4× — por diseño, para sacar a la superficie lo que experimentan los dispositivos/redes más lentos. Por eso un sitio “rápido” puede obtener una puntuación baja.
• La puntuación de rendimiento = promedio ponderado de cinco métricas de laboratorio: TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, Speed Index 10 %. FID y First Meaningful Paint ya no están.
• Bandas: 0–49 rojo (pobre), 50–89 naranja (necesita mejoras), 90–100 verde (bueno). Las puntuaciones de las métricas se asignan a una curva log-normal del HTTP Archive, por lo que los puntos más altos son los más difíciles. Oportunidades/Diagnósticos guían las correcciones pero no cambian directamente la puntuación.
• Las puntuaciones varían de una ejecución a otra — anuncios, pruebas A/B, extensiones, condiciones de red/servidor y carga de la máquina (la limitación de CPU es relativa al host). Trátalo como una distribución, no como un número único; ejecuta en modo incógnito con las extensiones desactivadas y registra la versión de Lighthouse y la configuración que usaste.
• Lighthouse CI automatiza esto: recopila múltiples ejecuciones (tres por defecto), toma la mediana y verifica los umbrales de tu equipo — una política de detección de regresiones, no un veredicto de datos de campo.
• Lighthouse ≠ PageSpeed Insights: PSI ejecuta Lighthouse (laboratorio) y añade datos de campo de CrUX (usuarios reales). A menudo no coinciden.
• Lighthouse mide LCP/CLS en el laboratorio pero no puede medir INP como lo hace el campo — usa TBT como proxy. Los datos de campo (CrUX) son los que reflejan a los usuarios reales y alimentan las señales de experiencia de página.
• No es una señal de ranking. Un 100 no significa los mejores rankings, y una puntuación de laboratorio baja no significa una mala experiencia de usuario real. Usa Lighthouse para depurar; usa datos de campo para juzgar.

Documentación oficial

Documentación de fuente primaria del equipo de Google Chrome.

• Descripción general de Lighthouse — qué es Lighthouse, las categorías de auditoría y todas las formas de ejecutarlo (DevTools, CLI, Node, PageSpeed Insights, extensión, Lighthouse CI).
• Puntuación de rendimiento de Lighthouse — los pesos de las métricas, las bandas de color 0–49 / 50–89 / 90–100 y la curva de puntuación log-normal.
• Auditorías PWA de Lighthouse — incluye el aviso de desaprobación de la categoría PWA eliminada.
• Limitación de Lighthouse (GitHub) — limitación simulada vs. aplicada, el ajuste preestablecido de 4G lento y el multiplicador de CPU 4×.
• Registro de cambios de Lighthouse (GitHub) — los cambios de la v12: eliminación de PWA, eliminación de First Meaningful Paint, INP elevado.
• Calculadora de puntuación de Lighthouse — introduce valores de métricas y ve la puntuación de rendimiento resultante; útil para establecer objetivos.

Laboratorio vs. campo (web.dev)

• Métricas de rendimiento centradas en el usuario — por qué las pruebas de laboratorio “no son necesariamente reflejo de cómo los usuarios reales experimentan tu sitio”.

Citas de la fuente

Declaraciones registradas de la documentación de Lighthouse de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Qué es Lighthouse y cómo se ejecuta

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (traducción) «Lighthouse es una herramienta automatizada de código abierto que ayuda a mejorar la calidad de las páginas web». — developer.chrome.com, Lighthouse overview. Ir a la cita
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (traducción) «Dale a Lighthouse una URL para auditar; ejecutará una serie de auditorías sobre la página y generará un informe de su rendimiento». — developer.chrome.com, Lighthouse overview. Ir a la cita

Cómo funciona la puntuación de rendimiento

• “The Performance score is a weighted average of the metric scores.” (traducción) «La puntuación de Rendimiento es una media ponderada de las puntuaciones de las métricas». — developer.chrome.com, Lighthouse performance scoring. Ir a la cita
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” (traducción) «Una vez recopiladas las métricas de rendimiento —expresadas en su mayoría en milisegundos—, Lighthouse convierte cada valor sin procesar en una puntuación de 0 a 100 según su posición en la distribución de puntuaciones de Lighthouse». — developer.chrome.com, Lighthouse performance scoring. Ir a la cita
• Sobre las bandas de puntuación: “0 to 49 (red): Poor” (traducción) «De 0 a 49 (rojo): deficiente» — con 50–89 naranja (necesita mejoras) y 90–100 verde (bueno). Ir a la cita

Por qué varían las puntuaciones

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” (traducción) «Gran parte de la variabilidad de la puntuación global de Rendimiento y de los valores de las métricas no se debe a Lighthouse; cuando la puntuación fluctúa, suele deberse a cambios en las condiciones subyacentes». — developer.chrome.com, Lighthouse performance scoring. Ir a la cita

Laboratorio vs. campo

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” (traducción) «Aunque las pruebas de laboratorio son una aproximación razonable al rendimiento, no reflejan necesariamente cómo experimentan el sitio los usuarios reales». — web.dev, User-centric performance metrics. Ir a la cita

Cómo obtener una lectura fiable de Lighthouse: lista de verificación

Antes de actuar según una puntuación de Lighthouse, asegúrate de que el número significa algo:

• Ejecútalo en una ventana de incógnito con las extensiones desactivadas (las extensiones inyectan JS y sesgan la puntuación).
• Ejecútalo varias veces y observa el rango: trátalo como una distribución, no como un número único.
• Confirma que estás comparando el mismo factor de forma cada vez (móvil vs. escritorio: la limitación difiere).
• Sepa qué conjunto de datos estás leyendo: laboratorio (Lighthouse) vs. campo (CrUX) en PageSpeed Insights. No los mezcles.
• Para preguntas de clasificación/experiencia de página, mira los datos de campo (Core Web Vitals en Search Console / CrUX), no la puntuación de laboratorio de Lighthouse.
• Recuerda que Lighthouse no puede medir INP como lo hace el campo: TBT es un proxy, no una garantía.
• Corrige desde las listas de Oportunidades/Diagnósticos, pero verifica el cambio observando cómo se mueve la métrica (solo las métricas cambian la puntuación).
• Para mediciones repetibles en automatización, usa Lighthouse CI con presupuestos en lugar de mirar ejecuciones puntuales.
• Controla lo que muestra la página al cargar: los banners de cookies/consentimiento, el estado de inicio de sesión y la caché (fría vs. cálida) cambian las auditorías que se ejecutan: elige un estado y sé consistente con él.
• Presta atención al contenido no determinista: las pruebas A/B, los anuncios rotativos y otros scripts de terceros pueden servir una carga útil diferente en cada ejecución y hacer variar la puntuación independientemente de lo que hayas cambiado.
• Deja que la página termine de cargar antes de activar la auditoría (o usa un modo que espere a que termine): cortar una ejecución antes de tiempo malinterpreta la página.
• Registra la versión de Lighthouse y la configuración de ejecución (modo, método de limitación, dispositivo) junto con la puntuación: una puntuación “igual” de una versión o configuración diferente no es realmente comparable.
• Ignora cualquier guía que aún puntúe la categoría PWA: eso se eliminó en Lighthouse 12.

Puntuación de rendimiento de Lighthouse: hoja de referencia

Las cinco métricas y sus pesos (ponderación de Lighthouse 10)

Retiradas / eliminadas: FID, Tiempo de interacción, Primera pintura significativa.

Bandas de color de puntuación

Mapeado en una curva log-normal del Archivo HTTP: percentil ~25 → 50, percentil ~8 → 90. Los últimos puntos son los más difíciles de ganar.

Condiciones de laboratorio predeterminadas

• Red: móvil 4G lento (~150 ms de latencia, ~1,6 Mbps de bajada / 750 Kbps de subida)
• CPU: multiplicador constante 4× (móvil de gama media en hardware de escritorio)
• Limitación: simulada por defecto (rápida, determinista), no aplicada por DevTools

Lighthouse vs. PageSpeed Insights

Datos rápidos

• Categorías actuales: Rendimiento, Accesibilidad, Buenas prácticas, SEO (PWA eliminada en Lighthouse 12).
• No es una señal de ranking. Un 100 ≠ mejores posiciones.
• No puede medir INP como lo hace el campo: usa TBT como proxy.
• Las puntuaciones varían de una ejecución a otra: eso es esperado.

Formas de ejecutar Lighthouse (y herramientas relacionadas)

• Chrome DevTools — panel de Lighthouse — integrado en Chrome; ideal para auditar páginas detrás de un inicio de sesión.
• PageSpeed Insights (pagespeed.web.dev) — sin instalación; ejecuta Lighthouse y añade datos de campo de CrUX junto a él.
• CLI de Lighthouse — npm install -g lighthouse, luego lighthouse <url>; se puede automatizar, necesita un Chrome local.
• Módulo Node de Lighthouse — intégralo en tus propias herramientas de forma programática.
• Lighthouse CI (@lhci/cli) — ejecuta Lighthouse en cada despliegue, establece presupuestos y falla la compilación ante regresiones. La herramienta adecuada para evitar que una puntuación baje silenciosamente.
• Calculadora de puntuación de Lighthouse (scorecalc) — introduce valores de métricas para ver la puntuación de rendimiento resultante y establecer objetivos realistas.
• Extensión de Chrome — disponible, pero DevTools es la ruta recomendada en el navegador.

Para datos de usuarios reales (de campo) que complementen estas herramientas de laboratorio, consulta el informe de Core Web Vitals en Google Search Console y la sección de campo de CrUX en PageSpeed Insights.

Hábitos de Lighthouse que crean falsa confianza

• Perseguir 100 como objetivo empresarial. Una puntuación perfecta de laboratorio no es un impulso de posicionamiento y puede distraer de los Core Web Vitals de campo y de los resultados reales de los usuarios. Usa el informe para encontrar cuellos de botella y luego verifica que los usuarios se beneficiaron.
• Tratar una sola ejecución como un veredicto. Lighthouse es una prueba simulada y varía de forma natural. Ejecútalo varias veces en las mismas condiciones y busca un patrón consistente en lugar de reaccionar ante una sola puntuación.
• Llamar al TBT de laboratorio lo mismo que al INP de campo. El TBT es un proxy de laboratorio útil para el bloqueo del hilo principal; el INP mide interacciones reales en el campo. Un buen TBT es evidencia, no prueba, de que el INP es bueno.
• Corregir cada auditoría en el orden listado. Las estimaciones de oportunidades se superponen, y algunas auditorías tienen poco impacto en el cuello de botella real de la página. Empieza con el trace, las métricas ponderadas más grandes y los recursos responsables de ellas.
• Comparar puntuaciones de móvil y escritorio directamente. Sus perfiles de emulación y distribuciones de puntuación difieren. Compara lo similar con lo similar.

Cambios en la puntuación de Lighthouse entre ejecuciones

Síntoma: La misma página se mueve entre bandas de color sin un despliegue.

Causa probable: Respuesta variable del servidor, scripts de terceros, carga compartida de la máquina, o diferentes ajustes de prueba cambiaron la ejecución sintética.

Corrección y confirmación: Iguala la URL, el perfil de dispositivo, la limitación, el estado de caché y la ubicación de prueba; ejecuta varias pruebas; luego compara el trace mediano y los tiempos de las métricas.

Los Core Web Vitals de campo pasan pero Lighthouse está en rojo

Síntoma: Los datos de campo de PSI pasan mientras la puntuación de rendimiento de Lighthouse es deficiente.

Causa probable: Las dos secciones miden poblaciones diferentes: CrUX resume usuarios reales a lo largo del tiempo, mientras que Lighthouse ejecuta una carga de página simulada.

Corrección y confirmación: Trata la evaluación de campo como el resultado del usuario y usa el trace de laboratorio para reproducir y diagnosticar un escenario de dispositivo lento. Confirma cualquier corrección tanto en las ejecuciones de laboratorio repetidas como en la siguiente ventana de informes de datos de campo.

Lighthouse no puede medir el INP

Síntoma: El informe muestra TBT pero ningún valor de INP de laboratorio.

Causa probable: El INP requiere interacciones reales durante una visita a la página; una ejecución de Lighthouse solo de navegación no tiene un historial de interacciones representativo.

Corrección y confirmación: Usa el TBT y el trace para encontrar tareas largas en el laboratorio, luego mide el INP con datos de campo o una grabación centrada en interacciones.

Una auditoría persiste después de la corrección obvia

Síntoma: Lighthouse sigue marcando un recurso después de que se optimizó o eliminó.

Causa probable: Una respuesta en caché, otra plantilla, una copia de terceros o una solicitud diferente en la cadena aún activa la auditoría.

Corrección y confirmación: Prueba la URL desplegada exacta con una caché fría, abre la lista de recursos afectados de la auditoría y asigna cada solicitud listada a su propietario.

Ponte a prueba: Google Lighthouse

Cinco preguntas rápidas sobre datos y puntuación de Lighthouse. Elige una respuesta para cada una y luego compruébalo.

Recursos que valen tu tiempo

Oficial

• Descripción general de Lighthouse — la guía definitiva sobre qué es, cómo funciona y dónde ejecutarlo.
• Puntuación de rendimiento de Lighthouse — pesos, bandas y la curva de puntuación.
• Documentación de limitación de Lighthouse (GitHub) — las condiciones de laboratorio en detalle.
• Calculadora de puntuación de Lighthouse — ingienería inversa de los objetivos de métricas para una puntuación.
• Métricas de rendimiento centradas en el usuario — el argumento de laboratorio frente a usuarios reales, de Google.

Dónde encaja Lighthouse

• Combina la puntuación de laboratorio con datos de campo: el informe de Core Web Vitals en Google Search Console y la sección CrUX de PageSpeed Insights. El laboratorio encuentra los problemas; el campo te dice si los usuarios reales los sienten.

De la industria

• Diferencias entre datos de campo y datos de laboratorio (web.dev) — el propio desglose de Google sobre cuándo confiar en los números de laboratorio frente a los de campo y por qué divergen.
• Core Web Vitals (web.dev) — la referencia canónica sobre qué métricas de CWV puede y no puede medir Lighthouse, incluida la brecha de INP.
• Largest Contentful Paint (web.dev) — análisis profundo de los umbrales de LCP y por qué las lecturas de laboratorio y de campo frecuentemente difieren.
• Lighthouse CI en GitHub — repositorio oficial y guía de configuración para integrar Lighthouse en pipelines de CI/CD automatizados.
• HTTP Archive Web Almanac — Capítulo de rendimiento — datos anuales sobre puntuaciones de Lighthouse en el mundo real y tasas de aprobación de Core Web Vitals en millones de páginas; útil para comparar tus puntuaciones con la web en general.
• web.dev — Medir el rendimiento de la página — el punto de partida recomendado por Google para combinar los resultados de Lighthouse con herramientas de datos de campo.

Números que vale la pena citar

• Pesos de la puntuación de rendimiento (Lighthouse 10): TBT 30 %, LCP 25 %, CLS 25 %, FCP 10 %, Speed Index 10 %. Fuente
• Bandas de puntuación: 0–49 rojo (pobre), 50–89 naranja (necesita mejoras), 90–100 verde (bueno). Un 90 corresponde aproximadamente al percentil 8 de los datos de HTTP Archive; un 50 al percentil 25. Fuente
• Limitación predeterminada: móvil Slow 4G (~150 ms de latencia, ~1,6 Mbps de bajada) más un multiplicador de CPU de 4× — emulando aproximadamente la conexión móvil del percentil 85. Fuente
• Categorías: cuatro hoy (Performance, Accessibility, Best Practices, SEO) — PWA eliminada en Lighthouse 12 (~2024). Fuente

Registro de cambios