Cómo lograr Lighthouse 95+ en tu sitio web: guía técnica completa

Google usa Core Web Vitals como factor de ranking directo desde 2021. Un sitio con Lighthouse score bajo 60 prácticamente no aparece en búsquedas competitivas, por más buen contenido que tenga. Esta guía técnica explica cómo llegar a Lighthouse 95+ consistentemente, qué optimizaciones mueven la aguja realmente y cuáles son ruido de developer.

La escribimos pensando en dueños de empresa que quieren entender el problema, y en developers que necesitan checklist accionable. Si tu rol es solo decidir si invertir o no en optimización, leé las primeras dos secciones. Si vas a implementar, leé todo.

Por qué Lighthouse importa para tu negocio

Lighthouse es la herramienta oficial de Google que mide cuatro dimensiones de tu sitio web: Performance (velocidad), Accessibility (accesibilidad), Best Practices (buenas prácticas web), SEO (factores SEO técnico). Cada dimensión recibe score 0-100.

El impacto comercial real de estos scores:

• Tasa de conversión: cada segundo de carga adicional reduce conversión 7-10% según múltiples estudios (Akamai, Google, Amazon)
• Posicionamiento orgánico: sitios con Core Web Vitals en verde rankean en promedio 24% mejor (BrightEdge, 2023)
• Bounce rate móvil: 53% de usuarios abandonan sitios que tardan más de 3 segundos en cargar (Google, 2018, sigue vigente)
• Costo de adquisición: sitios lentos requieren ~30% más inversión en SEM para compensar tráfico orgánico perdido

Para una PyME chilena que invierte $500.000/mes en marketing digital, mejorar Lighthouse de 50 a 95 puede significar $1.5M-$3M anuales en tráfico orgánico recuperado. El ROI es claro.

Los 6 Core Web Vitals que decide Google

Lighthouse 10+ usa estas métricas para calcular Performance. Conocerlas es prerequisito para optimizar.

LCP — Largest Contentful Paint

Qué mide: tiempo desde que el usuario solicita la página hasta que se renderiza el elemento más grande visible (típicamente la imagen hero o título principal).

Targets: bueno < 2.5s, necesita mejora 2.5-4s, malo > 4s.

Cómo se rompe típicamente: imágenes hero sin optimizar (4-8 MB), fuentes web cargadas con FOUT bloqueante, CSS bloqueante, JavaScript bloqueante que demora render.

INP — Interaction to Next Paint (reemplazó FID en 2024)

Qué mide: tiempo desde que el usuario hace clic/tap hasta que la página responde visualmente.

Targets: bueno < 200ms, necesita mejora 200-500ms, malo > 500ms.

Cómo se rompe: JavaScript pesado bloqueando el main thread, event handlers ineficientes, dependencias de terceros (Hotjar, Intercom widgets).

CLS — Cumulative Layout Shift

Qué mide: cuánto se mueven los elementos del layout mientras carga la página. Una página que “salta” durante la carga frustra al usuario.

Targets: bueno < 0.1, necesita mejora 0.1-0.25, malo > 0.25.

Cómo se rompe: imágenes sin dimensiones declaradas, anuncios que cargan tarde y empujan contenido, web fonts con FOIT (Flash of Invisible Text), banners que aparecen tarde.

TTFB — Time to First Byte

Qué mide: tiempo desde que el navegador hace request hasta recibir el primer byte de respuesta del servidor.

Targets: bueno < 800ms, malo > 1800ms.

Cómo se rompe: hosting compartido lento, base de datos sin indexar (típico WordPress), región de servidor lejana al usuario.

FCP — First Contentful Paint

Qué mide: tiempo hasta que aparece el primer contenido visible (texto o imagen). Diferente de LCP que mide el más grande.

Targets: bueno < 1.8s, malo > 3s.

TBT — Total Blocking Time

Qué mide: cuánto tiempo total el main thread estuvo bloqueado por JavaScript ejecutándose.

Targets: bueno < 200ms, malo > 600ms.

Quick wins (5-15% de mejora en 1 día)

Optimizaciones que cualquier sitio puede implementar y mueven la aguja inmediatamente.

1. Comprimir imágenes y servir formatos modernos

El error más común en sitios chilenos: imágenes JPEG 4-8 MB cuando podrían ser AVIF 200-400 KB con calidad equivalente.

Acción concreta:

• Convertí JPEG/PNG a AVIF (calidad 80) o WebP (calidad 85)
• Servir múltiples tamaños con srcset
• Lazy loading nativo: loading="lazy" en <img> debajo del fold
• Para hero: loading="eager" + fetchpriority="high"

Impacto típico: LCP baja 30-60%, score Performance +10-20 puntos.

2. Preload de fuentes críticas

Las fuentes web tardan en cargar y bloquean texto visible. Sitios con Google Fonts típicos pierden 1-2 segundos por esto.

Acción concreta:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" href="ruta-fuente.woff2" as="font" type="font/woff2" crossorigin>

Impacto típico: FCP baja 200-500ms, CLS mejora si tenías FOIT.

3. Defer JavaScript no crítico

Scripts de analytics, chat widgets, social plugins típicamente cargan bloqueando. Cargarlos después del LCP mejora todo.

Acción concreta:

• Usar defer o async en <script>
• Cargar Google Analytics con gtag.js configurado en delay
• Chat widgets (Intercom, HubSpot) cargar después de 3s o on user interaction

Impacto típico: TBT baja 30-70%, INP mejora significativamente.

4. Eliminar CSS no usado

Sitios WordPress típicos cargan 200-500 KB de CSS donde se usa el 10-20%. Bootstrap completo, theme styles, plugin styles.

Acción concreta:

• Auditar con Chrome DevTools → Coverage
• Eliminar CSS de plugins no usados
• Critical CSS inline para above-the-fold

Impacto típico: FCP -200ms, score Performance +5-10.

5. CDN con edge caching

Servir desde edge geográficamente cerca del usuario. Cloudflare (gratis) o CloudFront baja TTFB dramáticamente.

Acción concreta:

• Configurar Cloudflare Pages, Vercel o Netlify (todos con CDN edge)
• Para WordPress: Cloudflare proxy con caching aggressive

Impacto típico: TTFB baja 50-80%, especialmente para usuarios fuera de la región del servidor.

Optimizaciones avanzadas (15-30% adicional)

Estas requieren más trabajo pero llevan de Lighthouse 75-85 a 95+.

Eliminar render-blocking resources

Identificar y eliminar todo lo que bloquea el primer render. Idealmente, el primer byte que el navegador recibe ya tiene HTML renderizable, sin esperar nada externo.

• CSS crítico inline (resto async)
• Fuentes preloaded con display=swap
• JS no crítico defer/async
• Imágenes hero con priority hint

Image priority hints

Para LCP, el navegador necesita saber qué imagen priorizar. Por defecto carga en orden DOM, no por importancia visual.

<img src="hero.avif" alt="..." fetchpriority="high" />

Esto le dice al navegador “esta imagen es crítica, descargala primero, antes de scripts y otras imágenes”.

Service Worker + caching strategy

Para sitios con visitas recurrentes, service worker permite servir desde cache local sin pedir al servidor. Visitas 2-N cargan en 100-300ms.

Cuidado: requiere mantenimiento. Service workers mal configurados sirven contenido obsoleto.

HTTP/3 + Brotli

Protocolos modernos comprimen mejor y cargan en paralelo. Cloudflare, Vercel y Netlify los activan por defecto. Hosting tradicional muchas veces no.

Critical resource hints

<link rel="dns-prefetch" href="https://api.tu-servicio.com">
<link rel="preconnect" href="https://cdn.tu-imagenes.com">
<link rel="preload" href="hero-image.avif" as="image" fetchpriority="high">

Le dis al navegador con anticipación qué va a necesitar, para empezar a resolverlo en paralelo con el parsing HTML.

Optimizaciones de Accessibility (llegar a 100)

Performance es el más visible pero los otros tres también importan para Lighthouse 95+ global.

Accessibility quick wins:

• Alt text en todas las imágenes (descriptivo, no genérico)
• Contraste de texto mínimo 4.5:1 para texto normal, 3:1 para texto grande
• Forms con <label> asociado por for o nested
• Headings jerárquicos (no saltar de H1 a H4)
• ARIA roles donde aplique
• Focus visible en elementos interactivos (no outline: none sin reemplazo)

Optimizaciones de SEO (llegar a 100)

SEO quick wins:

• <title> único 50-60 caracteres por página
• <meta name="description"> único 150-160 caracteres
• Schema markup básico (Organization, WebPage)
• Robots.txt presente y correcto
• Sitemap.xml referenciado en robots
• HTTPS obligatorio (Cloudflare lo provee gratis)
• Mobile-friendly (viewport meta, responsive layout)
• lang declarado en <html>

Optimizaciones de Best Practices (llegar a 100)

Best Practices:

• HTTPS sin mixed content
• Console errors limpios (no errors visibles)
• Sin uso de APIs deprecated
• Imágenes con aspect ratio correcto (no aspect ratio mismatch)
• Notificaciones push solo on user gesture

Por qué WordPress típicamente falla en Lighthouse

Algunos sitios WordPress alcanzan Lighthouse 90+, pero requieren expertise y mantenimiento constante. La razón estructural:

1. Stack PHP + MySQL en cada request — server-side rendering en cada carga, no estático
2. Plugins acumulados, cada plugin agrega CSS/JS adicional
3. jQuery dependency — WP carga jQuery por defecto (90KB) aunque no se use
4. Theme bloat — temas premium tipo Avada/Divi cargan 500KB-2MB de assets
5. Hosting compartido típico — TTFB de 1-3 segundos en hostings populares chilenos

Optimizar WordPress a 95+ requiere: hosting premium, plugins pagos de optimización (WP Rocket, Perfmatters), eliminación quirúrgica de assets innecesarios, expertise técnico. Costo total típico: $200K-$500K iniciales + mantenimiento.

Sitios construidos con Astro u otros frameworks modernos llegan a 95+ por defecto sin esfuerzo adicional. Este es uno de los argumentos para migrar de WordPress a stack moderno.

Herramientas reales para auditar

Lighthouse en Chrome DevTools — F12 → Lighthouse tab → Run audit. Ejecutalo en modo incógnito para evitar interferencia de extensiones. Hacelo en modo móvil simulado, no desktop, porque Google indexa con mobile-first.

PageSpeed Insights (pagespeed.web.dev) — Lighthouse + Real User Metrics (Chrome User Experience Report). Las métricas RUM son más útiles que Lighthouse de laboratorio porque muestran lo que usuarios reales experimentan.

WebPageTest (webpagetest.org) — Más profundo que Lighthouse. Permite testear desde diferentes ubicaciones geográficas (importante para sitios chilenos: testear desde Santiago y Antofagasta da resultados distintos).

Chrome DevTools Performance tab — Cuando ya optimizaste y quieres ir al siguiente nivel. Permite ver cada operación del main thread.

Search Console — Core Web Vitals report — Datos reales de tus usuarios actuales. Te dice qué páginas específicas tienen problemas, no solo el promedio.

Cómo lo hacemos en Stratus

Todos los sitios que entregamos llegan a Lighthouse 95+ por contrato. La metodología:

1. Stack moderno por default — Astro 5 + Cloudflare Pages elimina 80% de los problemas estructuralmente.
2. Imágenes optimizadas en build — pipeline automatizado que genera AVIF/WebP en múltiples tamaños desde el master.
3. Fuentes con preload + subsetting, solo cargamos los caracteres realmente usados.
4. JS mínimo — Astro envía solo lo necesario. Promedio: 30-80 KB de JS por página vs WordPress típico 500KB-2MB.
5. Lighthouse audit pre-deploy — bloqueamos deploy si algún score baja de 95.

Si tu sitio actual no llega a Lighthouse 95+, podemos auditarlo y darte plan de acción priorizado. Es parte de nuestro servicio de SEO técnico — auditoría inicial desde $390.000 CLP, implementación de mejoras desde $890K según alcance.

Para conversar sobre tu caso específico, escríbenos por WhatsApp. Briefing en 15 minutos, te decimos honestamente si vale la pena optimizar o si conviene migrar a stack moderno.