Guía Práctica de Core Web Vitals

Qué miden realmente los scores

Core Web Vitals son tres métricas: LCP (Largest Contentful Paint — qué tan rápido la página parece cargada), CLS (Cumulative Layout Shift — qué tan estable es el layout), e INP (Interaction to Next Paint — qué tan responsive es la página a las interacciones).

Un score de Lighthouse es una mezcla ponderada de estas métricas y algunas secundarias. Pero en la práctica, arreglar LCP y CLS representa el 80% de la mejora en la mayoría de los sitios.

LCP: el problema de las imágenes

El elemento LCP casi siempre es la imagen del hero o el bloque de texto más grande por encima del fold. Para imágenes, el arreglo es casi siempre el mismo: usar un formato moderno (WebP o AVIF), precargar la imagen LCP, y dimensionarla correctamente para que el navegador no descargue una imagen de 3000px para un slot de 400px.

// Precargar la imagen LCP en Next.js
<Image
  src="/hero.jpg"
  priority       // agrega <link rel="preload">
  sizes="100vw"
  fill
  alt="Imagen hero"
/>

LCP: el problema de las fuentes

Las fuentes web bloquean el renderizado del texto LCP. La solución es preconnect al proveedor de fuentes, usar font-display: swap, y — si es posible — hostear la fuente localmente para controlar los headers de caché.

• Agregá <link rel="preconnect"> para el origen de la fuente
• Usá font-display: optional si el layout shift del swap es visible
• Hosteo propio vía next/font/google que inlinea el @font-face en build time
• Hacé subset de la fuente a solo los caracteres que usás

CLS: reservar espacio para contenido async

Los layout shifts ocurren cuando el contenido carga de forma asíncrona y empuja otros elementos. El arreglo es siempre reservar espacio antes de que llegue el contenido — establecer width y height explícitos en imágenes, usar min-height en slots de anuncios, y evitar insertar contenido sobre el fold después de la carga.

El problema de JS que bloquea el render

Los scripts de terceros (analytics, widgets de chat, A/B testing) son el mayor culpable del render-blocking. Cargalos con strategy="lazyOnload" en el componente Script de Next.js, o deferirlos hasta después de la primera interacción del usuario.

La performance no es una auditoría de una sola vez. Es una restricción que diseñás desde el principio. Agregarla después es un orden de magnitud más caro que incorporarla desde el inicio.