Local Max
Volver al blog
Performance15 min de lectura· 2022-07-14

Core Web Vitals 2026: LCP, INP y CLS explicados para SEO

Manual de referencia para entender y optimizar Core Web Vitals en 2026: las tres métricas oficiales de Google (LCP, INP, CLS), cómo se miden, cómo se diagnostican, qué optimizaciones tienen mayor ROI y cómo afectan al SEO.

Core Web Vitals: LCP, INP y CLS para SEO
EL

Eduardo López Parada

Fundador · Local Max

Los Core Web Vitals son las tres métricas oficiales de Google para evaluar la experiencia de usuario en una web: LCP (Largest Contentful Paint), INP (Interaction to Next Paint, reemplazó a FID en marzo 2024) y CLS (Cumulative Layout Shift). Desde 2021 son señal de ranking confirmada y, con mobile-first indexing universal, se han convertido en hygiene factor obligatorio: sitios con CWV en rojo pierden posiciones sistemáticamente vs competidores con CWV en verde. Esta guía explica cada métrica, los umbrales objetivo, cómo medirlas en producción, qué optimizaciones tienen mayor ROI y los errores frecuentes que las disparan a rojo.

Qué son los Core Web Vitals y por qué importan al SEO

Google introdujo Core Web Vitals en 2020 como parte de su iniciativa Web Vitals para estandarizar la medición de experiencia web. En 2021 los convirtió en señal oficial de ranking dentro del Page Experience update. En marzo 2024 sustituyó FID por INP como métrica oficial de interactividad — el cambio más importante reciente. En 2026 son métricas críticas porque: 1) Google las usa en ranking. 2) Mobile-first indexing universal las hace prerequisito. 3) AI Overview prioriza sitios con buena UX. 4) Conversión directa: cada décima de LCP que bajas mejora conversión un 5-10 %.

Las tres métricas oficiales 2026

MétricaQué mideUmbral verdeUmbral rojo
LCPTiempo hasta pintar el elemento más grande del above-the-fold< 2,5 segundos> 4 segundos
INPLatencia de respuesta a interacción del usuario< 200 ms> 500 ms
CLSMovimiento visual no esperado durante carga< 0,1> 0,25

Google evalúa el percentil 75 de tu tráfico real (datos CrUX, Chrome User Experience Report). No basta con que la mayoría de usuarios tenga CWV en verde — el 75 % debe estarlo. Si tu LCP móvil mediano es 2,2s pero el p75 es 4,1s, Google te clasifica como "Poor".

LCP (Largest Contentful Paint): la métrica más impactante

LCP mide cuánto tarda en pintarse el elemento más grande visible en el above-the-fold (típicamente la imagen hero, un vídeo o un bloque grande de texto). Es la métrica más decisiva para percepción de velocidad — el usuario interpreta "está cargado" cuando ve ese elemento principal.

Qué afecta LCP

  1. 1Tiempo de respuesta del servidor (TTFB): idealmente < 300 ms. Por encima de 600 ms ya penaliza LCP significativamente.
  2. 2Peso y formato de la imagen hero: una imagen de 2 MB en JPG sin optimizar destroza LCP. WebP/AVIF + compresión adecuada baja LCP en 1-3 segundos.
  3. 3Recursos render-blocking: CSS y JavaScript en <head> sin defer/async bloquean el render. Cada uno añade 100-500 ms.
  4. 4Fuentes web sin display: swap: el navegador espera a descargar la fuente antes de pintar texto. Solución: font-display: swap.
  5. 5CDN sin cobertura geográfica: si tu servidor está en Frankfurt y el usuario en Madrid, latencia 30 ms; en México, 200 ms.
  6. 6Lazy loading mal aplicado al hero: si pones loading="lazy" en la imagen hero, retrasas LCP > 1 segundo. Mantenerlo eager.

Cómo optimizar LCP (orden de mayor a menor impacto)

  • ✓Hosting con TTFB < 300 ms (cambiar de hosting compartido barato a managed WordPress, Cloudways, Kinsta, WP Engine, o estático en Vercel/Netlify)
  • ✓Imagen hero en WebP/AVIF con compresión adecuada (sweet spot 75-85 % quality, peso < 200 KB)
  • ✓Dimensiones width + height explícitas en HTML para reservar espacio
  • ✓Preload de la imagen LCP candidate:
  • ✓fetchpriority='high' en el del hero (señal adicional al navegador)
  • ✓Eliminar render-blocking CSS y JavaScript del (defer/async/critical CSS inline)
  • ✓Font-display: swap en @font-face para no bloquear texto
  • ✓CDN universal (Cloudflare Free es suficiente para empezar)
  • ✓Caché agresivo de assets estáticos (cache-control: public, max-age=31536000, immutable)

INP (Interaction to Next Paint): el reemplazo de FID

INP reemplazó oficialmente a FID en marzo 2024 como métrica oficial de Core Web Vitals. La diferencia: FID medía solo la PRIMERA interacción del usuario; INP mide la latencia de TODAS las interacciones (clics, taps, teclas) durante la sesión y reporta el p98 (el percentil 98). Es métrica más exigente y más representativa de la experiencia real.

Qué afecta INP

  1. 1JavaScript pesado en el main thread: si el thread principal del navegador está ocupado ejecutando JS, las interacciones del usuario esperan. Causa #1 de INP malo.
  2. 2Event listeners no debounced: handlers de scroll, mousemove o input que se ejecutan en cada evento sin throttling.
  3. 3Third-party scripts pesados: chats (Tawk.to, Crisp, Intercom), pixels de tracking (Meta, TikTok), heatmaps (Hotjar) — cada uno añade JS al main thread.
  4. 4React/Vue hydration costoso: SPAs con hydration de cliente bloquean interacción hasta que termina. Soluciones: SSR con streaming, islands architecture (Astro), partial hydration.
  5. 5Layouts complejos con muchos elementos animados: cada interacción dispara re-layout/re-paint masivo.

Cómo optimizar INP

  • ✓Auditar JS de terceros: eliminar chats, pixels y heatmaps que no usas activamente
  • ✓Lazy-load scripts no críticos con loading='lazy' o async/defer
  • ✓Web Workers para tareas pesadas (cálculos, parsing) — no bloquea main thread
  • ✓Debouncing/throttling en event listeners de alta frecuencia (scroll, mousemove)
  • ✓Code splitting agresivo: dynamic imports para componentes que se cargan bajo interacción
  • ✓React 18+ concurrent features (useDeferredValue, startTransition) para interacciones smooth
  • ✓Considerar migración a Astro o Qwik para sitios donde JS es prescindible

CLS (Cumulative Layout Shift): el saltarín visual

CLS mide el movimiento visual no esperado durante la carga. Si vas a hacer clic en un botón y de repente aparece un banner que desplaza ese botón 100px hacia abajo, ese es un CLS shift. La fórmula: impact fraction × distance fraction de cada shift, sumados durante toda la sesión. Objetivo: < 0,1. Por encima de 0,25 Google clasifica como Poor.

Qué causa CLS alto

  1. 1Imágenes sin width + height explícitos: el navegador no sabe cuánto espacio reservar hasta que descarga la imagen.
  2. 2Ads o iframes sin dimensiones reservadas: AdSense, banners de afiliados, embeds de YouTube sin contenedor pre-dimensionado.
  3. 3Fuentes web que cambian de tamaño al cargar (FOIT/FOUT): el texto se pinta primero con fuente del sistema y luego cambia a la fuente custom, redimensionando.
  4. 4Contenido inyectado dinámicamente above existing content: el clásico "banner de cookies que empuja el contenido hacia abajo".
  5. 5Animaciones CSS que cambian layout properties: transitions de width/height en lugar de transform.

Cómo optimizar CLS

  • ✓Dimensiones width + height obligatorias en TODOS los
  • ✓aspect-ratio CSS para contenedores de imágenes/vídeos responsive
  • ✓Reservar espacio para ads con min-height antes de que carguen
  • ✓Banner de cookies en posición fixed (no en flujo de documento)
  • ✓Fuentes con size-adjust + ascent-override para minimizar cambio de altura al swap
  • ✓size-adjust en @font-face para alinear métricas con fuente del sistema
  • ✓Usar transform: translate en lugar de width/height para animaciones
  • ✓Embeds (YouTube, Twitter, etc.) en contenedor con aspect-ratio fijo

Cómo medir Core Web Vitals (las dos formas)

Existen dos tipos de medición de CWV que reportan datos distintos. Conocer la diferencia es crucial para diagnosticar bien.

Datos de campo (CrUX) — los que Google usa para ranking

Chrome User Experience Report (CrUX) recopila métricas anónimas de usuarios reales de Chrome que visitan tu sitio. Es el dataset que Google usa para evaluar tu CWV en ranking. Se actualiza cada 28 días.

  • Google Search Console → Experiencia → Core Web Vitals: ver tus métricas reales por URL agrupadas.
  • PageSpeed Insights: introduce URL y muestra CrUX 28 días + Lighthouse sintético en una vista.
  • CrUX Dashboard en Looker Studio: para tracking continuo.
  • Vercel Analytics, Cloudflare Web Analytics, Akamai mPulse: Real User Monitoring (RUM) integrado en tu plataforma.

Datos de laboratorio (sintéticos) — para debugging

Tests sintéticos ejecutados en condiciones controladas (Chrome headless, Moto G4 simulado, throttling 4G). Útiles para debugging porque puedes ver qué optimización mejora qué métrica antes de desplegar.

  • Lighthouse: en Chrome DevTools → Lighthouse o PageSpeed Insights. Gratis.
  • WebPageTest: webpagetest.org. Test detallado con waterfall, filmstrip, métricas avanzadas.
  • GTmetrix: alternativa friendly. 14,95 $/mes plan pro.
  • SpeedCurve, Calibre, DebugBear: tools enterprise para CI/CD performance monitoring.

Benchmarks por tipo de sitio

Tipo de sitioLCP objetivoINP objetivoCLS objetivo
Sitio estático Next.js / Astro / Hugo< 1,5s< 100 ms< 0,05
WordPress bien optimizado + CDN< 2,5s< 200 ms< 0,1
WordPress típico de pyme sin optimizar3-5s200-400 ms0,1-0,3
E-commerce Shopify (default)2-3,5s150-250 ms< 0,1
E-commerce WooCommerce sin optimizar4-7s300-500 ms0,1-0,4
E-commerce headless Next.js + Shopify API< 1,5s< 100 ms< 0,05
SaaS B2B con SPA React2-4s200-400 ms< 0,1
Sitio editorial con ads (typical news)3-5s300-600 ms0,1-0,3

Quick wins de mayor ROI

  1. 1Migrar imágenes a WebP/AVIF: -25 a -65 % de peso = -1 a -3 segundos de LCP en sitios image-heavy.
  2. 2Cambiar de hosting compartido a managed: TTFB de 1.500ms a 200ms = -1,3 segundos de LCP.
  3. 3Activar Cloudflare CDN gratis: -200 a -500 ms LCP en tráfico internacional.
  4. 4Añadir dimensiones a TODAS las imágenes: -0,15 a -0,30 de CLS en sitios sin medidas.
  5. 5Eliminar 3-5 scripts de terceros no esenciales: -100 a -300 ms INP.
  6. 6font-display: swap en @font-face: -200 a -500 ms LCP y mejora CLS de fuentes.
  7. 7Defer/async en scripts no críticos: -200 a -800 ms LCP.
  8. 8Comprimir gzip/brotli en servidor: -30 a -60 % tamaño total transferido = mejor LCP global.

Errores frecuentes que disparan Core Web Vitals a rojo

  1. 1Hosting compartido low-cost (Hostinger Starter, OVH compartido, marca blanca de "Tu Web por 12 €/año"): TTFB > 1.500 ms mata LCP global.
  2. 2Imágenes 4000×3000 px sin optimizar cuando se muestran a 1200×900.
  3. 3Theme WordPress pesado (Divi, Avada, BeTheme) con 200-500 KB de CSS+JS antes de renderizar.
  4. 430+ plugins activos: cada uno añade scripts al main thread.
  5. 5Cookie banner sin posición fixed: empuja contenido hacia abajo, dispara CLS.
  6. 6YouTube/Twitter embeds sin contenedor pre-dimensionado.
  7. 7Chatbots cargando en home automáticamente (Tawk.to, Crisp): añaden 200-500 KB de JS bloqueante.
  8. 8Google Fonts cargado en sin display: swap.
  9. 9jQuery sin defer/async cuando ya no es necesario para nada.
  10. 10Polyfills innecesarios para navegadores que ya no soportas.

¿Tus Core Web Vitals están en rojo y no sabes por qué?

60 minutos gratis con un consultor técnico SEO. Hacemos auditoría completa de LCP/INP/CLS en muestra de 10-20 URLs con Lighthouse + CrUX + WebPageTest. Te entregamos plan priorizado con los quick wins de mayor impacto inmediato.

Reservar auditoría técnica

Preguntas frecuentes

¿Qué son los Core Web Vitals?

Los Core Web Vitals son las tres métricas oficiales de Google para evaluar la experiencia de usuario en una web: LCP (Largest Contentful Paint, mide tiempo hasta pintar el elemento más grande del above-the-fold), INP (Interaction to Next Paint, mide latencia de respuesta a interacciones — reemplazó a FID en marzo 2024) y CLS (Cumulative Layout Shift, mide movimiento visual no esperado durante carga). Umbrales verdes: LCP < 2,5s, INP < 200ms, CLS < 0,1. Son señal oficial de ranking desde 2021 dentro del Page Experience update, y en 2026 con mobile-first indexing universal se han convertido en hygiene factor obligatorio: sitios con CWV en rojo pierden posiciones sistemáticamente vs competidores con CWV en verde. Google evalúa el percentil 75 (p75) de tu tráfico real recopilado por Chrome User Experience Report (CrUX).

¿Cuál es la diferencia entre FID e INP?

FID (First Input Delay) medía solo la latencia de la PRIMERA interacción del usuario con la página — un único dato. INP (Interaction to Next Paint) reemplazó oficialmente a FID en marzo 2024 como métrica de Core Web Vitals porque es más representativa: mide la latencia de TODAS las interacciones (clics, taps, teclas) durante toda la sesión, y reporta el p98 (percentil 98, la peor experiencia que tuvo el 2 % de tus usuarios). Umbral verde: INP < 200ms; rojo: > 500ms. La transición de FID a INP fue dolorosa para muchos sitios porque pasaron de 'todo verde' (FID era fácil de cumplir) a 'todo amarillo o rojo' en INP, especialmente sitios JavaScript-heavy con SPAs y muchos scripts de terceros. Optimizar INP requiere reducir JavaScript en main thread, eliminar third-party scripts no esenciales, usar Web Workers, debouncing, code splitting agresivo, y considerar arquitecturas con menor JS (Astro, Qwik, Hotwire).

¿Cómo se miden los Core Web Vitals?

Dos tipos de medición que reportan datos distintos. 1) Datos de campo (CrUX, Chrome User Experience Report): métricas anónimas de usuarios reales de Chrome que visitan tu sitio. Es el dataset que Google usa para ranking. Se actualiza cada 28 días. Herramientas: Google Search Console → Experiencia → Core Web Vitals (datos reales por URL), PageSpeed Insights (CrUX + Lighthouse en una vista), CrUX Dashboard en Looker Studio (tracking continuo), Vercel Analytics, Cloudflare Web Analytics, Akamai mPulse (RUM integrado). 2) Datos de laboratorio (sintéticos): tests ejecutados en condiciones controladas (Chrome headless, Moto G4 simulado, throttling 4G). Útil para debugging. Herramientas: Lighthouse (Chrome DevTools), WebPageTest, GTmetrix, SpeedCurve. Crítico: Google usa datos de campo (CrUX) para ranking, no datos de laboratorio. Lighthouse puede dar 100/100 pero CrUX puede mostrar rojo si tu hosting real es más lento que el entorno de test.

¿Cuánto afectan los Core Web Vitals al SEO?

Son señal de ranking oficial desde 2021, pero no la más decisiva. Google ha confirmado que CWV son tiebreaker entre páginas con contenido equivalente — entre dos URLs con contenido similar y autoridad similar, gana la que tenga mejor experiencia (CWV en verde). En sectores ultra-competidos donde los top 10 tienen contenido y autoridad similar, CWV puede mover 3-5 posiciones. En sectores menos competidos, contenido y autoridad pesan más. Lo que SÍ es decisivo es el efecto indirecto: CWV mejores → mejor conversión → más tiempo en página → menos rebote → mejores señales de UX que Google sí pondera. Un sitio con CWV en rojo y bounce rate 80 % envía señal negativa a Google aunque CWV no fuera ranking directo. Estrategia operativa: trata CWV como hygiene factor obligatorio (verde objetivo), no como palanca diferencial. Ningún site con CWV en rojo va a Top 3 sostenido en sectores serios.

¿Cuál es el LCP, INP y CLS recomendado para una pyme?

Umbrales oficiales de Google (válidos para todo tipo de sitio): LCP < 2,5s verde, 2,5-4s amarillo, > 4s rojo. INP < 200ms verde, 200-500ms amarillo, > 500ms rojo. CLS < 0,1 verde, 0,1-0,25 amarillo, > 0,25 rojo. Benchmarks reales por tipo de sitio 2026: Sitio estático en Next.js/Astro/Hugo bien hecho: LCP < 1,5s, INP < 100ms, CLS < 0,05 (objetivo aspiracional). WordPress bien optimizado con CDN: LCP < 2,5s, INP < 200ms, CLS < 0,1 (cumple verde). WordPress típico de pyme sin optimizar: LCP 3-5s, INP 200-400ms, CLS 0,1-0,3 (mejorable). E-commerce Shopify default: LCP 2-3,5s, INP 150-250ms, CLS < 0,1. Una pyme con presupuesto razonable debería apuntar a verde en las tres métricas — es alcanzable con WordPress optimizado + buen hosting + CDN + imágenes WebP. Si tu pyme está en rojo, los quick wins típicos (cambiar hosting, WebP, CDN gratis Cloudflare, dimensiones explícitas) bajan a verde en 2-4 semanas de implementación.

¿Cómo se optimiza LCP?

Por orden de mayor a menor impacto: 1) Hosting con TTFB < 300ms (cambiar de hosting compartido low-cost a managed WordPress como SiteGround, Kinsta, WP Engine, o estático en Vercel/Netlify) — impacto -1 a -2 segundos LCP. 2) Imagen hero en WebP/AVIF con compresión adecuada (peso < 200KB) — impacto -1 a -3 segundos LCP en sitios image-heavy. 3) Preload de imagen LCP candidate con <link rel='preload' as='image' fetchpriority='high'> y fetchpriority='high' en el <img> — impacto -300 a -800ms. 4) Eliminar render-blocking CSS y JavaScript del <head>: defer/async/critical CSS inline — impacto -200 a -800ms. 5) Font-display: swap en @font-face para no bloquear texto — impacto -200 a -500ms. 6) CDN universal (Cloudflare Free es suficiente para empezar) — impacto -200 a -500ms en tráfico internacional. 7) Caché agresivo de assets estáticos (cache-control: max-age=31536000, immutable). 8) Lazy loading SOLO en imágenes below the fold, mantener hero eager. Sitios WordPress típicos pasan de LCP 5-6s a 2-2,5s aplicando los 5 primeros puntos.

¿Cómo se optimiza INP?

Por orden de impacto: 1) Auditar JavaScript de terceros: eliminar chats (Tawk.to, Crisp, Intercom), pixels de tracking (Meta, TikTok), heatmaps (Hotjar) que no usas activamente. Cada uno añade 50-300ms de JS al main thread. 2) Lazy-load scripts no críticos con loading='lazy' (nativo), async o defer. Solo cargar lo absolutamente crítico inline en <head>. 3) Web Workers para tareas pesadas (cálculos, parsing, ordenación de listas grandes): mueve trabajo fuera del main thread. 4) Debouncing/throttling en event listeners de alta frecuencia (scroll, mousemove, input): usar lodash.debounce o implementación nativa cada 100-200ms. 5) Code splitting agresivo: dynamic imports para componentes que se cargan bajo interacción (modales, sidebars, formularios complejos). 6) En React/Next.js: React 18+ concurrent features (useDeferredValue, startTransition, useTransition) para interacciones smooth en listas grandes. 7) Considerar migración a Astro o Qwik si tu sitio no necesita SPA — son arquitecturas que minimizan JavaScript en cliente. 8) Auditar third-party con DebugBear o Calibre para identificar el script concreto que dispara INP malo.

▸ ARTÍCULOS RELACIONADOS

Sigue profundizando.

Cluster temático: Performance + Técnico

▸ GARANTÍA Y COMPROMISO

Cómo nos jugamos la piel contigo.

La mayoría de agencias de SEO Local te venden esperanza con frases ambiguas y contratos blindados. Local Max funciona al revés: las garantías están por escrito, los objetivos se firman al inicio y el coste de equivocarnos lo asumimos nosotros.

Plan firmado

Antes de empezar firmamos un plan trimestral con objetivos verificables: keyword principal, posición de partida medida con Local Falcon, métrica de éxito y deadline. Sin objetivos genéricos como 'mejorar SEO'.

3 meses sin top 10 = mes gratis

Si tras 90 días de trabajo continuo con presupuesto completo no estás en el top 10 del Map Pack para tu keyword principal acordada, el cuarto mes lo trabajamos sin facturar. No es marketing: está escrito en el contrato.

Cancelas con 30 días

Sin permanencia anual. Sin cláusulas de salida con coste. Si decides parar, avisas con 30 días y te entregamos todo: accesos, credenciales, schema, contenido. Nada se queda atrapado en infraestructura nuestra.

Acceso directo a Eduardo

Tu interlocutor es Eduardo López Parada, fundador. No hay capa de account managers ni juniors. Si tienes una duda urgente vas directamente a quien está tomando decisiones técnicas en tu cuenta.

¿Hablamos de tu ciudad?

Auditoría gratis. Sin compromiso. Respondemos en 24 horas hábiles.

Reservar llamada estratégicaConsultoría · 199 €644 58 34 27WhatsApp
Reservar llamada