Découvrez comment la CMP de PubConsent a réduit l'INP pour ses clients jusqu'à 64% en utilisant une stratégie de rendement qui utilise les API Scheduler 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 garantir la conformité juridique, les CMP doivent garantir un impact minimal sur les performances et l'expérience utilisateur, en tant que scripts tiers.
La CMP PubConsent est le dernier produit de PubTech. Conçue avant tout sur les performances, la CMP PubConsent est légère. Elle 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 d'identifier les problèmes de réactivité de notre CMP. Dans cette étude de cas, PubTech montre comment elle a résolu les problèmes de réactivité de sa plate-forme de PGC PubConsent et comment elle a amélioré INP avant qu'elle ne devienne l'un des Core Web Vitals en mars 2024, démontrant ainsi son engagement indéfectible à fournir les meilleures performances possible pour un produit de PGC.
Pourquoi PubTech s'intéresse-t-il aux performances ?
Comme la plupart d'entre elles, la CMP PubConsent propose sa fonctionnalité de gestion du consentement implémentée sous la forme d'un script tiers sur les pages de votre site. Il est essentiel d'atténuer l'impact de notre offre de PGC sur les performances, y compris en termes de réactivité, pour garantir une intégration réussie de la PGC.
En priorisant les performances et en allégeant le script de la CMP PubConsent, les propriétaires de sites Web peuvent trouver le bon équilibre entre l'intégration de fonctionnalités utiles de gestion du consentement tout en préservant la qualité de l'expérience utilisateur.
Compte tenu de l'importance des fonctionnalités fournies par une CMP et de leur impact sur les performances, PubTech a défini les objectifs suivants:
- Réduisez l'impact du produit CMP PubConsent sur INP.
- Réduisez les longues tâches attribuables au produit de PGC.
- Réduisez le temps de blocage total (TBT), qui peut avoir un effet 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 les 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, puis fermer la boîte de dialogue de collecte du consentement pour les cookies entraînait une longue tâche qui retardait la mise à jour de l'affichage dans l'interface utilisateur. Comme vous pouvez le voir sur l'image ci-dessous, l'interface utilisateur n'a pas été mise à jour pour indiquer que la boîte de dialogue avait été fermée avant la fin de la tâche.
Tout comme le bouton permettant d'accepter tous les cookies et le bouton permettant de refuser tous les cookies ou de personnaliser les préférences de cookies, le workflow est le même dans l'architecture de la CMP PubConsent. Pour cette raison, les améliorations détaillées dans cette étude de cas ont eu une incidence sur une série d'interactions utilisateur dans le produit de PGC.
Ce délai a donné l'impression visuelle que le panneau était verrouillé pendant la tâche. Étant donné qu'il bloquait la mise à jour du rendu pendant une période perceptivement longue, l'INP de la page a été affecté négativement.
Comment PubTech a optimisé 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.
Rendre les tâches à priorité élevée
La méthode yieldToMainUiBlocking
présentée dans l'extrait de code suivant est conçue pour optimiser les tâches JavaScript à priorité élevée en générant avec scheduler.yield
si disponible, mais en revenant à postTask
avec une priorité user-blocking
(élevée) si postTask
est disponible, et enfin à zéro.
setTimeout
a été évité ici, car la méthode yieldToMainUiBlocking
est conçue pour gérer les opérations internes de paramétrage de la CMP et les tâches à priorité élevée qui doivent conserver cette priorité lors du rendement. Cela signifie que seuls les navigateurs qui implémentent ces API de planification, qui ne sont actuellement disponibles que dans les navigateurs basés sur Chromium au moment de la rédaction de ce document, bénéficient des améliorations décrites dans cette étude de cas. Malgré cela, cette approche a été jugée une amélioration progressive 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);
});
};
Achètent sur les tâches moyennes et en arrière-plan
La méthode yieldToMainBackground
présentée dans l'extrait de code suivant permet de décomposer les tâches longues avec 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, puis en revenant à setTimeout
sur les navigateurs non 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);
});
};
Comment PubTech a encore réduit la valeur de conversion temporaire grâce à l'optimisation de la mise en page du rendu
Après avoir appliqué la stratégie de rendement, nous avons constaté que l'INP s'était considérablement améliorée pour la CMP. En effet, après avoir considérablement réduit la durée de traitement du gestionnaire d'événements, l'équipe a découvert l'opportunité d'améliorer l'affichage du prochain rendu pour l'action Fermer l'interface utilisateur. À l'origine, cette action a été 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 des tâches de rendu nécessaires pour supprimer des éléments du DOM, une solution a été introduite. L'équipe a appelé le "déaffichage différé". Cette approche applique d'abord une règle CSS display: none
à la boîte de dialogue de consentement de la CMP une fois que l'utilisateur a autorisé son masquage. 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 ferme la boîte de dialogue de collecte du consentement.
Comment PubTech a encore réduit l'INP en améliorant la bibliothèque 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 de cette bibliothèque les plus coûteux en ressources de calcul étaient les "chaînes de compilation" et le "consentement de distribution". Ces composants font partie intégrante de la bibliothèque du TCF de l'IAB. Les optimisations suivantes apportées à ces composants ont été appliquées dans une section distincte 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.
- Les boucles inutiles ont été évitées et réduites dans le processus d'encodage des restrictions applicables aux éditeurs, qui est exécuté lorsque l'utilisateur donne son consentement.
La première de ces optimisations a permis de réduire le temps passé par la CMP sur chaque rappel tiers associé à la bibliothèque TCF de l'IAB. La seconde optimisation a permis de réduire la durée de traitement engendrée par le composant "build string". Cette optimisation a même permis de réduire jusqu'à 60% des boucles exécutées chaque fois qu'un utilisateur a donné son consentement.
Résultats
Grâce aux stratégies qui génèrent le plus de rendements et aux nouvelles optimisations de mise en page liées au rendu, l'INP de la CMP a augmenté de 65%. Cela a permis d'améliorer considérablement la réactivité de l'expérience utilisateur de la CMP PubConsent, et pour certaines annonces, la visibilité a même augmenté de 1, 5% en optimisant les demandes d'annonces.
En plus de ces améliorations, dans la bibliothèque du TCF de l'IAB, il a été observé que INP s'est amélioré de 77% sur mobile pour les clients concernés. Cela a permis de réduire de 85 % les tâches longues induites par le TCF. Cela a permis de réduire considérablement les frais généraux liés à chaque rappel tiers exécuté pendant l'ensemble du cycle de vie d'une page.
Le nombre d'origines ayant transmis l'INP avec la CMP PubConsent est passé de 13 % à 55 % sur mobile. Pour certains clients, l'INP de la page a été réduit de plus de moitié (de 470 à 230 millisecondes) grâce aux optimisations apportées au SDK PubTech.
Conclusion
Les clients de PubTech ont vite compris les performances positives de l'INP et les résultats des métriques commerciales résultant de nos efforts d'optimisation. Nous envisageons d'améliorer les performances de la CMP PubConsent, en exploitant les données RUM (Real User Monitoring) précieuses fournies par leurs clients. Ces données suivent de près les régressions et les progrès, ce qui favorise les efforts continus de PubTech.
En tant que société tierce, PubTech s'est également rendu compte qu'elle pouvait améliorer les performances Web à grande échelle et offrir une meilleure réactivité, tout en évitant les impacts négatifs sur les KPI de l'entreprise. Il n'est jamais trop tard pour commencer à mettre en œuvre ce type d'amélioration !
Un grand merci à Luca Coppola, directeur de la technologie de PubTech pour soutenir ce travail d'innovation, ainsi qu'à Jeremy Wagner, Michal Mocny et Rick Viscomi de Google.