Core Web Vitals 2026: nuevos umbrales, INP definitivamente y cómo los garantizamos en cada entrega

Resumen ejecutivo: qué cambia en 2026

• INP (Interaction to Next Paint) reemplaza a FID definitivamente desde marzo 2024. Mide latencia de todas las interacciones, no solo la primera.
• LCP (Largest Contentful Paint): umbral "bueno" se mantiene en ≤ 2.5 s, pero Google pondera más la estabilidad visual del elemento LCP.
• CLS (Cumulative Layout Shift): umbral "bueno" ≤ 0.1, pero ahora se penalizan shifts post-carga (ej. fuentes, anuncios, iframes tardíos).

En Trement nuestro criterio de aceptación interno es ≥ 90 en PageSpeed Insights mobile antes de lanzar. No es aspiración: es definition of done.

INP: la métrica que expone lo que FID ocultaba

FID solo medía el retraso de la primera interacción. INP mide el percentil 98 de todas las interacciones (clicks, taps, teclado). Si tu menú hamburguesa tarda 300 ms en abrir, tu INP es malo aunque el primer click fuera rápido.

Causas típicas de INP alto

1. Main thread bloqueado por JS pesado (hydration, frameworks, third-parties)
2. Event handlers síncronos que hacen trabajo pesado antes de pintar
3. Layout thrashing (leer/escibir layout en bucle)
4. Third-parties sin defer/async (chat widgets, analytics, mapas)

Cómo lo resolvemos en Trement

• Zero-hydration / islands architecture: HTML funcional desde el servidor, JS solo donde hay interactividad real
• Event delegation + requestIdleCallback para trabajo no urgente
• Web Workers para cómputo pesado (filtros, búsquedas, gráficos)
• Third-parties cargados bajo demanda (intersection observer en chat, mapas, videos)
• CSS-first interactions: :hover, :focus-visible, transition en lugar de JS para feedback visual

LCP: más allá del "primer elemento grande"

Google ahora evalúa la estabilidad del elemento LCP. Si tu hero image hace layout shift al cargar la fuente o la imagen, tu LCP "bueno" no cuenta.

Nuestra checklist LCP

• Hero image como con width/height explícitos
• Fuente del headline: preload + font-display: swap + fallback métrico (size-adjust, ascent-override)
• Sin JS bloqueante antes del hero (ni analytics, ni chat, ni A/B testing)
• CDN para assets estáticos (Cloudflare / CloudFront) con Cache-Control: immutable

CLS: los shifts invisibles que te penalizan

En 2026, los shifts post-carga pesan más: fuentes que cambian dimensiones, iframes de mapas/videos sin aspect-ratio, anuncios inyectados, skeletons que no coinciden con contenido real.

Nuestra defensa anti-CLS

• aspect-ratio en todo elemento con dimensiones intrínsecas (imágenes, videos, iframes, mapas)
• Font metrics overrides (ascent-override, descent-override, line-gap-override) para que fallback ocupe mismo espacio que web font
• Skeletons con mismas proporciones que contenido real (no placeholders genéricos)
• Anuncios/embeds en contenedores con min-height reservado

Nuestra pipeline de medición (no confiamos en una sola herramienta)

1. Lighthouse CI en cada PR (budget: LCP < 2.5s, INP < 200ms, CLS < 0.1)
2. PageSpeed Insights API diaria en staging y producción
3. Chrome UX Report (CrUX) mensual para datos de campo reales
4. Web Vitals JS library en producción enviando a GA4/BigQuery para alertas

Tabla de umbrales 2026 (oficiales Google)

¿Tu sitio actual pasa el filtro?

La mayoría de sitios en builders (Elementor, Wix, WordPress + themes pesados) fallan en INP y CLS. En Trement entregamos con reporte PageSpeed ≥ 90 mobile como parte del QA. Si tu proveedor actual no te da ese reporte, no te está entregando un sitio optimizado.

Pide tu auditoría CWV gratis O escríbenos por WhatsApp