Cómo la CMP de PubConsent redujo la INP de sus clientes hasta en un 64% con una estrategia de rendimiento que usa las APIs de Scheduler del navegador para corregir los problemas de capacidad de respuesta identificados con las Herramientas para desarrolladores de Chrome
Las plataformas de administración de consentimiento (CMP) son herramientas que ayudan a los sitios web a cumplir con las reglamentaciones de privacidad mediante la obtención del consentimiento del usuario para el uso de cookies y tecnologías de seguimiento. Además del objetivo principal de garantizar el cumplimiento legal, las CMP, como secuencias de comandos de terceros, también deben garantizar un impacto mínimo en el rendimiento y la experiencia del usuario.
La CMP de PubConsent es el producto más reciente de PubTech. La CMP de PubConsent, diseñada con un enfoque principal en el rendimiento, es liviana, lo que garantiza una experiencia del usuario óptima y un impacto mínimo en el rendimiento general del sitio web.
La introducción de la métrica Interaction to Next Paint (INP) permitió a PubTech descubrir problemas con la capacidad de respuesta de nuestra CMP. En este caso de éxito, PubTech muestra cómo resolvió sus problemas de capacidad de respuesta en su plataforma de CMP de PubConsent y cómo mejoró el INP antes de que se convirtiera en uno de los KPIs de Core Web Vitals en marzo de 2024, lo que demuestra un compromiso inquebrantable con la entrega del mejor rendimiento posible en un producto de CMP.
¿Por qué a PubTech le importa el rendimiento?
La CMP de PubConsent, como la mayoría de las CMP, ofrece su funcionalidad de administración de consentimiento implementada como una secuencia de comandos de terceros en las páginas del sitio. Para garantizar una integración exitosa de la CMP, es fundamental mitigar el impacto en el rendimiento de nuestra oferta de CMP, incluida la capacidad de respuesta.
Si priorizas el rendimiento y mantienes la secuencia de comandos de la CMP de PubConsent liviana, los propietarios de sitios web pueden lograr un equilibrio delicado entre incorporar funciones valiosas de administración de consentimiento y preservar la calidad de la experiencia del usuario.
Dada la importancia de la funcionalidad que proporciona una CMP y el impacto que puede tener en el rendimiento, PubTech estableció los siguientes objetivos:
- Minimiza el impacto del producto de la CMP de PubConsent en la INP.
- Reduce las tareas largas atribuibles al producto de la CMP.
- Reduce el tiempo de bloqueo total (TBT), que puede tener un efecto negativo en el INP de una página.
Cómo se midió la INP
PubTech usó Chrome DevTools para realizar un análisis inicial y diagnosticar manualmente las interacciones lentas. Este flujo de trabajo permitió a PubTech identificar problemas específicos que afectaban la capacidad de respuesta de la página. Por ejemplo, una interacción de clic dentro del producto de la CMP para aceptar todas las cookies y, luego, descartar el diálogo de consentimiento de cookies causó una tarea larga que retrasó una actualización de renderización en la interfaz de usuario. Como puedes ver en la siguiente imagen, la interfaz de usuario no se actualizó para mostrar que se cerró el diálogo hasta después de que se completó la tarea larga.
Al igual que el botón para aceptar todas las cookies, el botón para rechazar todas las cookies o personalizar las preferencias de cookies sigue el mismo flujo de trabajo en la arquitectura de la CMP de PubConsent. Por este motivo, las mejoras detalladas en este caso de éxito afectaron una serie de interacciones de los usuarios en el producto de la CMP.
Este retraso generó la percepción visual de que el panel estaba bloqueado durante la tarea. Debido a que bloqueó la actualización de renderización durante un período perceptiblemente largo, el INP de la página se vio afectado de forma negativa.
Cómo PubTech optimizó la INP para botones y vínculos
Para mejorar la INP, se adoptaron diferentes estrategias de rendimiento en la CMP de PubConsent.
Cómo generar tareas de alta prioridad
El método yieldToMainUiBlocking que se muestra en el siguiente fragmento de código está diseñado para optimizar las tareas de JavaScript de alta prioridad, ya que genera scheduler.yield si está disponible, pero recurre a postTask con prioridad user-blocking (alta) si postTask está disponible y, por último, no recurre a nada.
Se evitó setTimeout aquí porque el método yieldToMainUiBlocking está diseñado para controlar las operaciones de configuración interna de la CMP y el trabajo de alta prioridad que debe retener esa prioridad mientras genera resultados. Esto significa que solo los navegadores que implementan estas APIs de programación, que actualmente solo están disponibles en navegadores basados en Chromium en el momento de escribir este artículo, se benefician de las mejoras detalladas en este caso de éxito. Aun así, este enfoque se consideró una mejora progresiva aceptable para estas tareas de alta prioridad.
function yieldToMainUiBlocking () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
}
}
resolve(false);
});
};
Rendimiento en tareas en segundo plano y de duración media
El método yieldToMainBackground que se muestra en el siguiente fragmento de código se usa para dividir tareas largas que tienen prioridad user-visible (media) o background. La lógica implementa scheduler.yield() si está disponible, pero difiere en el uso de postTask con prioridad media y, por último, recurre a setTimeout en navegadores que no son de Chromium.
function yieldToMainBackground () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
}
}
setTimeout(() => { resolve(true) }, 0);
});
};
yieldToMainBackground permite que el navegador renderice la siguiente pintura (en este caso, cerrar la IU de la CMP) antes.
Cómo PubTech redujo aún más el TBT con la optimización del diseño de renderización
Después de aplicar la estrategia de rendimiento, se descubrió que la INP mejoró significativamente para la CMP. De hecho, después de reducir significativamente la duración de procesamiento del controlador de eventos, se descubrió una oportunidad para realizar más mejoras de renderización para la siguiente pintura de la acción Close UI. Esta acción se diseñó originalmente para quitar elementos del DOM. Esto planteaba desafíos, especialmente en sitios web con una cantidad considerable de nodos DOM, lo que generaba un aumento inesperado en el trabajo de renderización.
Para abordar la mayor cantidad de trabajo de renderización necesario para quitar elementos del DOM, se presentó una solución que el equipo llamó "renderización diferida". En este enfoque, primero se aplica una regla CSS display: none al diálogo de consentimiento de la CMP después de que el usuario da su consentimiento para ocultarlo. Luego, la eliminación de los nodos DOM asociados con el diálogo de la CMP se traslada a un momento posterior, cuando el navegador está inactivo, mediante requestIdleCallback. Este enfoque demostró ser mucho más rápido que quitar los nodos DOM en el momento en que el usuario cerró el diálogo de consentimiento.
Cómo PubTech redujo aún más la INP mejorando la biblioteca del MTC de IAB
Después de resolver correctamente la mayoría de los problemas de capacidad de respuesta de la CMP, se identificaron más oportunidades de mejora en una de sus dependencias principales: la biblioteca del Marco de trabajo de transparencia y consentimiento (TCF) de IAB.
Los componentes más costosos en términos de procesamiento de esta biblioteca fueron "cadenas de compilación" y "envío de consentimiento". Estos componentes son partes integrales de la biblioteca del MTC de IAB. Las siguientes optimizaciones de estos componentes se aplicaron en una bifurcación independiente específicamente para las necesidades de PubTech:
- Reutilizar los resultados calculados para el proceso de decodificación, que se ejecuta para cada devolución de llamada de terceros que necesita leer el consentimiento del usuario
- Se evitaron y redujeron los bucles innecesarios en el proceso de codificación de restricciones del publicador, que se ejecuta cuando el usuario da su consentimiento.
La primera de estas optimizaciones redujo el tiempo que la CMP dedica a cada devolución de llamada de terceros que se conecta a la biblioteca del MTC de IAB. La segunda optimización redujo la duración del procesamiento que genera el componente "cadenas de compilación". De hecho, esta optimización permitió reducir hasta el 60% de los bucles que se ejecutaban cada vez que un usuario expresaba su consentimiento.
Resultados
Con las estrategias de rendimiento anteriores y las nuevas optimizaciones del diseño de renderización implementadas, el INP de la CMP mejoró hasta en un 65%. Como resultado, la capacidad de respuesta de la experiencia del usuario de la CMP de PubConsent mejoró mucho y, en el caso de algunos anuncios, la visibilidad incluso mejoró un 1.5% gracias a la optimización del momento en que se solicitan los anuncios.
Además de estas mejoras, en la biblioteca del MTC de la IAB, se observó que la INP mejoró hasta en un 77% en dispositivos móviles para los clientes afectados como resultado de la reducción de hasta un 85% en las tareas largas que genera el MTC. Esto ayudó a reducir significativamente la sobrecarga de cada devolución de llamada de terceros que se ejecutaba durante todo el ciclo de vida de una página.
La cantidad de orígenes que pasan la INP cuando se usa la CMP de PubConsent mejoró más del 400%, de un 13% a un 55% en dispositivos móviles. En el caso de algunos clientes, la INP de la página se redujo a más de la mitad (de 470 a 230 milisegundos) debido a las optimizaciones realizadas en el SDK de PubTech.
Conclusión
Los clientes de PubTech no tardaron en reconocer los resultados positivos de las métricas comerciales y de rendimiento de la INP que se obtuvieron gracias a nuestros esfuerzos de optimización. Se están considerando más mejoras de rendimiento para la CMP de PubConsent, aprovechando los datos invaluables de la supervisión de usuarios reales (RUM) de sus clientes. Estos datos hacen un seguimiento detallado de las regresiones y los avances, lo que impulsa los esfuerzos de mejora continua de PubTech.
Como tercero, PubTech también se dio cuenta de que tiene la oportunidad de mejorar el rendimiento web a gran escala y proporcionar una mejor capacidad de respuesta, todo ello sin afectar los KPIs de la empresa. Nunca es tarde para comenzar a implementar este tipo de mejoras.
Agradecemos especialmente a Luca Coppola, CTO de PubTech, por apoyar este trabajo de innovación, y a Jeremy Wagner, Michal Mocny y Rick Viscomi de Google.