Core Web Vitals en 2026: Qué Cambió y Qué Sigue Importando para el SEO

Si no has revisado tus Core Web Vitals desde el lanzamiento inicial en 2021, probablemente estás fallando el umbral de INP y no lo sabes todavía.

Google reemplazó First Input Delay por Interaction to Next Paint en marzo de 2024. Eso fue hace dos años. Para 2026, INP está completamente integrado en el algoritmo de ranking de Google, no como una señal suave sino como un factor de ranking directo dentro del conjunto de Page Experience. La actualización de marzo de 2026 cambió la forma en que Google evalúa estas métricas — pasando de datos de laboratorio (Lighthouse) a datos de usuarios reales (CrUX) como la señal principal para las decisiones de ranking.

El mercado de arquitectura serverless, que impulsa gran parte del stack web moderno necesario para alcanzar estas métricas, alcanzó los $22.3 mil millones en 2026 según Industry Research, con una CAGR proyectada del 22.15% hasta 2035. Plataformas de edge computing como Cloudflare Workers (más de 330 ubicaciones, arranques en frío de menos de un milisegundo) y Vercel Edge Functions se están convirtiendo en el destino de despliegue por defecto para sitios que necesitan pasar Core Web Vitals a escala.

Pero aquí está el asunto: la mayoría de los sitios no fallan por la infraestructura. Falla por JavaScript.

Las Tres Métricas en 2026

Google simplificó sus Core Web Vitals a tres métricas, y los umbrales no han cambiado desde 2024. Lo que cambió es cuán estrictamente Google las aplica.

LCP (Largest Contentful Paint) — objetivo: menos de 2.5 segundos. Mide el rendimiento de carga. La métrica se ha vuelto más difícil de pasar porque los sitios modernos cargan más recursos — fuentes, imágenes, scripts de terceros — que en 2021. El LCP medio para sitios móviles en 2026 es de aproximadamente 3.8 segundos, según datos de CrUX recopilados por HTTP Archive. Solo alrededor del 45% de las páginas móviles pasan el umbral Good.

INP (Interaction to Next Paint) — objetivo: menos de 200 milisegundos. Reemplazó a FID y mide la capacidad de respuesta en todo el ciclo de vida de la página, no solo la primera interacción. Esta es la métrica que la mayoría de los sitios están fallando sin darse cuenta. FID solo medía el retraso entre la interacción del usuario y el momento en que el hilo principal comenzaba a procesar el manejador de eventos. INP mide el recorrido completo — desde la interacción hasta el siguiente pintado que muestra retroalimentación visual. Una página con JavaScript pesado que bloquea el hilo principal durante el desplazamiento o los clics fallará INP incluso si carga rápido.

CLS (Cumulative Layout Shift) — objetivo: menos de 0.1. Mide la estabilidad visual. La mayoría de los sitios que fallan CLS lo hacen por anuncios, medios incrustados o fuentes web que cargan después del render inicial. La solución suele ser directa: reservar espacio para el contenido dinámico antes de que cargue.

Qué Cambió Realmente la Actualización de Marzo 2026

La actualización de Core Web Vitals de marzo de 2026 introdujo tres cambios que importan para cualquiera que gestione un sitio web.

Los datos de usuarios reales son ahora la señal principal. Anteriormente, Google usaba una combinación de datos de laboratorio (simulaciones de Lighthouse) y datos de campo (Chrome UX Report). La ponderación de marzo de 2026 se desplazó fuertemente hacia los datos de campo de CrUX. Esto significa que tu puntuación de Lighthouse importa menos que cómo los usuarios reales en dispositivos reales experimentan tu sitio. Una página que obtiene 100 en Lighthouse pero tiene INP lento para usuarios en teléfonos Android de gama media seguirá posicionándose mal.

El umbral de "URL pobre" se endureció. Anteriormente, un sitio podía tener hasta el 25% de las URLs en la categoría Poor y aún así considerarse que pasaba. La actualización de marzo de 2026 redujo ese umbral al 15%. Si más del 15% de tus URLs fallan en cualquiera de las tres métricas, el ranking de todo tu sitio se ve afectado.

El seguimiento de interacciones se volvió más granular. INP ahora captura interacciones respaldadas por scroll — casos donde un usuario intenta interactuar con un elemento durante un evento de scroll y el navegador no puede seguir el ritmo. Estas interacciones se excluían previamente de la medición. Incluirlas ha reducido significativamente las tasas de aprobación, especialmente en páginas con mucho contenido.

Un sitio que monitoreamos pasó del 72% de aprobación de INP al 44% después de la actualización de marzo de 2026. Su código no había cambiado. Google cambió lo que contaba.

Dónde Falla la Mayoría de los Sitios

He estado revisando datos de CrUX en los sitios que gestionamos y auditamos. Los patrones de fallo son consistentes.

Los scripts de terceros son el mayor asesino de INP. Etiquetas de analítica, widgets de chat en vivo, librerías de A/B testing, plataformas de gestión de consentimiento — cada uno compite por tiempo en el hilo principal. Un sitio típico carga de 8 a 12 scripts de terceros en cada página. Cada script que se ejecuta en el hilo principal añade un retraso medible a cada interacción del usuario. El sitio medio pierde aproximadamente 150-200ms de presupuesto de INP solo por scripts de terceros.

La optimización de imágenes sigue estando rota para LCP. A pesar de la conciencia generalizada sobre LCP, la mayoría de los sitios aún sirven imágenes hero que son demasiado grandes, mal comprimidas o cargadas con atributos que bloquean el renderizado. La solución es mecánica: servir WebP o AVIF, establecer ancho y alto explícitos, usar fetchpriority="high" en la imagen hero y precargarla en el head del documento. Pero todavía veo sitios cargando su imagen hero como background-image en CSS, que no se puede precargar y retrasa LCP entre 0.5 y 1.5 segundos.

La carga de fuentes causa problemas tanto de LCP como de CLS. Las fuentes web personalizadas que bloquean el render retrasan LCP. Las fuentes que cambian después del render causan CLS. La solución: usar font-display: swap con una fuente de respaldo que tenga métricas similares, precargar tu archivo de fuente principal y subdividir tus fuentes para incluir solo los caracteres que tu contenido realmente usa.

Correcciones Prácticas que Funcionan

Esto es lo que hemos encontrado que realmente mueve la aguja en datos de usuarios reales, no solo en puntuaciones de Lighthouse.

Para INP

Divide las tareas largas. Cualquier JavaScript que se ejecute por más de 50 milisegundos bloquea el hilo principal y degrada INP. Usa yield o setTimeout para dividir tareas largas. Carga en lazy los scripts no críticos. Mueve la analítica y el seguimiento a web workers o usa requestIdleCallback.

Difiere los scripts de terceros. Carga scripts de terceros no críticos con async o defer. Mejor aún, cárgalos condicionalmente basado en la interacción del usuario — carga el widget de chat solo cuando el usuario haga clic en el botón de chat, no en cada carga de página.

Usa content-visibility: auto. Esta propiedad CSS difiere el renderizado de elementos fuera de pantalla hasta que el usuario se desplaza cerca de ellos. Reduce el trabajo del hilo principal durante la carga inicial y acelera la capacidad de respuesta de las interacciones.

Para LCP

Precarga la imagen hero. Añade <link rel="preload" href="hero.webp" as="image"> en el head del documento. Esto le dice al navegador que empiece a descargar la imagen antes de que encuentre la etiqueta img en el HTML.

Usa una CDN con optimización de imágenes. Cloudflare Images, Cloudinary o imgix pueden redimensionar, comprimir y convertir imágenes sobre la marcha. Una imagen hero de 2MB comprimida a 200KB con AVIF entrega la misma calidad visual al 10% del tamaño de archivo.

Elimina recursos que bloquean el render. El CSS crítico debe ir inline en el head del documento. El CSS no crítico y JavaScript deben cargarse después del render inicial.

Para CLS

Establece dimensiones explícitas en todos los medios. Cada imagen, video, iframe y espacio publicitario necesita atributos de ancho y alto. Sin ellos, el navegador no puede reservar espacio y el diseño se desplaza cuando el contenido carga.

Usa aspect-ratio en CSS. Para imágenes responsivas, establece aspect-ratio: 16/9 (o la proporción que tenga tu imagen) junto con width: 100%. Esto le dice al navegador las dimensiones proporcionales antes de que la imagen cargue.

Reserva espacios para anuncios. Inicializa los espacios publicitarios con un contenedor de altura fija que coincida con el tamaño esperado del anuncio, incluso antes de que el contenido del anuncio cargue.

Cuándo Ayuda el Edge Computing

El edge computing se menciona como una solución milagrosa para el rendimiento web. No lo es — pero ayuda con problemas específicos.

Cloudflare Workers puede ejecutar transformación de solicitudes, A/B testing, personalización y lógica de autenticación en el edge, cerca del usuario. Esto elimina viajes de ida y vuelta a un servidor central y reduce el TTFB (Time to First Byte) entre 100 y 300ms para usuarios lejos de tu origen.

Los datos del mercado de arquitectura serverless lo respaldan: $22.3 mil millones en 2026, creciendo rápido. Pero el edge computing no es un reemplazo para buenas prácticas de front-end. Si tus bundles de JavaScript son de 800KB, mover tu servidor al edge no arreglará tu puntuación de INP.

El caso de uso correcto para edge functions: verificaciones de autenticación, redirecciones por geolocalización, manipulación de cabeceras, agregación de solicitudes de API. El caso de uso incorrecto: ejecutar toda la lógica de tu aplicación en el edge porque no optimizaste tu front-end.

Construyendo una Cultura de Rendimiento

Los sitios que consistentemente pasan Core Web Vitals no son los que tienen la mejor infraestructura. Son aquellos donde el rendimiento es parte del flujo de trabajo de desarrollo, no una auditoría posterior al lanzamiento.

Establece un presupuesto de rendimiento en tu pipeline CI/CD. Bloquea despliegues que empujen una página por encima de 300KB de JavaScript o añadan más de 200ms a la mediana de INP. Usa Lighthouse CI o sitespeed.io para detectar regresiones antes de que lleguen a producción.

Monitorea datos de usuarios reales en tu analítica. Los datos de CrUX se actualizan mensualmente y vienen con un retraso de 28 días. Usa la API de CrUX o una herramienta RUM (Real User Monitoring) como SpeedVitals o Request Metrics para obtener datos diarios sobre cómo los usuarios reales están experimentando tu sitio.

En Mintec, construimos experiencias web que pasan Core Web Vitals por diseño, no por adaptación posterior. Nuestro proceso de desarrollo incluye presupuestos de rendimiento, monitoreo de usuarios reales y auditorías regulares contra los últimos umbrales de Google.

Explora nuestros servicios de diseño y desarrollo web →

Para más sobre arquitectura web moderna, revisa nuestra guía sobre headless CMS en 2026, nuestro análisis de por qué el comercio headless mejora la velocidad, y las características de un sitio web verdaderamente profesional.

Fuentes

• Google, "Interaction to Next Paint (INP)" — web.dev (https://web.dev/articles/inp)
• backlynk.io, "Core Web Vitals INP 2026: Datos de Usuarios Reales y Umbral de 200ms" (https://backlynk.io/blog/core-web-vitals-inp-2026-interaction-to-next-paint-real-user-data-200ms-threshold/)
• Industry Research, "Mercado de Arquitectura Serverless, Tendencias y Pronóstico 2026–2035" (https://www.industryresearch.co/market-reports/serverless-architecture-market-310787)
• digitalapplied.com, "Edge Computing: Guía de Desarrollo de Cloudflare Workers 2026" (https://www.digitalapplied.com/blog/edge-computing-cloudflare-workers-development-guide-2026)
• CrUX / HTTP Archive, "Web Almanac 2025 — Rendimiento" (https://almanac.httparchive.org/en/2025/performance)