Comment la PGC PubConsent a réduit l'INP de ses clients jusqu'à 64% en utilisant une stratégie de rendement qui utilise les API de planification du navigateur pour résoudre les problèmes de réactivité identifiés à l'aide des outils pour les développeurs Chrome.
Les plates-formes de gestion du consentement (CMP) sont des outils qui aident les sites Web à respecter les réglementations sur la confidentialité en obtenant le consentement des utilisateurs pour l'utilisation de cookies et de technologies de suivi. En plus de leur objectif principal, qui est de garantir la conformité aux lois, les PGC, en tant que scripts tiers, doivent également avoir un impact minimal sur les performances et l'expérience utilisateur.
La CMP PubConsent est le dernier produit de PubTech. Conçue pour privilégier les performances, la CMP PubConsent est légère, ce qui garantit une expérience utilisateur optimale et un impact minimal sur les performances globales du site Web.
L'introduction de la métrique Interaction to Next Paint (INP) a permis à PubTech de découvrir des problèmes de réactivité de notre CMP. Dans cette étude de cas, PubTech explique comment il a résolu ses problèmes de réactivité dans sa plate-forme CMP PubConsent et comment il a amélioré l'INP avant qu'il ne devienne l'un des Core Web Vitals en mars 2024. Il démontre ainsi son engagement indéfectible à fournir les meilleures performances possibles dans un produit CMP.
Pourquoi la technologie publicitaire est-elle axée sur les performances ?
Comme la plupart des PGC, la PGC PubConsent propose sa fonctionnalité de gestion du consentement implémentée en tant que script tiers sur les pages du site. Il est essentiel d'atténuer l'impact de notre offre de CMP sur les performances, y compris sur la réactivité, pour garantir une intégration réussie.
En privilégiant les performances et en gardant le script de la CMP PubConsent léger, les propriétaires de sites Web peuvent trouver un équilibre délicat entre l'intégration de fonctionnalités de gestion du consentement utiles et le maintien de la qualité de l'expérience utilisateur.
Compte tenu de l'importance des fonctionnalités d'une CMP et de l'impact qu'elles peuvent avoir sur les performances, PubTech s'est fixé les objectifs suivants:
- Réduire l'impact du produit CMP PubConsent sur l'INP
- Réduire les tâches longues attribuables au produit CMP
- Réduisez le temps de blocage total (TBT), qui peut avoir un impact négatif sur l'INP d'une page.
Comment l'INP a été mesuré
PubTech a utilisé les outils pour les développeurs Chrome pour effectuer une analyse initiale et diagnostiquer manuellement les interactions lentes. Ce workflow a permis à PubTech d'identifier des problèmes spécifiques affectant la réactivité des pages. Par exemple, une interaction de clic dans le produit CMP pour accepter tous les cookies et fermer ensuite la boîte de dialogue de consentement aux cookies a entraîné une tâche longue qui a retardé la mise à jour du rendu de l'interface utilisateur. Comme vous pouvez le voir sur l'image suivante, l'interface utilisateur n'a pas été mise à jour pour indiquer que la boîte de dialogue avait été fermée tant que la tâche longue n'était pas terminée.
Comme le bouton permettant d'accepter tous les cookies, le bouton permettant de refuser tous les cookies ou de personnaliser les préférences en matière de cookies suivent tous le même workflow dans l'architecture de la CMP PubConsent. Par conséquent, les améliorations détaillées dans cette étude de cas ont affecté une série d'interactions utilisateur dans le produit CMP.
Ce délai a donné l'impression visuelle que le panneau était verrouillé pendant la tâche. Comme il a bloqué la mise à jour du rendu pendant une période perceptiblement longue, l'INP de la page a été affecté négativement.
Comment PubTech a optimisé l'INP pour les boutons et les liens
Pour améliorer l'INP, différentes stratégies de rendement ont été adoptées dans la CMP PubConsent.
Cédant la priorité aux tâches à priorité élevée
La méthode yieldToMainUiBlocking illustrée dans l'extrait de code suivant est conçue pour optimiser les tâches JavaScript de haute priorité en renvoyant scheduler.yield si elle est disponible, mais en revenant à postTask avec une priorité user-blocking (élevée) si postTask est disponible, et enfin en renvoyant rien.
setTimeout a été évité ici, car la méthode yieldToMainUiBlocking est conçue pour gérer les opérations de paramètres CMP internes et les tâches de priorité élevée qui doivent conserver cette priorité tout en donnant un résultat. Cela signifie que seuls les navigateurs implémentant ces API de planification (qui ne sont actuellement disponibles que dans les navigateurs Chromium au moment de la rédaction de cet article) bénéficient des améliorations détaillées dans cette étude de cas. Malgré tout, cette approche a été jugée acceptable pour ces tâches à priorité élevée.
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);
});
};
Rendement des tâches moyennes et en arrière-plan
La méthode yieldToMainBackground présentée dans l'extrait de code suivant permet de diviser les tâches longues ayant une priorité user-visible (moyenne) ou background. La logique implémente scheduler.yield() s'il est disponible, mais elle diffère en utilisant postTask avec une priorité moyenne, et en revenant finalement à setTimeout sur les navigateurs autres que 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 permet au navigateur d'afficher le prochain rendu (fermeture de l'UI de la CMP dans ce cas) plus rapidement.
Comment PubTech a encore réduit le délai avant diffusion grâce à l'optimisation de la mise en page de rendu
Après avoir appliqué la stratégie de rendement, il a été constaté que l'INP avait considérablement augmenté pour la PGC. En fait, après avoir considérablement réduit la durée de traitement du gestionnaire d'événements, nous avons découvert une opportunité d'améliorer davantage le rendu pour la prochaine peinture de l'action Close UI (Fermer l'UI). Cette action était initialement conçue pour supprimer des éléments du DOM. Cela posait des problèmes, en particulier sur les sites Web comportant un nombre important de nœuds DOM, ce qui entraînait une augmentation inattendue du travail de rendu.
Pour faire face à l'augmentation du travail de rendu nécessaire pour supprimer des éléments du DOM, l'équipe a mis en place une solution qu'elle a appelée "dé-rendu paresseux". Cette approche applique d'abord une règle CSS display: none à la boîte de dialogue de consentement de la PGC une fois que l'utilisateur a accepté de la masquer. Ensuite, la suppression des nœuds DOM associés à la boîte de dialogue de la CMP est reportée à un moment ultérieur, lorsque le navigateur est inactif, à l'aide de requestIdleCallback. Cette approche s'est avérée beaucoup plus rapide que la suppression des nœuds DOM au moment où l'utilisateur a fermé la boîte de dialogue de consentement.
Comment PubTech a encore réduit l'INP en améliorant la bibliothèque du TCF de l'IAB
Après avoir résolu la plupart des problèmes de réactivité de la CMP, d'autres possibilités d'amélioration ont été identifiées dans l'une de ses principales dépendances: la bibliothèque du Transparency and Consent Framework (TCF) de l'IAB.
Les composants les plus coûteux en termes de calcul de cette bibliothèque étaient "build strings" (chaînes de compilation) et "dispatch consent" (autorisation de distribution). Ces composants font partie intégrante de la bibliothèque TCF de l'IAB. Les optimisations suivantes ont été appliquées à ces composants dans un fork distinct, spécifiquement pour les besoins de PubTech:
- Réutilisation des résultats calculés pour le processus de décodage, qui est exécuté pour chaque rappel tiers devant lire le consentement de l'utilisateur.
- Évité et réduit les boucles inutiles dans le processus d'encodage des restrictions de l'éditeur, qui est exécuté lorsque l'utilisateur donne son consentement.
La première de ces optimisations a réduit le temps passé par la CMP sur chaque rappel tiers qui s'associe à la bibliothèque TCF de l'IAB. La deuxième optimisation a réduit la durée de traitement du composant "build strings". En effet, cette optimisation a permis de réduire jusqu'à 60% des boucles exécutées chaque fois qu'un utilisateur exprimait son consentement.
Résultats
Avec les stratégies précédemment rentables et les nouvelles optimisations de mise en page de rendu en place, l'INP de la CMP a augmenté de 65%. Par conséquent, la réactivité de l'expérience utilisateur de la PGC PubConsent a été considérablement améliorée.Pour certaines annonces, la visibilité a même augmenté de 1, 5% en optimisant le moment où les annonces sont demandées.
En plus de ces améliorations, dans la bibliothèque du TCF de l'IAB, nous avons constaté que l'INP avait augmenté de 77% sur mobile pour les clients concernés, car les tâches longues induites par le TCF ont été réduites de 85%. Cela a permis de réduire considérablement les coûts indirects de chaque rappel tiers exécuté pendant tout le cycle de vie d'une page.
Le nombre d'origines transmettant l'INP lorsque la CMP PubConsent est utilisée a augmenté de plus de 400%, passant de 13% à 55% sur mobile. Pour certains clients, l'INP de la page a été réduite de plus de la moitié, passant de 470 millisecondes à 230 millisecondes, grâce aux optimisations apportées au SDK PubTech.
Conclusion
Les clients de PubTech ont rapidement reconnu les performances positives de l'INP et les résultats positifs des métriques commerciales obtenus grâce à nos efforts d'optimisation. D'autres améliorations des performances de la CMP PubConsent sont envisagées, en exploitant les données de surveillance des utilisateurs réels (RUM) inestimables de leurs clients. Ces données suivent de près les régressions et les progrès, ce qui permet à PubTech d'améliorer continuellement ses performances.
En tant que tiers, PubTech a également réalisé qu'il pouvait améliorer les performances Web à grande échelle et améliorer la réactivité, tout en évitant les impacts négatifs sur les KPI commerciaux. Il n'est jamais trop tard pour commencer à mettre en œuvre ce type d'améliorations.
Un merci tout particulier à Luca Coppola, directeur technique de PubTech, pour son soutien dans ce travail d'innovation, ainsi qu'à Jeremy Wagner, Michal Mocny et Rick Viscomi de Google.