Auditoría Lighthouse 100: el checklist real que uso antes de dar un proyecto por cerrado
La lista de comprobación técnica que reviso en cada proyecto de cliente antes de entregarlo, para acercarme al máximo real de Lighthouse en las cuatro categorías.
- #lighthouse
- #performance
- #checklist
- #seo
Antes de dar cualquier proyecto por cerrado, paso esta misma lista de comprobación. No es teoría — es literalmente lo que reviso proyecto a proyecto, y lo que explica por qué casi todos entregan con puntuaciones muy altas en Lighthouse de salida.
Performance
Fuentes con next/font, sin llamada externa a Google Fonts en producción. Imágenes con next/image (o el loader de Cloudflare equivalente), siempre con width y height explícitos. priority solo en la imagen above-the-fold, nunca en toda la página. JavaScript de terceros (analítica, chats) cargado de forma diferida tras el idle del navegador, nunca bloqueando el hilo principal en el primer render.
Accesibilidad
Contraste de color verificado con las variables del sistema de diseño, no a ojo. aria-label en todo botón que solo lleva icono. Jerarquía de encabezados sin saltos (un h1 por página, h2 y h3 en orden). focus-visible consistente en todos los elementos interactivos, no solo en los que el navegador resalta por defecto.
Mejores prácticas
Cabeceras de seguridad (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options) configuradas en next.config.ts, no solo en el proveedor de hosting. Sin errores de consola en producción. HTTPS forzado en todo el sitio.
SEO técnico
metadataBase correcto para que las imágenes OG resuelvan bien. Cada página con title y description únicos, nunca heredados del layout sin cambios. sitemap.ts y robots.ts generados dinámicamente. JSON-LD del tipo correspondiente al negocio (Person, Organization, LocalBusiness, Restaurant, Article) validado con el test de resultados enriquecidos de Google.
Por qué esto no siempre da exactamente 100
En redes simuladas lentas (Slow 4G) o dispositivos de gama muy baja, el LCP puede quedar unas décimas por encima del umbral incluso con todo lo anterior bien hecho, porque hay un suelo físico de latencia de red que ninguna optimización de código elimina. Cuando eso pasa, lo digo explícitamente en la entrega en vez de perseguir un 100 que dependería de condiciones de red que el usuario real no siempre tiene.
Conclusión
Un checklist repetible vale más que perseguir cada proyecto desde cero. Estas cuatro categorías, revisadas en este orden, son las que consistentemente llevan un proyecto Next.js a puntuaciones de producción altas — y cuando no llegan al máximo absoluto, el checklist también sirve para explicar exactamente por qué.
¿Construyendo algo?
Si esto te ha resonado, podemos hablar. Contactar →