Si su sitio carga lento, Google lo sabe. Y si los usuarios sienten lag al hacer clic en un botón, Google también lo sabe. Esa es la lógica detrás de los Core Web Vitals: tres métricas que miden la experiencia real del usuario y que en 2026 son señal directa de ranking en SEO técnico.
El cambio más importante: en marzo de 2024 Google reemplazó FID (First Input Delay) por INP (Interaction to Next Paint). La mayoría de artículos SEO en español todavía hablan de FID — están desactualizados. Esta guía explica las tres métricas vigentes en 2026, cómo medirlas, cómo optimizarlas y cómo construir el stack WordPress + LiteSpeed + Cloudflare que sostiene scores de 95+ en PageSpeed.
Qué son los Core Web Vitals y por qué Google los usa
Los Core Web Vitals son un subconjunto de Web Vitals: métricas estandarizadas por Google para medir la calidad de experiencia del usuario en cualquier sitio web. A diferencia de métricas técnicas como TTFB o Speed Index, los Core Web Vitals miden lo que el usuario percibe realmente: qué tan rápido aparece el contenido, qué tan rápido responde el sitio cuando hace clic, y si el layout se mueve bajo sus dedos.
Google las usa como señal de ranking desde 2021 (Page Experience Update). En 2026 forman parte del núcleo de evaluación técnica de cualquier auditoría seria, junto a HTTPS, mobile-friendly, y ausencia de intersticiales intrusivos. No son la señal más fuerte (el contenido y los enlaces siguen pesando más), pero son un tiebreaker crítico: cuando dos resultados tienen calidad de contenido similar, el que tiene mejores CWV gana posición.
Datos de campo vs datos de laboratorio
Esta distinción es fundamental y mucha gente la confunde. Existen dos formas de medir Core Web Vitals:
- Datos de laboratorio (lab data): medidos en condiciones simuladas con herramientas como Lighthouse o PageSpeed Insights. Dan resultados reproducibles pero no reflejan al usuario real.
- Datos de campo (field data): medidos en navegadores reales de usuarios reales mediante el Chrome User Experience Report (CrUX). Estos son los datos que Google usa para ranking.
Search Console solo muestra datos de campo. PageSpeed Insights muestra ambos: el panel superior (CrUX) son datos de campo, el panel inferior (Lighthouse) son datos de laboratorio. Optimizar solo Lighthouse y olvidar campo es un error común.
Las 3 métricas oficiales 2026: LCP, INP, CLS
En 2026 los tres Core Web Vitals son:
- LCP (Largest Contentful Paint): mide qué tan rápido se renderiza el elemento más grande visible (típicamente una imagen hero o un bloque de texto). Umbral bueno: ≤ 2,5 segundos.
- INP (Interaction to Next Paint): mide la latencia de todas las interacciones del usuario (clics, taps, teclado) a lo largo de la sesión. Reemplazó a FID en marzo 2024. Umbral bueno: ≤ 200 ms.
- CLS (Cumulative Layout Shift): mide cuánto se mueve el layout durante la carga. Cero saltos = experiencia estable. Umbral bueno: ≤ 0,1.
Google clasifica cada métrica en tres niveles: Good (verde), Needs Improvement (naranja), Poor (rojo). Para que una URL pase los Core Web Vitals, las tres métricas deben estar en Good en el percentil 75 de las visitas reales — es decir, el 75% de los usuarios deben tener buena experiencia, no solo el promedio.
Por qué el percentil 75 importa
Mucha gente reporta su LCP promedio de 2,1s y cree que está bien. Pero si el promedio es 2,1s puede ser que el percentil 75 esté en 4,5s — un porcentaje significativo de usuarios sufre experiencia lenta. Google evalúa el p75 porque protege la experiencia de la mayoría, no del usuario más afortunado con conexión 5G y dispositivo nuevo.
INP: la nueva métrica que reemplazó a FID (marzo 2024)
FID (First Input Delay) medía solo la primera interacción del usuario, y solo la latencia de input (no el tiempo de procesamiento ni de renderizado). En la práctica, FID era trivial de pasar: la mayoría de sitios lograban < 100 ms sin esfuerzo, lo que la convertía en una métrica que no discriminaba.
INP corrigió eso. INP mide todas las interacciones de la sesión y reporta la peor (técnicamente, el percentil 98 si hay muchas interacciones). Y mide el ciclo completo: desde que el usuario hace clic hasta que se pinta el siguiente frame. Esto incluye procesamiento JavaScript, recálculo de estilos, layout y paint.
Por qué INP es más difícil de pasar
INP penaliza JavaScript pesado. Si su tema tiene scripts que bloquean el thread principal por 300 ms cuando el usuario hace clic en el menú móvil, INP lo va a detectar. WordPress con muchos plugins suele fallar INP aunque pase LCP y CLS sin problema. Es la métrica que más sitios WordPress está sufriendo en 2026.
Umbrales INP:
- Good: ≤ 200 ms
- Needs Improvement: 200 – 500 ms
- Poor: > 500 ms
Cómo medir Core Web Vitals: Search Console, PageSpeed, Lighthouse
Tres herramientas oficiales de Google, cada una con su rol:
Google Search Console — Reporte de Core Web Vitals
La fuente de verdad para SEO. Search Console muestra el reporte agregado por URL para los últimos 28 días, con datos de campo CrUX. Aparece en el menú “Experiencia → Core Web Vitals”. Aquí ve cuántas URLs están en Good, Needs Improvement, Poor — separadas por móvil y escritorio. Si una URL aparece en rojo, este es el dashboard que tiene que mirar para validar que sus optimizaciones surtieron efecto.
PageSpeed Insights — Análisis de URL específica
En pagespeed.web.dev pegas una URL y obtienes datos de campo + laboratorio. Es la herramienta para diagnóstico individual: muestra qué elemento es el LCP, qué interacciones empeoran INP, qué elementos causan layout shift, y da recomendaciones priorizadas con potencial de ahorro de tiempo.
Chrome DevTools — Lighthouse y Performance panel
Para desarrollo y debugging fino. Lighthouse en DevTools genera el mismo reporte que PageSpeed pero corre localmente. El panel Performance permite grabar una sesión y ver exactamente qué tareas largas bloquearon el thread principal (lo que daña INP).
Web Vitals Extension
Extensión oficial de Chrome que muestra LCP, INP, CLS en tiempo real mientras navegas cualquier sitio. Útil para auditorías rápidas y para sentir la experiencia del usuario, no solo verla en números.
Optimización LCP: reducir tiempo de carga del contenido principal
El LCP típicamente es una imagen hero o un bloque de texto grande visible al cargar. Cuatro fases componen el LCP: TTFB (servidor), descarga del recurso, render del recurso, y delay del recurso. Para optimizar, hay que atacar las cuatro.
TTFB: reducir tiempo del servidor
TTFB es lo que tarda el servidor en empezar a enviar HTML. En WordPress depende del hosting, del cache de páginas, y de la cantidad de queries por petición. LiteSpeed con LSCache resuelve la mayor parte: sirve HTML pre-generado en lugar de procesarlo en cada visita. TTFB sin cache puede ser 800 ms; con LSCache + Cloudflare cae a 100-150 ms.
Preload del hero
Si su LCP es una imagen hero, agregue para forzar al navegador a descargarla con prioridad alta antes de que descubra el en el HTML. Gana 200-500 ms fácilmente.
Imágenes correctamente dimensionadas
Servir una imagen de 3000x2000 cuando se renderiza a 800x533 es desperdicio de bandwidth y CPU. WordPress genera tamaños responsivos automáticamente; usa el atributo srcset para que el navegador elija el tamaño correcto.
Formato WebP o AVIF
WebP pesa ~30% menos que JPEG con calidad equivalente. AVIF pesa 50% menos pero tiene soporte ligeramente menor. BerqWP y otros plugins de optimización convierten automáticamente. La diferencia en LCP de un hero JPEG vs WebP puede ser 400-800 ms en conexiones móviles.
Optimización INP: mejorar la responsividad a interacciones
INP es la métrica que más cuesta optimizar en WordPress porque cada plugin agrega scripts que pueden bloquear el thread principal. La estrategia tiene tres ejes:
Reducir JavaScript total
Audite los scripts de su sitio. Plugins que cargan JS en todas las páginas cuando solo lo necesitan en una específica son enemigos directos de INP. Usar plugins como Asset CleanUp o el módulo Page Builder Heartbeat de SEOPress permite cargar scripts solo donde se usan.
Defer y async en scripts no críticos
Cualquier script que no sea crítico para el renderizado inicial debe llevar atributo defer. Esto incluye GA4, GTM, Meta Pixel, scripts de chat, scripts de redes sociales. La diferencia: scripts síncronos bloquean el parsing del HTML; scripts con defer se ejecutan después de DOMContentLoaded.
Romper tareas largas con yielding
Si un script tiene una tarea de 250 ms, divídala en chunks usando setTimeout, requestIdleCallback o la API moderna scheduler.yield(). Cada vez que cede el thread, el navegador puede atender la interacción del usuario y INP mejora drásticamente. Esto es trabajo de desarrollador, no de plugin.
Cuidado con event handlers pesados
Un event handler de click que ejecuta lógica compleja síncrona empeora INP directamente. Mueve trabajo no urgente fuera del handler usando requestAnimationFrame o tareas asíncronas. El usuario debe ver respuesta visual en menos de 200 ms; el resto puede esperar.
Optimización CLS: eliminar saltos de layout
CLS mide cuánto se mueve el contenido durante la carga. Las causas típicas:
- Imágenes sin width/height declarados: el navegador no reserva espacio y cuando la imagen carga, todo lo que está debajo salta.
- Web fonts que cargan tarde: el navegador renderiza con fuente fallback, luego cambia a la fuente custom y los anchos cambian (FOUT).
- Anuncios o embeds inyectados sin contenedor de tamaño fijo: aparecen y empujan contenido.
- Banners de cookies que aparecen tras 2 segundos: shift en la parte superior.
Soluciones concretas
Para imágenes: siempre declarar width y height (o usar aspect-ratio en CSS). WordPress hace esto bien por defecto desde la versión 5.5, pero plugins de page builder a veces lo rompen.
Para fuentes: usar font-display: swap y precargar las fuentes principales con . Si la fuente custom es muy diferente a la fallback, considere font-size-adjust para minimizar el cambio de métrica.
Para banners y embeds: reservar espacio fijo con CSS (min-height) antes de que carguen.
WordPress + LiteSpeed + Cloudflare: el stack de máximo rendimiento
Después de optimizar decenas de sitios WordPress en Colombia, el stack que consistentemente entrega scores de 95+ en PageSpeed es: hosting LiteSpeed + LSCache (o BerqWP) + Cloudflare CDN con cache agresivo + tema bien construido (Divi 5 con su nueva arquitectura sin shortcodes legacy es válido).
Por qué LiteSpeed sobre Apache o Nginx tradicional
LiteSpeed sirve HTML cacheado a velocidad nativa de C++ sin pasar por PHP. La diferencia con Apache + WP Super Cache es que LSCache se invalida automáticamente cuando publicas/editas, sin lógica externa. TTFB típico con LSCache: 50-120 ms desde Colombia.
Cloudflare como capa CDN + edge cache
Cloudflare cachea recursos estáticos (imágenes, CSS, JS) en su edge global. Para visitas desde fuera de Colombia, esto reduce latencia drásticamente. Para visitas locales, también ayuda porque Cloudflare tiene PoP en Bogotá y Medellín. Configuración recomendada: cache level “Standard”, browser cache TTL “Respect existing headers”, APO activado si tiene plan Pro.
BerqWP: la alternativa especializada para Divi
Si usa Divi, BerqWP está diseñado específicamente para no romper el constructor visual mientras optimiza. Hace minificación CSS/JS, lazy loading, conversión WebP, y critical CSS automático. La integración con Cloudflare permite purga sincronizada en ambas capas.
Para llevar su sitio al siguiente nivel técnico, considere mi auditoría SEO técnica con análisis de Core Web Vitals: reviso las tres métricas, identifico el cuello de botella específico y entrego plan de optimización priorizado por impacto.
Imágenes WebP, lazy loading y preload de hero
Las imágenes son el mayor peso de cualquier sitio. La optimización tiene cuatro frentes:
Conversión a WebP/AVIF
BerqWP, Imagify, ShortPixel o el módulo de imágenes de LSCache convierten automáticamente. WebP tiene soporte universal en 2026 (98%+ de navegadores); AVIF lo tiene en 92% pero pesa menos.
Lazy loading nativo
WordPress agrega loading=“lazy” a imágenes fuera del viewport desde la versión 5.5. Verifique que su tema no lo deshabilite. Para el hero (above the fold), quitar el lazy: cargar el hero con prioridad alta usando fetchpriority=“high”.
Dimensionamiento responsivo
WordPress genera múltiples tamaños (thumbnail, medium, large, full) y los sirve via srcset. Si subes una imagen de 4000px y se renderiza a 800px en móvil, el navegador descarga solo el tamaño 1024px (el más cercano superior). Este comportamiento está activo por defecto pero algunos page builders lo rompen.
Preload del LCP
El elemento que será LCP (típicamente la primera imagen del hero) debe llevar en el . Esto le dice al navegador “descarga esto antes de continuar parseando”. Mejora LCP entre 200-600 ms.
JavaScript: defer, async y critical rendering path
JavaScript bloquea el render. Cada script síncrono pausa el parser HTML hasta que se descarga, parsea y ejecuta. La estrategia para minimizar el impacto:
Critical CSS inline
El CSS necesario para renderizar el contenido above-the-fold debe estar en línea en el . El resto del CSS se carga con con onload. BerqWP y plugins similares automatizan esto.
Defer en scripts no críticos
GA4, GTM, Meta Pixel, scripts de chat, comentarios, redes sociales: todos llevan defer. La regla práctica: si el script no es necesario para que el usuario vea contenido en el primer paint, va con defer.
Async para scripts de terceros independientes
Async se ejecuta tan pronto se descarga (rompiendo orden). Útil para scripts que no dependen de otros: tracking de conversiones, A/B testing tools simples. No usar async en jQuery o scripts que tienen dependencias.
Eliminar scripts inútiles
Cada plugin que instala suma scripts y CSS. La auditoría brutal pero efectiva: enumere todos los scripts cargados (en DevTools → Network → JS) y pregunte para cada uno: “¿este sitio funciona sin él?” Si la respuesta es sí, desactívelo o reemplace el plugin.
Para una estrategia integral que combine velocidad técnica con visibilidad, lea mi guía GEO 2026 sobre AI Overviews y ChatGPT: en 2026 la velocidad alimenta tanto a Google como a los crawlers de IA.
Caso real: de 35 a 95 en PageSpeed con números
Un cliente B2B en Bucaramanga llegó con PageSpeed móvil de 35 y desktop de 62. Métricas iniciales:
- LCP móvil: 5,8 segundos (Poor)
- INP móvil: 480 ms (Poor)
- CLS móvil: 0,28 (Poor)
- TTFB: 920 ms
- Transferencia total: 4,2 MB
Diagnóstico
Hosting compartido sin LSCache. 23 plugins activos, 8 sin uso real. Imágenes JPG sin optimizar (hero de 1,8 MB). Sin lazy loading. Sin Cloudflare. Tema con tres sliders en home cargando JS pesado. Web fonts custom sin preload.
Plan ejecutado en 3 semanas
Semana 1: migración a hosting LiteSpeed con LSCache, instalación de Cloudflare con APO, eliminación de 8 plugins inútiles. Resultado intermedio: PageSpeed móvil 58.
Semana 2: BerqWP configurado con WebP + critical CSS + minificación, optimización del hero (preload + fetchpriority + WebP), declaración width/height en todas las imágenes, fonts con font-display:swap + preload. Resultado intermedio: PageSpeed móvil 78.
Semana 3: defer en GA4 + GTM + Meta Pixel, eliminación de dos sliders por imagen estática + CSS, audit final de scripts. Resultado final: PageSpeed móvil 95, desktop 99.
Métricas finales
- LCP móvil: 1,9 segundos (Good)
- INP móvil: 145 ms (Good)
- CLS móvil: 0,03 (Good)
- TTFB: 110 ms
- Transferencia total: 1,1 MB
Tres semanas, sin cambiar el diseño visual del sitio. La diferencia: tener un proceso técnico ordenado que ataca cada métrica en el orden correcto. Si necesita resultados similares, contácteme como consultor SEO certificado en performance para una auditoría inicial.
