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étrica | Qué mide | Bueno | Necesita mejora | Pobre |
|---|---|---|---|---|
| LCP | Mayor elemento visible | < 2.5s | 2.5-4.0s | > 4.0s |
| INP | Latencia de interacciones | < 200ms | 200-500ms | > 500ms |
| CLS | Movimiento inesperado | < 0.1 | 0.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 el 80% de problemas en WordPress
Basado en 47 auditorías técnicas de sitios WordPress pymes entre 2024 y 2026 que pasaron de “pobre” a “bueno” en los 3 vitales.
Fix 1 — Optimizar el LCP element (suele ser la imagen hero)
- Serve imágenes en
AVIFoWebP(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
widthyheight(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: swappara 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:
asyncodeferen 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
widthyheightHTML o aspect-ratio CSS. - iframes: contenedor con
aspect-ratiodefinido. - Fonts:
size-adjusten@font-facepara 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 el 60% de 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)
- Diagnóstico de campo: Search Console → Experiencia → CWV. Anota qué métrica falla y en qué porcentaje de URLs.
- 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.
- 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).
- 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).
Cliente de WordPress + Elementor Pro con 18 plugins, tienda WooCommerce mediana (~3.000 sesiones/mes). Core Web Vitals en Search Console: LCP 4.8s (pobre), INP 640ms (pobre), CLS 0.18 (necesita mejora).
Auditoría: el LCP element era la imagen hero en JPG de 1.4MB. INP venía de 3 plugins (chat LiveChat, popup OptinMonster, slider Smart Slider 3) que corrían en todas las páginas. CLS por fuentes sin font-display + un slider sin dimensiones fijas.
Fixes aplicados en 2 jornadas: conversión a AVIF + preload del hero, desactivación de chat LiveChat en 80% de páginas, reemplazo de slider por Swiper nativo con dimensiones fijas, self-host de fuentes. Resultado a los 28 días: LCP 1.9s (bueno), INP 180ms (bueno), CLS 0.06 (bueno). Tráfico orgánico mobile subió 31% en 60 días 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.