Core Web Vitals 2026 para pymes: lo que vi midiendo 20 webs reales

Llevo unas semanas midiendo Core Web Vitals (CWV) con datos de campo reales (CrUX) en una muestra de 20 webs de pymes españolas que audité o gestiono. La conclusión corta: la mitad están suspendidas en LCP o INP, casi todas están bien en CLS, y la gran mayoría podría arreglarse con 3-5 cambios concretos sin tocar el diseño.

Este post es lo que vi, qué cambios sí mueven la aguja, y qué cosas «de manual» no aportan.

Recordatorio rápido de las tres métricas

Métrica	Qué mide	Umbral verde
LCP (Largest Contentful Paint)	Cuánto tarda en pintarse el elemento más grande visible	< 2,5 s
INP (Interaction to Next Paint)	Cuánto tarda en responder a la primera interacción del usuario	< 200 ms
CLS (Cumulative Layout Shift)	Cuánto se mueven los elementos visualmente durante la carga	< 0,1

Importante: lo que pesa para SEO es el dato de campo (CrUX), no el lab Lighthouse. Lighthouse simula; CrUX mide usuarios reales en Chrome con datos sincronizados. Búscalo en Search Console → Experiencia → Core Web Vitals, o en PageSpeed Insights pestaña «Field Data».

Los datos de las 20 webs

Foto agregada (no nombres):

• LCP en verde (< 2,5 s): 11 / 20 (55%).
• LCP en ámbar (2,5-4 s): 7 / 20 (35%).
• LCP en rojo (> 4 s): 2 / 20 (10%).
• INP en verde (< 200 ms): 9 / 20 (45%).
• INP en ámbar (200-500 ms): 8 / 20 (40%).
• INP en rojo (> 500 ms): 3 / 20 (15%).
• CLS en verde (< 0,1): 17 / 20 (85%).
• CLS en ámbar o rojo: 3 / 20.

Lo más sorprendente: INP pesa más de lo que la gente piensa. Es la métrica que reemplazó a FID en marzo 2024 y muchas webs hechas hace 2-3 años no se han adaptado.

LCP: las 3 causas reales en las 9 webs suspensas

Causa 1: imagen hero sin optimizar

7 de las 9 webs con LCP no-verde tenían hero con imagen JPG pesada (300 KB - 1,2 MB) sirviéndose sin WebP/AVIF y sin loading="eager" correcto.

Fix concreto:

• Convertir hero a WebP (~30% del peso del JPG con misma calidad visual). Si soportas AVIF, mejor.
• Asegurar loading="eager" y fetchpriority="high" en el hero.
• Definir width y height explícitos para que el navegador reserve el espacio (también ayuda con CLS).
• Si usas Next.js, <Image priority> con quality={85} lo suele dejar resuelto.

Resultado típico tras este cambio: LCP baja de 3,8 s a 2,1 s en mobile 4G real.

Causa 2: bloque de fuente custom sin font-display: swap

4 de las 9 sufrían FOIT (Flash Of Invisible Text) porque la fuente custom se cargaba sin font-display: swap. El texto del hero solo se pinta cuando llega la fuente.

Fix concreto:

• Añadir font-display: swap; en cada @font-face.
• Self-host las fuentes (no cargar desde Google Fonts directo) para reducir el handshake DNS extra.
• Subset las fuentes a los caracteres reales que necesitas (latin para ES).
• Preload del archivo .woff2 más crítico con <link rel="preload" as="font" type="font/woff2" crossorigin>.

Resultado: 600-900 ms de mejora en LCP sin tocar contenido.

Causa 3: scripts third-party bloqueantes

2 webs con LCP malo tenían 3-5 scripts third-party (chat widgets, píxeles de tracking, herramientas de A/B testing) cargando antes que el contenido.

Fix concreto:

• Cargar todos los scripts no críticos con defer o async.
• Mover el chat widget para que solo cargue al pasar 3 s o al primer scroll.
• Quitar herramientas A/B testing que ya no usas (común).
• Si usas Next.js, <Script strategy="lazyOnload"> para todo lo no esencial.

INP: el silencioso que está suspendiendo el 55% de webs

INP reemplazó a FID en marzo 2024. Mide cuánto tarda el sitio en responder cuando el usuario hace algo (tap, click, scroll significativo). Las 11 webs que medí con INP no-verde compartían 2 causas:

Causa 1: JavaScript bloqueante en el thread principal

JS de terceros (Google Analytics, Hotjar, Intercom, etc.) o JS propio mal optimizado bloquea el main thread durante la carga inicial. El usuario hace tap → el navegador no puede responder hasta que termine el script.

Fix concreto:

• Auditar con Chrome DevTools → Performance → Main thread, buscar tareas > 50 ms.
• Mover lógica pesada a Web Workers.
• Code-splitting agresivo: cargar JS por ruta, no global.
• Eliminar JS de funcionalidades no usadas (lo más común: librerías de carrusel cargadas en todas las páginas pero usadas solo en home).

Causa 2: React con re-renders innecesarios

5 de las webs con INP malo eran SPAs o webs Next.js mal optimizadas. Cada interacción disparaba un re-render de un árbol grande de componentes.

Fix concreto:

• useMemo y useCallback en handlers que pasan a hijos.
• React.memo en componentes que renderizan listas largas.
• Server Components en Next.js 13+ para mover lógica al servidor.
• Suspense + streaming para que partes interactivas no bloqueen.

Resultado típico: INP de 450 ms baja a 180 ms.

CLS: el casi-resuelto, pero ojo a los 3 casos rebeldes

CLS es la métrica donde la mayoría está OK. Las 3 webs en ámbar/rojo lo tenían por una sola causa: inserción de banners de cookies/ads tarde que empujan el contenido principal hacia abajo.

Fix:

• Reservar el espacio del banner con min-height ANTES de que cargue.
• Si el banner es overlay, posicionarlo fixed o absolute para que no afecte al flow.
• Para anuncios programáticos, usar aspect-ratio o min-height en los slots.

Lo que NO mueve la aguja (te lo van a sugerir igual)

• Activar HTTP/3 en Cloudflare: mejora marginal (50-100 ms) salvo en redes muy lentas. No es prioridad antes de optimizar la página.
• Minificar CSS / JS al máximo: ya lo hace tu bundler. Quitar 5 KB de un bundle de 200 KB no mueve LCP.
• Cambiar de Wordpress a Next.js solo por CWV: si la web tiene contenido bien estructurado, optimizar Wordpress (CDN + caché + imágenes WebP + lazy load) suele bastar. Migración cuesta más de lo que ahorra.
• «Lazy load» en TODO: lazy load en hero baja el LCP (efecto contrario al deseado). Lazy load solo bajo la fold.

Plan a 30 días por orden de impacto

1. Día 1-2: auditar con PageSpeed Insights + Search Console CWV. Identificar las 3 páginas con más impresiones que estén en ámbar/rojo.
2. Día 3-5: optimizar hero de esas 3 páginas (WebP + width/height + priority).
3. Día 6-10: fix de fuentes (font-display: swap + preload).
4. Día 11-15: auditar scripts third-party. Eliminar 2-3 no esenciales. Mover el resto a defer o lazy.
5. Día 16-25: si hay INP malo, auditar con Chrome DevTools y aplicar fixes JS.
6. Día 26-30: re-medir con CrUX (Search Console tarda 28 días en mostrar datos nuevos por la ventana móvil de 28 días que usa).

A 30 días sostenidos, el 70% de las webs PYME pueden pasar las 3 CWV a verde sin reescribir nada del diseño.

Por qué importa esto en 2026

Más allá del SEO clásico (CWV es factor de ranking confirmado desde 2021), en 2026 importa doblemente porque:

• Las IAs generativas (ChatGPT, Perplexity, AI Overviews) penalizan sitios lentos cuando deciden qué citar. Una página lenta es señal de que el sitio no está bien mantenido.
• El usuario móvil promedio en España navega cada vez más por 4G/5G normal, no fibra. La diferencia entre 2,1 s y 3,8 s LCP en mobile es la diferencia entre rebote y conversión.
• Tu competencia local se está poniendo al día. Hace 3 años podías ser el lento del barrio y rankear. Hoy, no.

---

¿Tu web está en ámbar o rojo en CWV? Es lo primero que reviso en una auditoría SEO técnica. Si quieres ir directo al mantenimiento, el SEO técnico mensual incluye monitorización CWV continua.