¿Los banners de cookies perjudican los Core Web Vitals? De dónde viene realmente el coste

Las tres formas en que un banner te cuesta

Los Core Web Vitals son tres números: Largest Contentful Paint, cuánto tarda en dibujarse lo más grande de la pantalla; Cumulative Layout Shift, cuánto se mueve la página mientras carga; Interaction to Next Paint, cuánto tarda la página en responder a un clic. Un banner de consentimiento puede perjudicar cada uno de ellos, pero mediante tres mecanismos distintos, y la sabiduría popular («los banners son lentos») oculta cuál te está pasando a ti.

LCP: el bundle bloqueante

El primer mecanismo es del que más escriben los ingenieros de rendimiento. Muchos gestores de consentimiento sirven un script grande, cargado de forma síncrona en el head, que tiene que descargarse y ejecutarse antes de que el navegador siga analizando la página. El análisis de DebugBear de CMP populares muestra casos en los que el script del banner empuja el LCP de unos 1,4 segundos a 3,6 e inyecta decenas de miles de nodos DOM. Un segundo problema de LCP, más silencioso: si el banner es el elemento más grande del viewport en una pantalla móvil, se convierte en el elemento LCP, y su propio tiempo de renderizado es tu puntuación.

La solución al primero es arquitectónica: el runtime tiene que ser pequeño y no debe bloquear el análisis. La solución al segundo es de diseño: un banner en forma de barra o tarjeta de esquina en vez de un modal a pantalla completa, en la primera visita, en un teléfono.

CLS: el banner tardío

El segundo mecanismo es el desplazamiento de diseño, y casi siempre es autoinfligido. Un banner que se inyecta después del primer pintado y empuja el contenido hacia abajo produce un desplazamiento igual a su propia altura, que en un teléfono es la mayor parte del presupuesto de CLS de 0,1. Los banners que se deslizan sobre el contenido no desplazan nada; los que se insertan en el flujo, sí. La solución es reservar el espacio antes del pintado, o superponer en vez de insertar.

INP: la ráfaga al hacer clic

El tercer mecanismo es el más nuevo y el menos comentado. INP mide el retraso entre una interacción y el siguiente fotograma. El clic que más duele en un sitio con gestión de consentimiento es Aceptar todo: en ese instante el banner libera todos los scripts bloqueados a la vez, y una docena de etiquetas pelean por el hilo principal mientras la página intenta redibujar el cierre del banner. El artículo de SpeedCurve sobre gestores de consentimiento lo señala como la regresión de INP más común que ven. El banner no la causó; la causaron las etiquetas, pero el banner las programó.

La solución es la planificación. Los scripts liberados deberían ejecutarse en orden del documento, cediendo entre ellos, fuera de la ruta crítica de la interacción, para que el banner se cierre primero y los rastreadores vengan después.

Cómo está construido el runtime de CookieCrumbs

• 21 kB comprimidos, un solo archivo. Cargado de forma asíncrona con una larga vida de caché, desde nuestro propio dominio. Instala su interceptor de forma síncrona en unos cientos de bytes de lógica inline y obtiene todo lo demás después, así que nada bloquea el análisis y nada se ejecuta antes de que exista el interceptor.
• Sin peticiones a terceros propias. Sin webfont, sin set de iconos, sin analítica del banner. La tipografía viene del sistema o de tu página.
• Espacio reservado antes del pintado. Los diseños de barra y cinta añaden al documento un relleno de su propia altura mientras están visibles, en el borde en que se sitúen, de modo que nada se mueve. Contribución de CLS medida: 0,00.
• Liberación en orden, cediendo. Al consentir, los scripts bloqueados se recrean en orden del documento con una cesión entre ellos, de modo que el clic se resuelve antes de que se ejecuten los rastreadores.
• No es el elemento LCP. Los diseños por defecto están dimensionados para que tu contenido, no el banner, sea el mayor pintado en un teléfono.

Cómo medir el tuyo

1. Ejecuta PageSpeed Insights en una página con el banner visible (un perfil nuevo, sin cookie de consentimiento). Lee los datos de campo si los tienes; los datos de laboratorio valen para empezar.
2. En el diagnóstico de LCP, comprueba qué elemento es el elemento LCP. Si es el banner, cambia el diseño.
3. En el diagnóstico de CLS, busca un desplazamiento en el momento en que aparece el banner. Si lo hay, el banner se inserta en el flujo.
4. Graba una traza de rendimiento, pulsa Aceptar todo y lee las tareas largas que siguen. Ese es tu coste de INP, y pertenece a las etiquetas que liberaste.
5. Compara en el panel de red el tamaño de transferencia del script del banner y si bloquea el renderizado. Menos de 30 kB y asíncrono es el objetivo.

Luego ejecuta el escaneo gratuito: te dice cuántos rastreadores se liberarán con ese clic, que es el número que le importa al INP.

Fuentes

1. DebugBear, «Cookie consent banners, page speed, and Core Web Vitals»
2. SpeedCurve, «Five ways cookie consent managers hurt web performance (and how to fix them)»
3. Termly, «How to optimize your cookie banner for Core Web Vitals»
4. Google, umbrales de Core Web Vitals en web.dev (LCP 2,5 s, CLS 0,1, INP 200 ms)
5. CookieCrumbs, sección del banner (21 kB, CLS 0,00)

Escrito por el equipo de CookieCrumbs, publicado el 5 de septiembre de 2026. Los datos llevan su fecha; si alguno ha cambiado, avísanos y lo corregiremos.