Desde marzo 2024, Core Web Vitals dejó de ser “una métrica más de Google” para convertirse en señal de ranking directa en búsqueda mobile. En 2026, los tres vitales son: LCP (carga), INP (interactividad) y CLS (estabilidad visual). Si tu sitio falla en cualquiera de ellos con datos de campo, Google te baja ~12-18 posiciones en mobile según los benchmarks independientes.

Pero aquí está el problema: la mayoría de pymes audita con PageSpeed Insights (datos de laboratorio), ve un 85/100 verde y asume que está bien. PageSpeed te miente con la mejor de las intenciones. Google no te rankea por el número que te muestra PageSpeed — te rankea por los datos reales de tus usuarios (CrUX + Chrome UX Report).

Los 3 Core Web Vitals en 2026 (y los umbrales que importan)

MétricaQué mideBuenoNecesita mejoraPobre
LCPMayor elemento visible< 2.5s2.5-4.0s> 4.0s
INPLatencia de interacciones< 200ms200-500ms> 500ms
CLSMovimiento inesperado< 0.10.1-0.25> 0.25

La regla de pasaje: necesitas el P75 (percentil 75) en “Bueno” para los 3 vitales durante 28 días consecutivos. Si uno solo está en “Necesita mejora” o “Pobre”, tu sitio no pasa.

Campo vs Laboratorio: por qué PageSpeed no alcanza

Hay dos fuentes de datos de rendimiento, y Google solo usa una para rankear:

Laboratorio (Lab Data)

Simulación en servidores Google de un “usuario tipo”. Fibra óptica, Chrome limpio, Moto G4 simulado, sin extensiones. Te lo da Lighthouse, PageSpeed Insights, WebPageTest.

Útil para: debugging, detectar qué componente está lento, comparar antes/después de un fix.

NO útil para: saber si tu sitio pasa Core Web Vitals. Google no rankea con esto.

Campo (Field Data / RUM)

Datos reales de usuarios reales en sus dispositivos reales. Viene del Chrome User Experience Report (CrUX) y lo puedes ver en Search Console o con herramientas RUM (Real User Monitoring).

Útil para: saber si pasas o no pasas, identificar qué segmentos de tu audiencia sufren (mobile vs desktop, 3G vs WiFi).

Limitación: solo disponible si tu sitio tiene suficiente tráfico (Google pide ~mil sesiones/mes mínimo).

Un sitio puede tener 95/100 en PageSpeed y fallar Core Web Vitals

Porque PageSpeed simula una conexión ideal. Tus usuarios chilenos en 4G con celular de 3 años atrás tienen otra realidad. Audita siempre contra datos de campo.

3 herramientas para auditar Core Web Vitals con datos de campo

1 · Search Console (gratis, obligatorio)

Ve a Experiencia → Core Web Vitals. Te muestra la distribución de URLs buenas/necesitan mejora/pobres, segmentado por mobile y desktop. Si tienes menos de 5.000 impresiones/mes, el reporte estará incompleto — en ese caso, complementa con las otras herramientas.

2 · CrUX Dashboard (Looker Studio, gratis)

Dashboard público de Google: g.co/crux-dashboard. Conectas tu dominio y te muestra datos históricos de CrUX mes a mes. Clave para ver tendencias y si un fix mejoró o empeoró.

3 · RUM propietario (Cloudflare, Vercel, New Relic, GA4)

Si necesitas granularidad por página específica o por segmentos (usuarios que convirtieron vs no), necesitas RUM propio. Cloudflare Web Analytics es gratis y suficiente para la mayoría de pymes.

Los 6 fixes que resuelven la mayoría de los problemas en WordPress

A partir de las auditorías técnicas de sitios WordPress pymes que he hecho, estos son los seis arreglos que más veces llevan los tres vitales de “pobre” a “bueno”.

Fix 1 — Optimizar el LCP element (suele ser la imagen hero)

  • Serve imágenes en AVIF o WebP (50-70% menos peso que JPG).
  • Atributo fetchpriority="high" en la imagen del hero.
  • Preload del hero en el <head>: <link rel="preload" as="image" href="...">.
  • Dimensiones explícitas width y height (previene también CLS).

Fix 2 — Reducir JavaScript de plugins

Elementor Pro + 12 plugins = 2.8MB de JS. Cada plugin que agregas empuja INP arriba. Audita con Query Monitor o Asset CleanUp y desactiva scripts por página (ej. los scripts del formulario de contacto no los necesitas en la home).

Fix 3 — Font loading optimizado

  • Self-host las fuentes (no uses Google Fonts vía <link> directo).
  • Usa font-display: swap para evitar FOIT (flash of invisible text).
  • Preload las 1-2 variantes críticas (400 y 700 regular italic no).

Fix 4 — Third-party scripts diferidos

Chat widgets, analytics, pixels, retargeting: todos son third-party que matan INP. Usa:

  • async o defer en todos los <script> no críticos.
  • Delay de Meta Pixel, GTM, Hotjar hasta que el usuario interactúe (plugin Flying Scripts o código custom).
  • Chat widget que carga solo al hover del botón (no al onload).

Fix 5 — CLS: elementos con dimensiones fijas

  • Imágenes: siempre width y height HTML o aspect-ratio CSS.
  • iframes: contenedor con aspect-ratio definido.
  • Fonts: size-adjust en @font-face para que el fallback no cambie el layout cuando carga la real.
  • Banners de cookies: posicionar fijos bottom, NO empujar contenido.
  • Ads inyectados: reserve el espacio antes de que carguen.

Fix 6 — CDN + caché agresiva

  • Cloudflare free tier + APO (USD 5/mes) resuelve buena parte de los problemas de LCP.
  • Caché de página estática en el hosting (LiteSpeed Cache, WP Rocket).
  • Caché de objetos (Redis u Object Cache Pro) si usas WooCommerce.

Auditoría Core Web Vitals en 4 pasos (90 min)

  1. Diagnóstico de campo: Search Console → Experiencia → CWV. Anota qué métrica falla y en qué porcentaje de URLs.
  2. Diagnóstico de laboratorio: corre PageSpeed en las 3 URLs más traficadas (home, landing principal, página más rankeada). Anota el elemento LCP y los scripts bloqueantes.
  3. Priorización por impacto: si INP falla, foco en JS (fix 2, 4). Si LCP falla, foco en imágenes y fonts (fix 1, 3, 6). Si CLS falla, foco en dimensiones fijas (fix 5).
  4. Validación: aplica fix, espera 28 días (ciclo CrUX), re-audita. Si mejoró, siguiente. Si no, revisa que el fix se haya aplicado bien (caché, etc).

Un caso típico que veo: sitio WordPress + Elementor Pro con muchos plugins y una tienda WooCommerce mediana, con los tres Core Web Vitals en rojo en Search Console (LCP y INP “pobre”, CLS “necesita mejora”).

Auditoría: el LCP element era una imagen hero en JPG pesada. El INP venía de un puñado de plugins (chat, popup, slider) que corrían en todas las páginas. El CLS, de fuentes sin font-display y un slider sin dimensiones fijas.

Fixes aplicados en un par de jornadas: conversión a AVIF + preload del hero, desactivación del chat en las páginas donde no aporta, reemplazo del slider por Swiper nativo con dimensiones fijas y self-host de fuentes. Resultado al cerrar el ciclo CrUX: los tres vitales en verde, y una mejora sostenida del tráfico orgánico mobile en los meses siguientes.

Qué NO hacer en 2026

  • No instalar 5 plugins “de optimización” en paralelo. Se pisan entre sí y empeoran el problema.
  • No confiar en un solo número (ni PageSpeed, ni GTmetrix, ni el score promedio). Cada métrica tiene su causa.
  • No auditar una sola vez. Core Web Vitals es un proceso continuo: cada plugin que agregas puede romperlo de nuevo.
  • No olvidar mobile. Google rankea con datos mobile. Si solo testeas en desktop, estás mirando la mitad del problema.