Auditoría de Rendimiento Web con Lighthouse y Core Web Vitals
Tu landing "se ve bien". Lighthouse dice que tus usuarios se van antes de que cargue el hero. El problema no es estético: una landing que tarda 5 segundos en pintar el LCP en 4G pierde al 53% de sus visitantes antes siquiera de ver tu propuesta de valor (Google Web.dev, 2024). Y esa métrica no la mide tu sensación de "el sitio carga rápido" en una Mac con fibra óptica. La mide un móvil Android de gama media en un pueblo con 3G inestable. La audiencia real.
Lighthouse es la herramienta open source de Google que te da ese diagnóstico honesto. Es gratis, se ejecuta local o en CI, y te devuelve un reporte con los cinco indicadores que importan: LCP, INP, CLS, TBT y FCP. Pero lo interesante no es correr Lighthouse una vez. Es integrarlo a tu pipeline de deploy para que cada pull request falle si el score baja de un umbral, antes de llegar a producción.
En este artículo aprenderás:
- Qué mide Lighthouse exactamente y por qué separar auditoría desktop de móvil cambia todas tus conclusiones
- Core Web Vitals explicados con thresholds reales para LCP, INP y CLS — los que Google usa como señal SEO
- Integrar Lighthouse CI en GitHub Actions con
budget.jsonpara bloquear PRs que degraden el performance - Cinco optimizaciones que suben el score rápido sin reescribir nada: preload de imágenes críticas, defer de scripts, compresión Brotli, reserved space para CLS y yield to main thread para INP
- Checklist que corremos en auditorías reales antes de aceptar un cliente de frontend
Qué mide Lighthouse y por qué desktop vs móvil no son lo mismo
Lighthouse audita cinco categorías: Performance, Accessibility, Best Practices, SEO y PWA. Cada una devuelve un score de 0 a 100. La que genera más preguntas y más errores de interpretación es Performance, porque depende fuertemente del entorno de medición.
Por defecto, Lighthouse corre dos perfiles distintos: mobile (emulando un Moto G4 con throttling de 4G lento y CPU 4× más lenta que el host) y desktop (sin throttling, resolución 1350×940). Los scores entre ambos perfiles pueden diferir en 30-40 puntos. Un sitio con 95 en desktop puede estar en 42 en mobile. Y el 60% del tráfico mexicano es móvil (INEGI ENDUTIH 2024), así que el score desktop es la conversación cómoda y el mobile es la realidad.
La métrica compuesta de Performance se calcula con pesos específicos:
- LCP (Largest Contentful Paint): 25% del score. Tiempo hasta pintar el elemento más grande en el viewport (típicamente el hero, una imagen o un bloque de texto).
- TBT (Total Blocking Time): 30%. Tiempo total que el main thread estuvo bloqueado más de 50ms durante la carga.
- CLS (Cumulative Layout Shift): 25%. Cuánto "saltó" visualmente la página mientras cargaba.
- FCP (First Contentful Paint): 10%. Cuándo se pintó el primer pixel con contenido real.
- Speed Index: 10%. Qué tan rápido se rellena visualmente el viewport.
INP (Interaction to Next Paint) reemplazó a FID como Core Web Vital oficial en marzo de 2024. Lighthouse lo reporta como diagnóstico aunque no entra directamente en el score numérico.
Corres Lighthouse en tu laptop y te da 92. Corres PageSpeed Insights (que también es Lighthouse) y te da 54. ¿Cuál es el real? PageSpeed usa datos de CrUX (Chrome User Experience Report) que son del tráfico real de tus usuarios. Tu laptop es un best-case escenario. Para decisiones serias, confía en PageSpeed y en Lighthouse CI, no en la extensión del navegador.
Core Web Vitals con thresholds reales
Los Core Web Vitals son tres métricas específicas que Google usa como señal de ranking SEO desde 2021. No pasar los umbrales de "Good" en estas tres métricas te cuesta posiciones en resultados de búsqueda, independientemente de la calidad de tu contenido.
| Métrica | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
LCP mide cuándo el usuario ve "algo grande". Si tu hero es una imagen de 800KB sin preload, vas a fallar aunque tu HTML sea mínimo. La optimización clásica es <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> en el <head>, convertir el hero a formato WebP o AVIF, y servir versiones responsivas con srcset.
INP mide cuánto tarda el navegador en responder al primer click, tap o teclazo. Reemplazó a FID porque FID solo medía la primera interacción; INP mide la peor interacción durante toda la sesión. Es el Core Web Vital más subestimado: una página puede cargar en 1.5s (LCP excelente) pero si al hacer click en un botón el framework corre 400ms de JavaScript bloqueante antes de responder, el INP te tumba.
CLS mide cuánto "salta" el layout. El caso clásico es un anuncio o banner que aparece después del texto y empuja el contenido hacia abajo mientras el usuario ya está leyendo. Se corrige reservando el espacio con min-height o aspect-ratio en CSS antes de que el contenido dinámico cargue. Es el más fácil de arreglar cuando lo identificas.
Instalar Lighthouse y correr el primer reporte
Lighthouse se distribuye como CLI npm, extensión de Chrome integrada en DevTools, y como paquete node para integración programática. Para auditoría manual rápida:
npm install -g lighthouse
lighthouse https://tu-sitio.com --preset=desktop --view
lighthouse https://tu-sitio.com --form-factor=mobile --throttling.cpuSlowdownMultiplier=4 --view
El flag --view abre el reporte HTML en el navegador al terminar. El reporte incluye screenshots del rendering a intervalos de 500ms, trace del main thread, y recomendaciones específicas con estimación de segundos que ahorrarías al aplicarlas.
Para auditar varias URLs del sitio (no solo la home), útil para detectar que tu landing esté bien pero el blog se caiga:
lighthouse https://meeplab.com --output=json --output-path=./reports/home.json
lighthouse https://meeplab.com/blog --output=json --output-path=./reports/blog.json
lighthouse https://meeplab.com/contacto --output=json --output-path=./reports/contacto.json
El output JSON es el que vamos a automatizar en CI. Un reporte típico pesa 500KB-2MB y contiene más detalle del que vas a revisar manualmente alguna vez.
¿Querés la auditoría corrida contra tu sitio real?
Agendá 30 minutos por Meet y corremos Lighthouse en vivo contra tu sitio. Salís con las 5 optimizaciones específicas que aplicaríamos primero y el workflow de CI listo para pegarlo a tu proyecto.
Agendar auditoría →Lighthouse CI en GitHub Actions con budget.json
Correr Lighthouse manual antes de cada deploy es sostenible una semana. Después se olvida, el score degrada PR por PR, y tres meses después descubres que el sitio bajó 20 puntos sin que nadie se enterara. La solución es automatizarlo en CI.
Lighthouse CI es un proyecto oficial de Google (Apache 2.0) que integra Lighthouse con CI y permite fallar el build si el score cae por debajo de un umbral. Usa un archivo de configuración llamado lighthouserc.json y opcionalmente un budget.json que define límites de tamaño y timing por tipo de recurso.
Primero la configuración:
{
"ci": {
"collect": {
"url": [
"http://localhost:3000/",
"http://localhost:3000/blog",
"http://localhost:3000/contacto"
],
"numberOfRuns": 3,
"settings": {
"preset": "desktop"
}
},
"assert": {
"preset": "lighthouse:no-pwa",
"assertions": {
"categories:performance": ["error", { "minScore": 0.85 }],
"categories:accessibility": ["error", { "minScore": 0.9 }],
"categories:seo": ["error", { "minScore": 0.9 }],
"largest-contentful-paint": ["warn", { "maxNumericValue": 2500 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}
Esto dice: "corre Lighthouse 3 veces contra estas 3 URLs, toma la mediana, y falla el build si performance mobile < 0.85 o CLS > 0.1". El target: temporary-public-storage sube el reporte a un servicio gratis de Google que guarda los HTML por 7 días.
El workflow de GitHub Actions:
# .github/workflows/lighthouse.yml
name: Lighthouse CI
on:
pull_request:
branches: [main]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run build
- run: npm run start &
- name: Wait for server
run: npx wait-on http://localhost:3000
- name: Run Lighthouse CI
run: |
npm install -g @lhci/cli@0.13.x
lhci autorun
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
GitHub Actions da 2,000 minutos gratis al mes para repos privados (ilimitado para públicos). Lighthouse CI contra 3 URLs con 3 corridas cada una toma ~3 minutos por PR. Es sostenible incluso en repos con 50 PRs por semana.
Performance budget: dónde poner el límite
Un budget.json define límites de tamaño por tipo de recurso y timing por métrica. Es el contrato entre ingeniería y performance: mientras respetes el budget, desplegás tranquilo.
[
{
"path": "/*",
"timings": [
{ "metric": "interactive", "budget": 3000 },
{ "metric": "first-contentful-paint", "budget": 1500 }
],
"resourceSizes": [
{ "resourceType": "script", "budget": 250 },
{ "resourceType": "image", "budget": 400 },
{ "resourceType": "stylesheet", "budget": 50 },
{ "resourceType": "total", "budget": 800 }
],
"resourceCounts": [
{ "resourceType": "third-party", "budget": 10 }
]
}
]
Los valores razonables para un sitio de marketing de una PyME: 250KB de JS, 400KB de imágenes, 800KB de total page weight, máximo 10 scripts de terceros. Si tu sitio ya está por encima, pon los números actuales como budget inicial y bájalos 10% cada mes. Lo importante no es el valor absoluto — es que no vuelva a subir.
Cinco optimizaciones que suben el score rápido
Estos son los cambios de alto impacto que aplicamos primero en cualquier auditoría. Ninguno requiere reescribir el sitio.
1. Preload del LCP. Identifica cuál es el LCP de cada página (Lighthouse lo reporta) y agrega un <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> en el <head>. Típicamente gana 400-800ms en LCP. Si tu hero es una imagen de fondo vía CSS, Lighthouse no la precarga automáticamente, por lo que este preload explícito es obligatorio.
2. Defer de scripts no críticos. Todo script de analytics, chat widgets, y pixeles de ads va con defer o mejor aún con carga diferida cuando el usuario interactúa. <script defer src="analytics.js"> difiere la ejecución hasta después del HTML parse pero antes del DOMContentLoaded. Gana TBT y INP.
3. Compresión Brotli. HTTP servers modernos (Nginx, Caddy, Cloudflare, Netlify) soportan Brotli, que comprime ~20% mejor que gzip. Si tu backend no lo tiene activado, habilítalo. Gana bytes transferidos y por ende LCP en conexiones lentas.
4. Reserved space para CLS. Cualquier elemento cuyo tamaño no se conoce al momento del render inicial (ads, embeds, fonts con FOUT, imágenes sin width/height) genera CLS. Para imágenes, siempre especifica width y height en HTML o usa aspect-ratio: 16 / 9 en CSS. Para embeds (YouTube, mapas), envuélvelos en un contenedor con dimensiones fijas. Gana CLS instantáneamente.
5. Yield to main thread para INP. Si tienes handlers que ejecutan 100+ ms de JS al hacer click (por ejemplo, filtrar una tabla grande), divide el trabajo con scheduler.yield() o setTimeout(0) para devolver el control al navegador y pintar la respuesta inmediata primero. Gana INP de manera dramática sin cambiar lógica.
"Una landing PyME que auditamos estaba en 42 de performance móvil. Aplicamos preload del hero, defer de dos scripts de terceros y reserved space para los embeds. Pasó a 87 en dos tardes. Cero reescritura, cero deploy riesgoso."
Checklist de auditoría antes de aceptar un cliente de frontend
Este es el checklist que corremos en la primera llamada técnica con un prospecto de performance. Si el sitio no pasa al menos 8 de 10 puntos, la conversación cambia de "optimizamos" a "refactor y deploy con CI nuevo".
- Lighthouse mobile Performance ≥ 70, aunque sea antes de cualquier intervención
- LCP mobile < 4s (umbral "Poor" de Google)
- CLS mobile < 0.25
- INP < 500ms en las interacciones principales
- Imágenes servidas en WebP o AVIF con
srcsetresponsivo - JS total < 500KB gzipped en la primera carga
- Máximo 3-5 scripts de terceros (analytics, chat, ads combinados)
- Compresión Brotli activa en el hosting
- HTTP/2 o HTTP/3 (no HTTP/1.1)
- CDN activo para assets estáticos
Los sitios que pasan todos los puntos raramente nos contratan: ya están bien. Los que fallan 5 o más son los que generan oportunidad de trabajo real. Conocer el checklist te sirve aunque no trabajes con nosotros: sabes exactamente qué pedirle a cualquier proveedor.
¿Tu landing pasa el checklist mobile?
Corrémosla en 30 minutos por Meet. Te mostramos el reporte Lighthouse en vivo, marcamos las 3 intervenciones de mayor impacto, y te dejamos el workflow de GitHub Actions listo para pegarlo a tu repo. Sin seguimiento invasivo, sin pitch de ventas.
Agendar auditoría técnica →Cuándo Lighthouse no es suficiente
Lighthouse mide lo que carga en un entorno sintético. No mide qué experimentan tus usuarios reales en sus condiciones. Para eso necesitas Real User Monitoring (RUM): datos de Core Web Vitals recolectados del tráfico real con web-vitals.js (librería OSS de Google, MIT) y enviados a tu backend o a Plausible/Umami.
La regla simple: Lighthouse CI bloquea regresiones en el pipeline. RUM detecta problemas que solo aparecen en dispositivos específicos, países con peor red, o browsers que tú no probaste. Los dos son complementarios, no sustitutos.
Para una PyME que arranca con esto, el orden correcto es: (1) Lighthouse CI en cada PR, (2) Lighthouse corrido contra las 3-5 páginas principales semanalmente en un cron, (3) RUM solo cuando el tráfico justifique los datos (≥ 10k sesiones/mes). Antes de eso, los números de RUM son ruido estadístico.
Conclusión
La performance web no es opcional en 2026. Es Core Web Vital, es señal SEO de Google, y es la diferencia entre un usuario que lee tu propuesta de valor y uno que se fue en el segundo 3. Lighthouse te da el diagnóstico gratis y preciso, y Lighthouse CI te deja bloquear regresiones antes de que lleguen a producción.
Lo que cubrimos:
- ✅ Qué mide Lighthouse y por qué mobile vs desktop cuentan cosas distintas
- ✅ Core Web Vitals con umbrales reales: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1
- ✅ Instalación CLI y primer reporte HTML
- ✅ Lighthouse CI en GitHub Actions con
budget.json - ✅ Cinco optimizaciones de alto impacto que suben el score sin reescribir
- ✅ Checklist de auditoría pre-cliente para calificar tu sitio
Tu Siguiente Paso
Si tu sitio cae debajo de 70 en Lighthouse mobile, vale la pena una revisión técnica de 30 minutos. Te mandamos el reporte, las 3 intervenciones de mayor impacto, y el workflow de CI para que no vuelva a bajar. Gratis, sin pitch.
Agendar auditoría Lighthouse →