Los tres Core Web Vitals en 2026

Google mide tres métricas de campo primarias para la experiencia de página. Cada una tiene un umbral para el rendimiento "Bueno":

• Largest Contentful Paint (LCP) — tiempo para renderizar el elemento visible más grande. Bueno: menos de 2,5 segundos.
• Interaction to Next Paint (INP) — capacidad de respuesta a todas las interacciones del usuario (reemplazó a FID en marzo de 2024). Bueno: menos de 200 ms.
• Cumulative Layout Shift (CLS) — estabilidad visual durante la carga. Bueno: menos de 0,1.

Un banner de consentimiento que bloquea el renderizado, ejecuta JavaScript pesado en la carga o inyecta cambios tardíos en el diseño puede empujar cualquiera de estos hacia la banda "Necesita mejora" o "Deficiente" — y Google usa datos de campo de 28 días de usuarios reales de Chrome, por lo que los problemas transitorios se convierten en señales de clasificación persistentes.

Cómo los banners de consentimiento perjudican el LCP

El Largest Contentful Paint normalmente se activa en una imagen hero o un titular. Varios patrones de consentimiento lo retrasan innecesariamente:

Scripts CMP que bloquean el renderizado

Cargar el CMP de forma síncrona desde el encabezado del documento detiene el análisis HTML hasta que el script se descarga y ejecuta. Si el CMP está alojado en un CDN lento o tiene caché fría, puedes agregar 200-800 ms al LCP globalmente.

Banner que cubre el elemento hero

Si el banner de consentimiento está posicionado como una superposición modal que cubre el elemento LCP, los navegadores aún medirán el LCP desde el elemento cubierto. Sin embargo, si el banner es el elemento pintado más grande, se convierte en el candidato LCP — y si se renderiza a través de JavaScript después de la carga de la página, el LCP es artificialmente alto.

Solución: Carga asíncrona con pequeño bootstrap en línea

Carga el CMP completo de forma asíncrona (`async` o `defer`), con solo un pequeño script en línea para la visualización inicial del banner. Apunta a un bootstrap de menos de 5 KB comprimido con gzip. La lógica de comportamiento completa, las listas de proveedores y el UI chrome pueden cargarse de forma diferida después del primer pintado.

Cómo los banners de consentimiento perjudican el INP

El Interaction to Next Paint mide el peor tiempo de respuesta en todos los clics, toques y pulsaciones de teclas durante una sesión. Las interacciones de consentimiento de cookies son a menudo la primera interacción que realiza un usuario — por lo que un botón Aceptar lento arruina la puntuación.

Trabajo pesado al Aceptar

Muchos CMP ejecutan trabajo síncrono al Aceptar: cargando más de 40 scripts de proveedores, escribiendo en localStorage, disparando eventos dataLayer, activando actualizaciones de Google Consent Mode. Si esto supera los 200 ms, INP sufre.

Solución: Encolar trabajo después del pintado

Al hacer clic en Aceptar, oculta inmediatamente el banner y programa el trabajo pesado con `requestIdleCallback` o `setTimeout(0)`. El usuario ve que el banner desaparece al instante; los scripts de proveedores se cargan en segundo plano sin bloquear la interacción.

Cómo los banners de consentimiento perjudican el CLS

El Cumulative Layout Shift rastrea el movimiento visual inesperado. Los banners son una fuente clásica de CLS cuando se inyectan en el DOM después de que el contenido se ha pintado.

Inyección tardía del banner

Si el banner aparece 800 ms después del LCP, empuja el contenido hacia abajo y genera un cambio de diseño. Incluso un banner pequeño puede desencadenar una puntuación CLS de 0,1+ si afecta a una gran parte del viewport.

Re-renderizados del widget de preferencias de cookies

Los widgets de preferencias en el pie de página que cargan logos de proveedores de forma asíncrona pueden refluir todo el pie de página múltiples veces, acumulando CLS.

Solución: Reservar espacio de antemano

Usa CSS para reservar el espacio del banner desde el primer pintado — marcador de posición de altura fija, `min-height` en el pie de página o un banner fijado en la parte inferior que no empuje el contenido. Los CMP modernos deben ofrecer una configuración sin CLS de fábrica.

Google Consent Mode V2 y rendimiento

El Consent Mode V2 permite que las etiquetas de Google se ejecuten en un estado sin cookies antes del consentimiento, pasando señales a través de `gtag('consent', 'default', {...})`. Esto es excelente para la continuidad de la medición, pero la propia biblioteca gtag.js tiene 50-90 KB. Cárgala de forma asíncrona y establece los valores predeterminados lo antes posible para evitar condiciones de carrera.

• Establece los valores predeterminados antes de que gtag se cargue — coloca la llamada consent default en el encabezado, antes del script gtag.js.
• Usa `analytics_storage: 'denied'` como valor predeterminado — minimiza los datos recopilados antes del consentimiento.
• Actualiza al Aceptar a través de requestIdleCallback — evita bloquear el hilo principal.

Medición del impacto del CMP en los Core Web Vitals

No adivines — mide. Usa estas herramientas para cuantificar el impacto de tu banner:

• PageSpeed Insights — datos de campo del Chrome UX Report más auditoría Lighthouse de laboratorio. Compara puntuaciones con y sin el script CMP.
• Extensión Web Vitals de Chrome — superposición de LCP, INP, CLS en tiempo real durante las pruebas locales.
• WebPageTest.org — vista de filmstrip y cascada que muestra exactamente cuándo se renderiza el banner y qué bloquea.
• Informe Core Web Vitals de Search Console — datos de campo de 28 días agrupados por patrón de URL. Comprueba si las páginas de destino con tu banner puntúan de manera diferente que las páginas sin él.

Cómo FlexyConsent se mantiene rápido