Barras de cookies y velocidad web

Las barras de cookies implementadas sin optimización de velocidad representan una amenaza bastante seria para la velocidad y, por ende, para las métricas Web Vitals. En este artículo compartiremos con ustedes las experiencias que hemos adquirido trabajando para nuestros clientes.

Probablemente ya sepan que las barras de cookies (también conocidas como "CMP banners") serán obligatorias en la mayoría de los sitios web debido a cambios legislativos. No nos ocuparemos de la legislación (eso lo ha hecho Petra Dolejšová) ni del diseño (analizado por Ondřej Ilinčev), sino que nos centraremos únicamente en cómo no arruinar la velocidad al implementarlas.

Primero, les mostraremos al campeón. La peor barra de cookies posible, que seguramente arruinará sus métricas.

Ahí lo tienen, el campeón en destruir la velocidad web. Cinco segundos en los que no pasa nada. Luego, la barra comienza a desplazar el contenido muy lentamente. Y aún más, ya que se renderiza una imagen realmente grande en ella.

¿Por qué es esto muy malo desde el punto de vista de la velocidad? Reflexionen un poco, seguro que lo descubren.

¿Lo tienen?

Estos son los problemas más importantes que esta barra ocasionará:

1. Se carga tarde, cuando el usuario ya podría estar consumiendo el contenido de la página.
2. El desplazamiento empeora la métrica CLS y, en este caso, de manera muy significativa. Solo la barra de cookies haría que la métrica se disparase a más de cinco veces el valor máximo posible.
3. En el último paso, se renderiza una imagen en la barra de cookies. Idealmente un poco después de la propia barra, mal optimizada y, preferiblemente, más grande que cualquier otro elemento en la página. Tenemos aquí condiciones ideales para destruir la métrica LCP.

Hay muchos campeones de destrucción de velocidad en la web. Y como habrán deducido correctamente, no siempre se trata de barras de cookies...

Ahora veamos los problemas específicos que las barras de cookies pueden causar a las métricas.

Métrica LCP: Renderiza lo antes posible#

Entre los desarrolladores se ha extendido el mito de que el renderizado de contenido como las barras de cookies debe posponerse lo máximo posible. Después de todo, no es el contenido principal de la página.

Esta es una de las grandes equivocaciones que pueden cometer al implementar barras. Desde el punto de vista del usuario, la barra de cookies es el contenido principal y más importante. Idealmente, debería leerla primero, aceptarla y luego continuar en su sitio web.

Además, si han conseguido diseñar la barra de manera que contenga elementos grandes (textos largos o imágenes), podría convertirse en el elemento LCP a partir del cual se calcula la métrica Largest Contentful Paint.

Así que al retrasar la barra, también pueden retrasar la métrica LCP.

Miren la imagen a continuación, hay dos sitios web. Ambos grandes y técnicamente complejos. Para sus desarrolladores es problemático renderizar la barra de cookies a tiempo, incluso después de haber hecho mucho por lograrlo. ¿Cómo se ve esto desde la perspectiva de un usuario con una conexión más lenta?

En ambos casos, la métrica LCP se calcula a partir del contenido de la barra. En el primer caso, la barra aparece más tarde que el diseño web y luego, lamentablemente, se espera la descarga de la imagen.

La segunda variante es ligeramente mejor. Antes de que se descargue la barra, en conexiones lentas se ve un esqueleto que reserva el espacio para el contenido de la barra.

Pueden encontrar más información sobre cómo reservar espacio para componentes en este artículo.

Métrica CLS: No desplaces, no animes#

Ya saben que la métrica Cumulative Layout Shift se ve afectada negativamente por desplazamientos no deseados del contenido. En el ejemplo inicial de una barra realmente mala, vimos los mayores problemas que pueden causar a la métrica CLS (y a los usuarios) con un mal diseño o implementación.

En el contexto de CLS, también tengan cuidado con soluciones específicas. En uno de nuestros clientes, por ejemplo, la implementación de la solución Google Funding Choices empeoró esta métrica tres veces:

Hemos comprobado que en los datos de usuario (Web Vitals del Chrome UX Report) no tuvo un impacto tan grande. Sin embargo, es definitivamente una advertencia contra la implementación ciega de soluciones de terceros.

Prueben. Y midan, midan y midan. Quizás en nuestra prueba de velocidad web.

Con CLS, también tengan cuidado con las animaciones. Probablemente sepan que es necesario animar correctamente, es decir, usando propiedades CSS como transform. Sin embargo, si en algunas soluciones dejan activadas sus animaciones, están mal hechas y empeorarán su CLS. Aquí podríamos señalar como mal ejemplo la solución OneTrust (anteriormente Optanon).

INP/TBT: Mide el impacto en el rendimiento del navegador#

La métrica "javascript" Interaction to Next Paint (o Total Blocking Time en mediciones sintéticas) no suele empeorar con las barras de cookies. Pero incluso aquí encontramos excepciones.

En este sentido, tengan cuidado con la solución Didomi, que en un móvil más lento puede bloquear el núcleo principal del navegador hasta cuatro veces el valor de Google Analytics. En sitios web comunes es solo una pequeña molestia, pero, por ejemplo, en sitios donde la carga de renderizado con JS de terceros ya es mayor (sitios de contenido con publicidad), esto puede significar un empeoramiento del INP para los usuarios.

Nota sobre la medición#

A menudo nos encontramos con la opinión de que los componentes de terceros no deberían incluirse en la medición de velocidad, porque los desarrolladores no son responsables de ellos.

Sin embargo, los usuarios no ven la web sin componentes de terceros ni web.dev sobre JS de terceros. No queda más remedio que aceptar la barra de cookies y otros terceros, y simplemente medir el estado real.

Sin embargo, con la barra de cookies se da una situación especial: Algunos usuarios ven la web con ella y otros sin ella. Por eso recomendamos probar ambas variantes.

En la imagen se muestra la configuración de SpeedCurve para Livesport, donde probamos solo la página de inicio con la barra de cookies. Aquí se resuelve técnicamente mediante scripting de WebpageTest. Ustedes pueden hacer una solución similar, por ejemplo, utilizando Lighthouse User Flows.

Recomendaciones para su implementación#

Resumamos:

1. Cargue la barra de cookies lo antes posible.
2. Evite, si es posible, elementos grandes en ella que puedan ser elementos LCP.
3. Tenga cuidado con las animaciones y el deslizamiento de la barra desde arriba.
4. Pruebe el impacto en la velocidad de las soluciones seleccionadas.
5. Mida el impacto en la velocidad con y sin la barra de cookies.

Video final#

Si prefieren la palabra hablada, hay una grabación disponible del webinar de Pavel Ungr sobre barras de cookies.

Con la implementación y optimización, por supuesto, podemos ayudarles en unas horas de consulta, contáctenos en: martin.michalek@pagespeed.cz.

¡Les deseamos webs rápidas! Incluso con la barra de cookies.