¿Ralentizan los banners de cookies tu web?

Un banner de cookies puede ralentizar tu sitio, pero el banner casi nunca es la parte cara. El script que lo dibuja es pequeño. El coste llega en el momento en que alguien acepta, cuando todas las herramientas de analítica, publicidad y sesión que el banner retenía se disparan a la vez, en un solo hilo principal, después de que tu página ya haya pintado.
Dos cosas distintas reciben el nombre de "el banner"
Cuando alguien dice que su banner de cookies ha ralentizado el sitio, normalmente está describiendo uno de dos costes distintos, y la diferencia decide qué hacer al respecto.
El primero es la propia capa de consentimiento: un script que decide si mostrar un diálogo, lo dibuja, guarda la respuesta y la difunde. Ese trabajo es realmente pequeño. Un script de consentimiento es un diálogo y algo de estado, y los que están bien hechos cargan de forma asíncrona y reservan su propio espacio.
El segundo es todo lo que la capa de consentimiento estaba reteniendo. Tu gestor de etiquetas, la analítica, los píxeles publicitarios, la grabación de sesión, el widget de chat. Nada de eso se ejecutó mientras la visita decidía. Todo se ejecuta en el instante en que acepta y, como la liberación ocurre después de que la página haya pintado, aterriza en un hilo principal que la visita ya está intentando usar.
Lo que implica algo que casi todos los consejos de rendimiento se saltan: quien rechaza recibe una página sensiblemente más rápida que quien acepta. No estás sirviendo un sitio. Estás sirviendo dos, y tu monitorización los está promediando.
Las cuatro formas en que un banner sí te cuesta
Los mecanismos están bien documentados, y los cuatro tienen solución.
Render blocking. Un script de consentimiento cargado sin async ni defer retiene el parser mientras se descarga. Ese retraso llega antes de que tu página pueda pintar nada, incluso en visitas repetidas donde la respuesta ya está guardada y el banner no va a aparecer nunca.
El banner se convierte en tu Largest Contentful Paint. Si cubre una parte grande del viewport y llega más tarde que tu hero, el navegador mide el banner en lugar de tu contenido. El umbral de Google es de 2.5 segundos, y un banner que pinta a los 3 segundos acaba de decidir tu puntuación.
Layout shift. Un banner inyectado en el flujo del documento en lugar de superpuesto empuja hacia abajo todo lo que hay debajo. Cumulative Layout Shift debería quedarse por debajo de 0.1, y una barra a todo el ancho que aparece medio segundo tarde se gasta ese presupuesto ella sola.
El propio clic de aceptar. Cuando el manejador de consentimiento inicializa cuatro proveedores de forma síncrona, el clic que cierra el banner congela la página. Interaction to Next Paint debería quedarse por debajo de 200 milisegundos. Este lo nota la gente sin saber cómo se llama, porque es el que da sensación de estar roto.
Por qué tu puntuación de PageSpeed no ve la ruta cara
Aquí está el hueco que deja casi cualquier artículo sobre este tema. Lighthouse y PageSpeed Insights cargan tu página en un perfil limpio, sin consentimiento guardado, toman sus mediciones y paran. Nunca hacen clic en nada. Así que el estado que miden es el estado previo a la elección: tu página, más un banner, con toda la pila de etiquetas todavía retenida detrás de un botón que nadie ha pulsado.
Es una vista legítima de una primera visita. También es la página más barata que sirves. La ruta de aceptación, el estado más pesado que tiene tu sitio, no aparece nunca en la puntuación de laboratorio, así que los equipos optimizan el único número que ven mientras la ruta cara pasa años sin medirse. Tienes que ir a mirarla a propósito, y lleva unos diez minutos.
Cómo medir tu propio banner, en las dos rutas
Consigue una referencia con el banner desactivado
Traza la página con el script de consentimiento bloqueado del todo, desde el panel de bloqueo de peticiones de tu navegador. Ese es el suelo. Sin él no puedes distinguir el coste del consentimiento del coste de lo que el consentimiento libera.
Mide el estado que ve una primera visita
La ejecución por defecto de PageSpeed Insights: perfil nuevo, sin elección guardada, banner en pantalla. La diferencia con el suelo es el coste honesto del banner en sí, y en uno bien hecho es pequeño.
Graba la ruta de aceptación a mano
Abre el panel de rendimiento, empieza a grabar, carga la página, haz clic en aceptar y sigue grabando unos segundos. Ahora puedes ver lo que aterriza de verdad: cuántas peticiones dispara la elección y cuánto tiempo se queda bloqueado el hilo principal. Ninguna puntuación automática te va a enseñar esto, y por eso muy poca gente lo ha mirado.
Graba también la ruta de rechazo
Repite la traza y haz clic en rechazar. En un sitio con Consent Mode v2 conectado deberías seguir viendo salir peticiones de Google, sin identificadores. Ese es el diseño funcionando como toca, no una fuga, y vale la pena confirmarlo con tus propios ojos antes de que alguien te diga lo contrario.
Divide tus datos de campo por estado de consentimiento
Las trazas de laboratorio te dicen lo que puede pasar; los datos de campo te dicen lo que pasa. Una monitorización mezclada entre todas las visitas promedia una ruta de rechazo rápida con una ruta de aceptación lenta y esconde las dos. Si la tuya admite una dimensión personalizada, marca en ella el estado del consentimiento y lee las dos poblaciones por separado.
Qué cambia Consent Mode y qué no
Mucha documentación sigue describiendo el consentimiento como un interruptor rígido: ningún script se ejecuta hasta que la visita dice que sí. Así se comporta una capa de consentimiento que bloquea, y no es en absoluto como se comporta un sitio con Consent Mode v2. Con el Consent Mode avanzado, las etiquetas de Google cargan en todas las páginas sea cual sea la respuesta; la señal cambia lo que pueden almacenar y enviar, no si existen. Así que si tu plan para tener un sitio más rápido era condicionar las etiquetas de Google al consentimiento, el peso no desaparece. Solo quitar una etiqueta elimina su coste.
Merece la pena nombrar el intercambio con honestidad, porque es la razón real para aceptar ese peso. Conectar las señales de v2 es lo que permite a Google modelar las conversiones que un rechazo borraría, y eso, en el trabajo de Amplio Data con clientes, recupera entre un 20 y un 40 por ciento de la medición que te cuesta un banner de consentimiento. Son rangos medidos en implementaciones de clientes de Amplio Data, no una garantía. La recuperación depende de tu mezcla de tráfico, de las regiones y de cómo estén configuradas tus etiquetas. Un montaje que bloquea es una página algo más rápida que informa de menos de lo que ocurrió en ella.
El suelo que no puedes optimizar
Parte de este coste es permanente, y fingir lo contrario es como los proveedores acaban prometiendo cosas que no pueden cumplir. Siempre pagarás por el script que decide si mostrar un diálogo, por leer la respuesta guardada antes de que se inicialicen tus etiquetas y por las etiquetas que de verdad necesitas.
Lo que sí puedes quitar es el resto: la carga síncrona, la barra inyectada tarde y sin espacio reservado, los cuatro proveedores que se inicializan con un solo clic, la etiqueta que nadie mira desde 2023. Según nuestra experiencia, esa última suele ser la mayor mejora disponible, y no tiene nada que ver con el consentimiento.
La velocidad importa también por un segundo motivo, que tratamos en subir las tasas de aceptación sin dark patterns: un banner que se atasca se cierra por impaciencia, no por preferencia.
El enfoque de Velo es el aburrido. Servir la capa de consentimiento desde el edge, mantenerla asíncrona, reservar su espacio para que nada se mueva y entregar la elección a tus etiquetas lo bastante rápido como para que nada aguas abajo tenga que esperar. La ingeniería interesante está en lo que pasa después de la respuesta, no en el diálogo que la recoge.
Preguntas habituales
Lo que la gente pregunta sobre este tema.
¿Los banners de cookies ralentizan tu web?
Un banner de cookies puede ralentizar tu sitio, pero el script del banner casi nunca es la parte cara. La mayor parte del coste llega después de que alguien acepta, cuando las herramientas de analítica, publicidad y sesión que el banner retenía se inicializan todas a la vez en el hilo principal. Un banner pequeño, cargado de forma asíncrona y con espacio reservado para que no desplace el contenido, suma muy poco por sí solo.
¿Las cookies en sí ralentizan una web?
No. Las cookies son unos cientos de bytes que viajan en peticiones que ya estabas haciendo. Lo que la gente percibe como lentitud por cookies es el JavaScript de terceros que las escribe: gestores de etiquetas, analítica, píxeles publicitarios y grabación de sesión. Quitar una cookie no cambia nada en la velocidad de la página; quitar el script que la escribe cambia mucho.
¿Un banner de cookies perjudica al SEO o a los Core Web Vitals?
Puede afectar a los Core Web Vitals, que son una señal de posicionamiento. Un banner inyectado después de que la página pinte provoca layout shift, uno cargado de forma síncrona retrasa el pintado, y un manejador de consentimiento pesado en el clic de aceptar perjudica la capacidad de respuesta. Nada de eso es inevitable. A los rastreadores no se les muestra un banner y nunca hacen clic en uno, así que el banner en sí no bloquea la indexación.
¿Puede un banner de cookies convertirse en el elemento LCP?
Sí, y más a menudo de lo que se espera. Si el banner cubre una parte grande del viewport y pinta más tarde que el contenido de tu hero, el navegador mide el banner como tu largest contentful paint. La solución es mantenerlo lo bastante pequeño o lo bastante temprano como para que nunca sea lo más grande de la pantalla en el momento equivocado.
Tu banner, tu consentimiento,
tus datos — todo en un mismo sitio.

