En esta guía
LCP, INP y CLS no son solo métricas técnicas: son la diferencia entre rankear o no. Desde 2021 forman parte explícita del page experience signal de Google, y desde la actualización de marzo 2024 (cuando INP reemplazó FID) los umbrales se volvieron más estrictos. Esta es la guía práctica para mejorarlos, con las optimizaciones específicas por framework — incluida la situación particular de sitios construidos con Lovable y otros SPAs.
Qué son los Core Web Vitals en 2026
Los Core Web Vitals son tres métricas que Google considera representativas de la experiencia de usuario real:
- LCP (Largest Contentful Paint) — el tiempo que tarda en aparecer el elemento más grande visible (típicamente la imagen hero, un H1 grande, o un bloque de video). Mide qué tan rápido el usuario percibe que la página cargó.
- INP (Interaction to Next Paint) — el tiempo entre que el usuario hace una interacción (click, tap, keystroke) y la próxima actualización visual. Reemplazó a FID en marzo 2024 como métrica de interactividad. INP es más estricto: mide la peor interacción de la sesión, no solo la primera.
- CLS (Cumulative Layout Shift) — cuánto se mueven los elementos de la página durante la carga. Mide la inestabilidad visual.
Las tres se reportan como percentil 75 de tu base de usuarios real (no del promedio). Eso significa: el 75% de tus usuarios deben experimentar valores dentro del umbral "bueno" para que tu URL sea categorizada como "bueno" en GSC.
Los umbrales exactos: bueno, mejorable, pobre
Los thresholds 2026 según el Web.dev oficial:
LCP
- Bueno: ≤ 2.5 segundos
- Mejorable: 2.5 – 4.0 segundos
- Pobre: > 4.0 segundos
INP
- Bueno: ≤ 200 milisegundos
- Mejorable: 200 – 500 milisegundos
- Pobre: > 500 milisegundos
CLS
- Bueno: ≤ 0.1
- Mejorable: 0.1 – 0.25
- Pobre: > 0.25
Cómo medirlos correctamente (campo vs laboratorio)
La distinción que la mayoría se salta y termina pagando: hay dos tipos de mediciones, y solo una afecta tus rankings.
Datos de campo (Field Data / RUM / CrUX)
Provienen del Chrome User Experience Report — agregaciones anónimas de usuarios reales de Chrome. Estos son los datos que Google usa para evaluar tu sitio. Los ves en:
- GSC → Core Web Vitals — la única vista que importa para rankings. Categoriza tus URLs en "Bueno / Mejorable / Pobre".
- PageSpeed Insights — sección superior con los datos de campo.
- CrUX API — para integraciones programáticas.
Datos de laboratorio (Lab Data)
Provienen de mediciones simuladas en condiciones controladas. Útiles para debuggear, no para evaluar rankings.
- Lighthouse en Chrome DevTools — corre en tu máquina.
- PageSpeed Insights — sección inferior.
- WebPageTest.org — más sofisticado, permite probar desde ubicaciones específicas.
Si tus datos de campo son malos pero los de laboratorio son buenos: hay un problema con usuarios reales que el ambiente simulado no replica. Causas típicas: conexiones móviles lentas, dispositivos viejos, scripts third-party que cargan después de que termina la simulación, A/B tests con variantes lentas.
Cómo mejorar LCP
Identificar el LCP element primero
Antes de optimizar, identificá qué elemento es el LCP. En Chrome DevTools → Performance, grabás una carga; el elemento más grande pintado entre 0s y el LCP aparece marcado. En 80% de los casos es la imagen hero o el bloque H1.
Preload del recurso LCP
Si el LCP es una imagen, agregá un preload en el <head>:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">El atributo fetchpriority="high" (soportado desde 2023) le dice al navegador que priorice ese recurso sobre los demás.
Servir imágenes en formato moderno
WebP o AVIF en lugar de JPEG/PNG. WebP es 25–35% más liviano para misma calidad visual; AVIF es 50% más liviano pero con menor soporte en navegadores viejos. Servilos con <picture> y fallbacks:
<picture>
<source srcset="/hero.avif" type="image/avif">
<source srcset="/hero.webp" type="image/webp">
<img src="/hero.jpg" alt="..." width="1200" height="630">
</picture>Eliminar render-blocking resources
CSS y JS bloqueantes en <head> retrasan el primer paint. Reglas operativas:
- CSS crítico inline en
<style>, resto async - JS no esencial con
deferoasync - Fonts con
font-display: swappara que el texto aparezca incluso si la fuente no cargó
CDN y caching
Servir assets desde un CDN (Cloudflare, Fastly, Vercel Edge) reduce LCP entre 30–50% para usuarios geográficamente distantes del servidor origen. Es la optimización con mejor ratio impacto/esfuerzo si tu base de usuarios es global.
Cómo mejorar INP
Reducir trabajo en el main thread
INP mide la latencia entre interacción y respuesta visual. El cuello de botella casi siempre es JavaScript ejecutándose en el main thread cuando el usuario interactúa. Estrategias:
- Code splitting — cargar solo el JS necesario para la ruta actual. En Vite/Next, esto suele ser automático con
import()dinámico. - Tree shaking — eliminar código muerto del bundle.
- Auditá tus dependencias con
npx vite-bundle-visualizerowebpack-bundle-analyzer. Reemplazá librerías pesadas con alternativas livianas (date-fns en vez de moment.js, lodash-es con tree shaking en vez de lodash completo).
useDeferredValue y useTransition (React)
Si tu app es React 18+, los hooks de concurrencia mejoran INP significativamente. useTransition marca actualizaciones de estado como no-urgentes, permitiendo que la respuesta visual al usuario suceda primero:
const [isPending, startTransition] = useTransition();
const handleSearch = (value) => {
setQuery(value); // urgente — actualiza el input
startTransition(() => {
setResults(filter(items, value)); // no-urgente
});
};Web Workers para trabajo pesado
Cualquier procesamiento sostenido (parsing de archivos grandes, cálculos, búsqueda en datasets locales) debería correr en un Web Worker, no en el main thread. Esto libera el main thread para responder a interacciones del usuario.
Reducir long tasks
Una "long task" es cualquier bloque de JS que corre por más de 50ms sin yield. Dividilas con scheduler.yield() (cuando esté disponible) o con setTimeout(fn, 0) para forzar al navegador a procesar interacciones pendientes entre tareas.
Cómo mejorar CLS
Width y height en imágenes y videos
Toda imagen y video debe tener atributos width y height explícitos. Sin ellos, el navegador no puede reservar el espacio correcto antes de cargar el asset, y cuando carga, todo lo que está debajo se desplaza. CLS automáticamente sube.
Reservar espacio para ads y embeds
Anuncios, embeds de Twitter/YouTube y widgets de terceros cargan asincrónicamente y desplazan contenido. Reservales un contenedor con dimensiones fijas:
<div style="min-height: 300px;">
<!-- ad slot -->
</div>Fuentes web con font-display
Cuando una fuente web carga después del texto, el navegador re-pinta con la fuente nueva y el layout se desplaza ligeramente (FOUT — Flash of Unstyled Text). font-display: swap mitiga, font-display: optional elimina el problema a costa de que algunos usuarios nunca vean tu fuente custom.
No insertar contenido encima de contenido existente
Banners, cookie notices, popups que aparecen en el top de la página y empujan todo hacia abajo son el peor patrón de CLS. Si necesitás un cookie banner, hacelo fixed/sticky en bottom o como overlay modal.
El caso específico de SPAs y sitios Lovable
Las single-page applications tienen un problema estructural con Core Web Vitals: el HTML inicial está casi vacío y todo el contenido aparece después de que React/Vue/Angular se hidrata. LCP típicamente es malo (3–5s) por eso mismo.
Para sitios Lovable y similares, la solución no es optimizar el bundle de JavaScript — es pre-renderizar. Servicios como LovableHTML generan snapshots HTML estáticos de cada ruta que se sirven a Googlebot y reducen LCP percibido a 1–2 segundos. La hidratación de React sigue ocurriendo después, pero el LCP element ya está visible.
Sin pre-rendering, un sitio Lovable típico no puede salir de la categoría "Mejorable" en LCP de field data, independientemente de cuánto optimices el código.
Preguntas frecuentes
¿Los Core Web Vitals son realmente factor de ranking?
Sí. Google los incluye como parte del Page Experience signal desde 2021. El peso es relativamente modesto comparado con relevance y backlinks, pero es un "tiebreaker": cuando dos páginas son comparables en otros aspectos, la de mejores CWV rankea mejor. Para sitios competitivos, ese tiebreaker es la diferencia entre posición 3 y posición 7.
¿Cómo verifico si Core Web Vitals está afectando mi ranking?
En GSC → Core Web Vitals, identificá las URLs categorizadas como "Pobre". Cruzá con tu reporte de Performance: si esas URLs tienen impresiones altas pero posiciones promedio peor que tu media, probablemente CWV está siendo el factor limitante. Si querés un diagnóstico completo donde CWV es solo uno de los 12 puntos, hacé una auditoría SEO técnica completa.
¿Cuánto tiempo tarda en reflejarse una mejora en CWV en GSC?
Los datos de campo se basan en 28 días rodantes. Una mejora deployada hoy empieza a verse parcialmente en 7 días y completamente en 28. Los rankings que mejoran por CWV pueden tardar otros 2–6 semanas adicionales después de que GSC categorice las URLs como "Bueno".
¿INP es realmente más estricto que FID?
Significativamente. FID solo medía la primera interacción de la sesión, e ignoraba interacciones complejas. INP mide la peor interacción de toda la sesión y considera todo el ciclo de respuesta visual. Sitios que estaban en "Bueno" con FID son comúnmente "Mejorable" o "Pobre" con INP.
¿Vale la pena optimizar CWV si mi competencia tampoco lo tiene optimizado?
Sí, por dos razones. Una: cuando ellos eventualmente optimicen (y lo harán), vas a estar atrás. Dos: CWV no es solo señal de ranking, es UX directa — bounce rate y conversiones mejoran independientemente del SEO. El ROI es doble.
¿Qué hago si mi LCP es bueno en desktop pero malo en mobile?
Mobile-first indexing significa que Google usa principalmente la versión mobile para rankear. Optimizá para mobile primero. Las palancas típicas: imágenes responsive con srcset, JS bundle más liviano para mobile, y reducción de third-party scripts que pegan mucho más en CPUs mobile más débiles.