El estado del arte, sin rodeos
Las Core Web Vitals dejaron de ser un debate académico y se convirtieron en una métrica de negocio. Google las usa como señal de ranking, los usuarios las sienten directamente en conversión y los equipos serios ya tienen budgets explícitos por página.
Las metas, al percentil 75 sobre datos de campo:
- LCP (Largest Contentful Paint) ≤ 2.5 s
- INP (Interaction to Next Paint) ≤ 200 ms
- CLS (Cumulative Layout Shift) ≤ 0.1
INP entró formalmente en marzo de 2024 reemplazando a FID y es hoy la más exigente: mide la latencia real de respuesta a clicks, taps y teclado, no solo el primero.
Lo que sí mueve la aguja
Para LCP: identifica el elemento LCP en cada plantilla (suele ser una imagen hero o un H1 con webfont), agrega fetchpriority="high" a la imagen y un <link rel="preload"> para la fuente que la dibuja. Sirve la imagen en AVIF/WebP y dimensiónala con width/height para evitar reflows.
Para INP: el principal villano es JavaScript en el main thread bloqueando interacciones. Reduce JS de terceros (analytics, chat, video) cargándolos vía Partytown o web workers. Para tu propio JS, evita state updates pesados en handlers; usa requestIdleCallback para trabajo no urgente.
Para CLS: reserva espacio para todo lo que carga después (imágenes, iframes, ads, web fonts con FOIT/FOUT, banners de cookies). font-display: swap con size-adjust apropiado evita el salto típico al cargar webfonts.
La diferencia entre rápido y percibido como rápido
Un sitio puede tener LCP de 2.0 s y sentirse lento si el botón principal tarda 400 ms en responder al click. Por eso INP importa tanto. Optimizar performance percibida es invertir en interactividad real, no solo en métricas de carga.
Cómo medirlo en serio
No te quedes en Lighthouse. Es útil pero es lab data; las decisiones se toman con datos de campo. Usa el reporte de Core Web Vitals de Search Console o el web-vitals library reportando a tu analytics. Establece budgets por página y romperlos debe bloquear deploys.