Cómo lograr Lighthouse 95 o más en tu sitio web: guía técnica

Quién escribe esto: Stratus, un estudio que vende diseño web y SEO técnico. Las reglas de Google y de Lighthouse van con su fuente; las recomendaciones son nuestras y lo decimos.

Antes de optimizar, dos aclaraciones que ahorran tiempo y plata:

1. El puntaje de Lighthouse no es lo que Google usa para posicionar. Google usa Core Web Vitals medidos con visitas reales. Lighthouse es una prueba de laboratorio que sirve para encontrar problemas.
2. Core Web Vitals cuentan, pero no deciden solos. Google dice que sus sistemas de ranking los usan, que un buen resultado no garantiza las primeras posiciones y que buscar un puntaje perfecto solo por SEO puede no ser el mejor uso de tu tiempo (Google Search Central, experiencia de página, actualizada el 22-09-2026).

Con eso claro, un buen puntaje sigue valiendo la pena: un sitio rápido y estable es mejor para quien lo visita, sobre todo desde un celular con mala señal.

Qué mide Lighthouse

Lighthouse revisa cuatro categorías y le pone a cada una un puntaje de 0 a 100: Rendimiento, Accesibilidad, Prácticas recomendadas y SEO. En rendimiento, de 90 a 100 es verde.

El puntaje de rendimiento (Lighthouse 10) se calcula con cinco métricas de laboratorio:

Métrica	Peso
Total Blocking Time (TBT)	30%
Largest Contentful Paint (LCP)	25%
Cumulative Layout Shift (CLS)	25%
First Contentful Paint (FCP)	10%
Speed Index	10%

El puntaje cambia entre una corrida y otra. Según la documentación de Lighthouse, buena parte de esa variación no viene de la herramienta sino de las condiciones: red, dispositivo, extensiones del navegador, anuncios o pruebas A/B. Por eso conviene correrlo varias veces y mirar la tendencia.

Fuente: Chrome for Developers, cómo se calcula el puntaje de rendimiento.

Los tres Core Web Vitals y otras métricas

Core Web Vitals son tres: LCP, INP y CLS. Se miden en el percentil 75 de las visitas reales, por separado en celular y en escritorio. Las demás métricas de esta lista ayudan a diagnosticar, pero no son Core Web Vitals.

LCP: Largest Contentful Paint (Core Web Vital)

Qué mide: cuánto tarda en aparecer el elemento más grande de la primera pantalla, normalmente la imagen principal o el título.

Umbrales: bueno, 2,5 s o menos; deficiente, sobre 4 s.

Qué lo empeora: imagen principal pesada, fuentes que bloquean el texto, CSS o JavaScript que bloquean el dibujo de la página y un servidor lento.

INP: Interaction to Next Paint (Core Web Vital)

Qué mide: cuánto tarda la página en reaccionar a un clic, un toque o una tecla. Reemplazó a FID el 12 de marzo de 2024.

Umbrales: bueno, 200 ms o menos; deficiente, sobre 500 ms.

Ojo: Lighthouse no puede medir INP, porque en el laboratorio nadie hace clic. Su mejor indicador es TBT.

Qué lo empeora: JavaScript pesado en el hilo principal, manejadores de eventos lentos y widgets de terceros (chats, mapas de calor, píxeles de publicidad).

CLS: Cumulative Layout Shift (Core Web Vital)

Qué mide: cuánto se mueven los elementos mientras la página carga.

Umbrales: bueno, 0,1 o menos; deficiente, sobre 0,25.

Qué lo empeora: imágenes sin ancho y alto, anuncios o banners que aparecen tarde y empujan el contenido, y fuentes que cambian de tamaño al cargar.

TTFB: Time to First Byte

Qué mide: cuánto tarda el servidor en empezar a responder.

Umbrales: bueno, 0,8 s o menos; deficiente, sobre 1,8 s.

Qué lo empeora: hosting compartido lento, páginas que se generan con consultas a la base de datos en cada visita y un servidor lejos de tus usuarios.

FCP: First Contentful Paint

Qué mide: cuándo aparece el primer texto o imagen.

Umbrales: bueno, 1,8 s o menos; deficiente, sobre 3 s.

TBT: Total Blocking Time

Qué mide: cuánto tiempo estuvo bloqueado el hilo principal por tareas largas de JavaScript durante la carga.

Umbrales en Lighthouse (celular): bueno, 200 ms o menos; deficiente, sobre 600 ms.

Fuentes: web.dev, Core Web Vitals (actualizada el 31-10-2024), LCP, INP, CLS, TTFB y FCP; registro de cambios de Google Search Central (12-03-2024, INP reemplaza a FID).

Lo primero que conviene hacer

Optimizaciones que casi cualquier sitio puede aplicar. Cuánto mejora cada una depende de tu punto de partida: mide antes y después.

1. Imágenes livianas y en formatos modernos

• Convierte JPEG y PNG a AVIF o WebP.
• Sirve varios tamaños con srcset, para que un celular no descargue la imagen de escritorio.
• loading="lazy" en las imágenes que están bajo la primera pantalla.
• En la imagen principal: loading="eager" y fetchpriority="high".

Mueve: LCP.

2. Fuentes que no bloqueen el texto

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

Usa font-display: swap y, si puedes, sirve las fuentes desde tu propio dominio y solo con los caracteres que usas.

Mueve: FCP, LCP y a veces CLS.

3. JavaScript que no es crítico, después

• defer o async en los <script>.
• Analítica y píxeles cargados después de la carga principal.
• Chats y widgets de terceros cargados cuando el usuario interactúa.

Mueve: TBT en laboratorio e INP con usuarios reales.

4. CSS que no se usa, fuera

• Revisa con Chrome DevTools, pestaña Coverage.
• Saca el CSS de plugins o librerías que no usas.
• El CSS crítico de la primera pantalla puede ir en línea.

Mueve: FCP y LCP.

5. Una red de distribución (CDN)

Servir el sitio desde servidores cerca del usuario baja el TTFB. Cloudflare, Vercel y Netlify sirven sitios estáticos desde su red; un WordPress también puede ponerse detrás de Cloudflare con caché.

Mueve: TTFB y, con eso, todo lo demás.

Optimizaciones avanzadas

Sacar lo que bloquea el primer dibujo

Lo ideal es que el HTML que llega primero ya se pueda mostrar, sin esperar archivos externos: CSS crítico en línea y el resto diferido, fuentes con swap, JavaScript no crítico con defer y prioridad alta en la imagen principal.

Prioridad de la imagen principal

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

Le dice al navegador que esa imagen va primero, antes que otros scripts e imágenes.

Service Worker

En sitios con visitas recurrentes, un service worker puede servir archivos desde la caché del navegador. Cuidado: mal configurado, sirve contenido viejo.

HTTP/3 y Brotli

Protocolos y compresión modernos. Las redes de distribución actuales los ofrecen; revisa si tu hosting los tiene activados.

Avisarle al navegador lo que viene

<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">

Accesibilidad

• Texto alternativo en las imágenes que comunican algo.
• Contraste de al menos 4,5:1 para texto normal y 3:1 para texto grande (WCAG 2.1, nivel AA).
• Cada campo de formulario con su <label>.
• Encabezados en orden, sin saltar de H1 a H4.
• Foco visible en enlaces y botones (nunca outline: none sin reemplazo).

SEO

• Un <title> único y descriptivo por página.
• Una meta description única por página.
• robots.txt correcto y el sitemap declarado en él.
• HTTPS en todo el sitio.
• Viewport para celular y diseño adaptable.
• Idioma declarado en <html lang>.
• Datos estructurados válidos (Organization, WebPage y los que correspondan a tu negocio).

Prácticas recomendadas

• HTTPS sin contenido mixto.
• Consola sin errores.
• Sin APIs obsoletas.
• Imágenes con su proporción correcta.
• Permisos (notificaciones, ubicación) solo cuando el usuario hace algo que los pide.

Por qué WordPress suele costar más en Lighthouse

Hay sitios en WordPress con muy buen puntaje, pero exigen trabajo y mantención. Las razones son estructurales:

1. Páginas generadas en el servidor en cada visita, salvo que haya caché.
2. Cada plugin puede sumar CSS y JavaScript a todas las páginas.
3. Temas multipropósito pesados, que cargan funciones que el sitio no usa.
4. Hosting compartido, con tiempos de respuesta variables.

Optimizarlo suele requerir un mejor hosting, un plugin de caché y optimización, y sacar lo que sobra. Si estás evaluando cambiar de tecnología, lo comparamos en WordPress vs Astro.

Herramientas para medir

Lighthouse en Chrome DevTools: F12, pestaña Lighthouse. Córrelo en una ventana de incógnito y en modo celular.

PageSpeed Insights (pagespeed.web.dev): Lighthouse más los datos de campo de Chrome (CrUX), cuando la URL tiene tráfico suficiente. Los datos de campo valen más que el puntaje.

WebPageTest (webpagetest.org): pruebas más detalladas, desde distintas ubicaciones y conexiones.

Chrome DevTools, pestaña Performance: para ver qué hace el hilo principal en cada momento.

Search Console, informe de Core Web Vitals: los datos reales de tus usuarios, agrupados por URL.

Cómo trabajamos en Stratus

Construimos con Astro y servimos los sitios desde la red de Cloudflare: HTML generado de antemano, JavaScript solo donde hace falta e imágenes optimizadas al publicar. El SEO técnico va incluido en todos los planes.

Si tu sitio actual tiene métricas en rojo, podemos auditarlo y darte un plan priorizado. Es parte de nuestro servicio de SEO técnico: auditoría desde $390.000 + IVA e implementación de $890.000 a $1.900.000 + IVA, según el tamaño del sitio.

Para conversar sobre tu caso, escríbenos por WhatsApp. Te decimos si conviene optimizar lo que tienes o rehacerlo.