Como Optimizar Core Web Vitals: LCP, FID y CLS Explicados

¿Qué son los Core Web Vitals?

Los Core Web Vitals son un conjunto de métricas definidas por Google que miden la experiencia de usuario real de una página web. Desde 2021, son un factor de ranking en los resultados de búsqueda de Google, lo que significa que una web lenta o inestable puede perder posiciones frente a competidores más rápidos.

Las tres métricas que componen los Core Web Vitals miden aspectos diferentes de la experiencia de usuario: velocidad de carga percibida (LCP), capacidad de respuesta a interacciones (INP, que reemplazó a FID en marzo de 2024) y estabilidad visual (CLS). Juntas, proporcionan una imagen holística de cómo los usuarios perciben el rendimiento de tu web.

Es importante entender que los Core Web Vitals se miden con datos de campo (Real User Metrics o RUM), no de laboratorio. Google recopila datos de usuarios reales de Chrome a través del Chrome User Experience Report (CrUX) y los agrega a nivel de página durante un periodo de 28 días. Esto significa que las métricas reflejan la experiencia real de tus usuarios en sus dispositivos y conexiones reales, no las condiciones ideales de tu máquina de desarrollo.

Cada métrica tiene tres umbrales: "Good" (verde, objetivo a alcanzar), "Needs Improvement" (amarillo, requiere atención) y "Poor" (rojo, necesita mejoras urgentes). Google considera que una página aprueba los Core Web Vitals cuando el percentil 75 de todas las cargas de página está en el rango "Good" para las tres métricas.

LCP (Largest Contentful Paint): Velocidad de carga percibida

LCP mide el tiempo que tarda en renderizarse el elemento de contenido más grande visible en el viewport. Este elemento suele ser una imagen hero, un título principal, un vídeo o un bloque de texto grande. LCP responde a la pregunta: "¿Cuánto tarda el contenido principal en ser visible para el usuario?"

Umbrales: Good: menos de 2.5 segundos. Needs Improvement: entre 2.5 y 4 segundos. Poor: más de 4 segundos.

Factores que afectan al LCP

El LCP depende de cuatro factores principales: tiempo de respuesta del servidor (TTFB), tiempo de descarga de recursos (imágenes, fuentes, CSS), tiempo de renderizado del CSS y tiempo de carga de JavaScript que bloquea el renderizado. Optimizar LCP requiere abordar cada uno de estos factores.

Estrategias de optimización de LCP

Optimiza el TTFB: Usa un CDN para servir contenido estático desde servidores cercanos al usuario. Implementa server-side rendering (SSR) o static site generation (SSG) para reducir el tiempo de generación de HTML. Optimiza las consultas a bases de datos y usa caché de servidor (Redis, Memcached) para respuestas frecuentes. Un TTFB inferior a 800ms es el objetivo.

Prioriza el recurso LCP: Identifica cuál es el elemento LCP de tu página (normalmente la imagen hero o el título principal) y prioriza su carga. Usa <link rel="preload"> para la imagen LCP, añade fetchpriority="high" a la etiqueta img, y evita loading="lazy" en la imagen LCP (úsalo solo para imágenes below the fold).

Optimiza imágenes: Usa formatos modernos como WebP o AVIF que ofrecen mejor compresión que JPEG/PNG. Sirve imágenes responsive con srcset para que cada dispositivo descargue solo el tamaño que necesita. Para la imagen LCP, considera usar un tamaño fijo optimizado para el viewport más común de tus usuarios.

Elimina JavaScript que bloquea el renderizado: El JavaScript síncrono en el head bloquea el renderizado del HTML. Usa defer o async para scripts no críticos, y mueve el JavaScript no esencial al final del body. Para frameworks como React/Next.js, el hydration del JavaScript puede retrasar el LCP; considera selective hydration o partial hydration con frameworks como Astro.

Optimiza fuentes web: Las fuentes personalizadas pueden retrasar significativamente el renderizado del texto. Usa font-display: swap para mostrar texto con una fuente fallback mientras carga la fuente personalizada, preload las fuentes críticas, y usa size-adjust para minimizar el layout shift cuando la fuente personalizada carga.

INP (Interaction to Next Paint): Capacidad de respuesta

INP reemplazó a FID (First Input Delay) como métrica de Core Web Vital en marzo de 2024. Mientras FID solo medía el retraso de la primera interacción, INP mide la latencia de todas las interacciones del usuario durante toda la visita a la página: clicks, taps y teclas. El valor INP es el percentil 98 de todas las latencias de interacción, o la peor latencia si hay menos de 50 interacciones.

Umbrales: Good: menos de 200 milisegundos. Needs Improvement: entre 200 y 500 milisegundos. Poor: más de 500 milisegundos.

¿Por qué INP es más importante que FID?

FID solo medía el retraso antes de que el navegador comenzara a procesar la primera interacción, pero no medía el tiempo que tardaba la interacción en producir un resultado visual. INP mide la latencia completa: desde que el usuario interactúa hasta que el navegador pinta el siguiente frame con el resultado. Esto captura problemas que FID ignoraba completamente, como handlers de eventos lentos, layout thrashing y actualizaciones costosas del DOM.

Estrategias de optimización de INP

Reduce el trabajo del main thread: El navegador solo puede hacer una cosa a la vez en el main thread: ejecutar JavaScript, calcular estilos, hacer layout o pintar. Si el main thread está ocupado ejecutando JavaScript pesado, las interacciones del usuario se encolan y la respuesta se retrasa. Identifica y optimiza las tareas largas (long tasks, más de 50ms) usando el Performance tab de Chrome DevTools.

Divide tareas largas: Usa scheduler.yield() o setTimeout para dividir tareas largas en chunks más pequeños que permitan al navegador procesar interacciones del usuario entre medias. Esto es especialmente importante durante la inicialización de la página y en handlers de eventos complejos.

Optimiza event handlers: Los handlers de eventos que hacen mucho trabajo síncrono (cálculos pesados, actualizaciones masivas del DOM, llamadas de red síncronas) son la causa principal de un INP alto. Mueve el trabajo pesado a Web Workers, usa debouncing para eventos frecuentes, y actualiza solo las partes del DOM que realmente cambiaron.

Reduce el JavaScript total: Menos JavaScript significa menos parsing, compilación y ejecución. Audita tus dependencias, elimina las que no usas, y considera alternativas más ligeras. Cada kilobyte de JavaScript que eliminas mejora INP directamente.

CLS (Cumulative Layout Shift): Estabilidad visual

CLS mide la inestabilidad visual acumulada durante la vida de la página. Cada vez que un elemento visible cambia de posición inesperadamente (sin que el usuario haya interactuado), se registra un layout shift. CLS es la suma de todos estos shifts inesperados. Un CLS alto significa que la página "salta" mientras el usuario intenta leer o interactuar con ella.

Umbrales: Good: menos de 0.1. Needs Improvement: entre 0.1 y 0.25. Poor: más de 0.25.

Causas comunes de CLS

Imágenes sin dimensiones: Cuando una imagen no tiene atributos width y height, el navegador no sabe cuánto espacio reservar. Cuando la imagen carga, empuja el contenido circundante, causando un layout shift. Siempre incluye width y height en las etiquetas img, o usa CSS aspect-ratio para reservar el espacio.

Anuncios y embeds: Los anuncios que se cargan asíncronamente y no tienen un contenedor de tamaño fijo son una de las principales causas de CLS. Reserva espacio para anuncios con un contenedor de dimensiones fijas, incluso si el anuncio aún no ha cargado. Lo mismo aplica para embeds de vídeos, iframes y widgets de terceros.

Fuentes web: Cuando una fuente personalizada carga y reemplaza la fuente fallback, el texto puede cambiar de tamaño y causar un layout shift. Usa font-display: optional o font-display: swap con size-adjust para minimizar la diferencia de métricas entre la fuente fallback y la personalizada.

Contenido dinámico inyectado: Banners de cookies, notificaciones, barras de anuncios y contenido cargado asíncronamente que se inserta encima del contenido existente causan layout shifts. Para evitarlo, reserva espacio para estos elementos o insértalos debajo del contenido existente en lugar de encima.

Estrategias de optimización de CLS

La regla general es: reserva espacio para todo lo que va a aparecer. Si sabes que una imagen va a medir 600x400px, reserva ese espacio antes de que la imagen cargue. Si sabes que un anuncio va a ocupar 300x250px, crea un contenedor de ese tamaño. Si un banner de cookies va a aparecer en la parte inferior, reserva espacio o usa position: fixed para que no desplace el contenido.

Usa la herramienta Layout Shift Regions en Chrome DevTools para visualizar exactamente qué elementos se están moviendo y causando CLS. Esto te permite identificar rápidamente la fuente de los layout shifts y tomar acciones correctivas específicas.

Herramientas para medir Core Web Vitals

Herramientas de campo (datos reales)

Google Search Console: La sección "Core Web Vitals" muestra el rendimiento de tus URLs agrupadas por estado (Good, Needs Improvement, Poor) basándose en datos reales de usuarios de Chrome. Es la fuente más importante porque refleja exactamente lo que Google ve para ranking.

PageSpeed Insights: Combina datos de campo (CrUX) con un análisis de laboratorio (Lighthouse) para una URL específica. Proporciona recomendaciones específicas y priorizadas para mejorar cada métrica.

Chrome UX Report (CrUX): Base de datos pública con métricas de rendimiento real de millones de URLs. Puedes consultarla directamente vía BigQuery o usar la API de CrUX para obtener datos programáticamente.

web-vitals library: La librería oficial de Google para medir Core Web Vitals en tu propia aplicación. Instálala para enviar métricas a tu sistema de analytics y monitorear el rendimiento en tiempo real.

Herramientas de laboratorio (testing local)

Lighthouse: Integrado en Chrome DevTools (tab "Lighthouse"), proporciona un análisis completo de rendimiento, accesibilidad, SEO y buenas prácticas. Genera un informe con puntuaciones y recomendaciones accionables.

Chrome DevTools Performance tab: La herramienta más potente para debugging de rendimiento. Graba una sesión de uso y analiza en detalle cada milisegundo: tareas del main thread, renderizado, painting, layout, y los eventos de LCP, CLS e INP.

WebPageTest: Herramienta online que permite testear tu web desde múltiples ubicaciones, dispositivos y velocidades de conexión. Proporciona waterfall charts detallados, vídeos de la carga y métricas avanzadas.

Conclusión

Optimizar los Core Web Vitals no es solo un ejercicio de SEO; es una mejora real de la experiencia de tus usuarios. Una web que carga rápido (LCP), responde instantáneamente a las interacciones (INP) y no salta visualmente (CLS) genera más confianza, más engagement y más conversiones.

Empieza midiendo: revisa tus métricas en Google Search Console, identifica las páginas con peor rendimiento, y aborda los problemas más impactantes primero. Normalmente, optimizar las imágenes y reducir el JavaScript producen las mayores mejoras con el menor esfuerzo. La optimización de rendimiento es un proceso continuo, no un proyecto puntual: integra la medición de Core Web Vitals en tu pipeline de CI/CD para detectar regresiones antes de llegar a producción.