Los Core Web Vitals son una señal de posicionamiento confirmada y, lo que es más importante, un factor de conversión. El trío actual:
- LCP (Largest Contentful Paint): el contenido principal visible en < 2,5 s. Solución: estático/ISR,
priorityen la imagen hero, el mínimo de CSS bloqueante, un TTFB rápido (vea la estrategia de renderizado). - INP (Interaction to Next Paint): sustituyó al FID en marzo de 2024; cada interacción debe responder en < 200 ms. Solución: menos scripts externos y cargados de forma diferida, bundles de cliente más pequeños (
"use client"solo donde haga falta), dividir las tareas largas. - CLS (Cumulative Layout Shift): < 0,1. Solución: dimensiones en todas las imágenes/embeds, espacio reservado para los banners,
next/font(sin saltos al cambiar la fuente).
Mida de dos maneras:
- En laboratorio: Lighthouse en CI (por ejemplo
@lhci/clien cada PR) detecta las regresiones antes del despliegue. - En campo: los datos de usuarios reales son sobre lo que Google posiciona realmente. Se conecta con un solo hook:
// app/web-vitals.tsx
"use client";
import { useReportWebVitals } from "next/web-vitals";
export function WebVitals() {
useReportWebVitals((metric) => {
// enviamos a la analítica propia
navigator.sendBeacon("/api/vitals", JSON.stringify(metric));
});
return null;
}
Los datos de campo se consultan en Search Console → Core Web Vitals o en PageSpeed Insights (muestra CrUX cuando hay datos suficientes).
Checklist:
- LCP < 2,5 s, INP < 200 ms, CLS < 0,1 en datos de campo, no solo en Lighthouse
- Lighthouse CI o equivalente vigila las regresiones
-
useReportWebVitalsalimenta la analítica con métricas de usuarios reales - Móvil comprobado por separado: es donde fallan la mayoría de los sitios
