PubTech konnte mit seiner Plattform zur Einwilligungsverwaltung den INP auf den Websites seiner Kunden um bis zu 64 % senken und gleichzeitig die Anzeigensichtbarkeit um bis zu 1,5 % verbessern

So konnte die CMP von PubConsent die INP für ihre Kunden um bis zu 64% senken, indem sie eine Yielding-Strategie mit den Scheduler APIs des Browsers verwendete, um Probleme mit der Reaktionsfähigkeit zu beheben, die mit Chrome DevTools identifiziert wurden.

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

Plattformen zur Einwilligungsverwaltung (Consent Management Platforms, CMPs) sind Tools, mit denen Websites die Datenschutzbestimmungen einhalten können, indem die Nutzereinwilligung für die Verwendung von Cookies und Tracking-Technologien eingeholt wird. Neben dem primären Ziel der rechtlichen Compliance müssen CMPs als Drittanbieter-Scripts auch für minimale Auswirkungen auf Leistung und Nutzerfreundlichkeit sorgen.

PubConsent CMP ist das neueste Produkt von PubTech. Die PubConsent-CMP wurde vor allem im Hinblick auf die Leistung entwickelt. Sie ist leistungsstark, sorgt für eine optimale Nutzererfahrung und hat nur minimale Auswirkungen auf die Gesamtleistung der Website.

Durch die Einführung des Messwerts Interaction to Next Paint (INP) konnte PubTech Probleme mit der Reaktionsfähigkeit unserer CMP erkennen. In dieser Fallstudie zeigt PubTech, wie es seine Probleme mit der Responsivität in seiner CMP-Plattform PubConsent gelöst und den INP-Wert verbessert hat, bevor er im März 2024 zu einem der Core Web Vitals wurde. So demonstriert das Unternehmen sein unerschütterliches Engagement für die bestmögliche Leistung eines CMP-Produkts.

Warum ist PubTech an der Leistung interessiert?

Die CMP von PubConsent bietet wie die meisten CMPs Funktionen zur Einwilligungsverwaltung, die als Drittanbieter-Script auf Websiteseiten implementiert sind. Die Leistungsauswirkungen unseres CMP-Angebots – auch auf die Reaktionsfähigkeit – zu minimieren, ist entscheidend für eine erfolgreiche CMP-Integration.

Wenn Websiteinhaber die Leistung priorisieren und das PubConsent-CMP-Script möglichst schlank halten, können sie ein heikles Gleichgewicht zwischen der Einbindung wertvoller Funktionen zur Einwilligungsverwaltung und der Wahrung der Qualität der Nutzererfahrung finden.

Angesichts der Bedeutung der Funktionen einer CMP und der Auswirkungen, die sie auf die Leistung haben kann, hat sich PubTech folgende Ziele gesetzt:

  1. Minimieren Sie die Auswirkungen des PubConsent-CMP-Produkts auf die INP.
  2. Langwierige Aufgaben, die dem CMP-Produkt zugeordnet werden können, reduzieren.
  3. Verringern Sie die Gesamte Blockierzeit (Total Blocking Time, TBT), die sich negativ auf die INP einer Seite auswirken kann.

So wurde die Impressionsnachfrage gemessen

PubTech führte mit den Chrome DevTools eine erste Analyse durch und diagnostizierte manuell langsame Interaktionen. Mit diesem Workflow konnte PubTech bestimmte Probleme identifizieren, die sich auf die Seitenreaktionsfähigkeit auswirkten. Wenn ein Nutzer beispielsweise im CMP-Produkt auf „Alle Cookies akzeptieren“ klickt und dann das Dialogfeld zur Einwilligung in Cookies schließt, dauert es sehr lange, bis die Benutzeroberfläche aktualisiert wird. Wie Sie auf dem folgenden Bild sehen, wurde die Benutzeroberfläche erst nach Abschluss der langen Aufgabe aktualisiert, um anzuzeigen, dass das Dialogfeld geschlossen wurde.

Sowohl die Schaltfläche zum Akzeptieren aller Cookies als auch die Schaltfläche zum Ablehnen aller Cookies oder zum Anpassen der Cookie-Einstellungen folgen in der PubConsent-CMP-Architektur demselben Workflow. Daher wirkten sich die in dieser Fallstudie beschriebenen Verbesserungen auf eine Reihe von Nutzerinteraktionen in der CMP aus.

Ein Ablauf, der zeigt, wie eine lange Aufgabe die Aktualisierung der Benutzeroberfläche verhindert, nachdem der Nutzer in der PubConsent-CMP auf die Schaltfläche „Alle akzeptieren“ geklickt hat. Es gibt fünf Schritte, die eine einzige lange Aufgabe ausmachen, was die Benutzeroberfläche träge macht.
Visuelle Darstellung dessen, was passiert, wenn Nutzer auf die Schaltfläche „Alle akzeptieren“ klicken.

Diese Verzögerung führte dazu, dass der Bereich während der Aufgabe optisch als gesperrt wahrgenommen wurde. Da das Rendering-Update für einen spürbar langen Zeitraum blockiert wurde, wurde die INP der Seite negativ beeinflusst.

Um die INP zu verbessern, wurden in der PubConsent-CMP verschiedene Ertragsstrategien eingeführt.

Aufgaben mit hoher Priorität ausführen

Die im folgenden Code-Snippet gezeigte Methode yieldToMainUiBlocking ist für die Optimierung von JavaScript-Aufgaben mit hoher Priorität konzipiert. Sie gibt scheduler.yield zurück, falls verfügbar, wechselt aber zu postTask mit user-blocking (hohe Priorität), falls postTask verfügbar ist, und schließlich zu nichts.

setTimeout wurde hier vermieden, da die yieldToMainUiBlocking-Methode für interne CMP-Einstellungen und Aufgaben mit hoher Priorität entwickelt wurde, die diese Priorität beibehalten sollten, während sie ausgeführt werden. Das bedeutet, dass nur Browser, die diese Planungs-APIs implementieren – die derzeit nur in Chromium-basierten Browsern verfügbar sind –, von den in dieser Fallstudie beschriebenen Verbesserungen profitieren. Trotzdem wurde dieser Ansatz als akzeptable progressive Verbesserung für diese Aufgaben mit hoher Priorität eingestuft.

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);
 
});
};

Leistung bei mittleren und Hintergrundaufgaben

Mit der im folgenden Code-Snippet gezeigten Methode yieldToMainBackground können lange Aufgaben mit der Priorität user-visible (mittel) oder background in mehrere Teile unterteilt werden. Die Logik implementiert scheduler.yield(), wenn sie verfügbar ist. Sie unterscheidet sich jedoch dadurch, dass postTask mit mittlerer Priorität verwendet wird und schließlich in Nicht-Chromium-Browsern auf setTimeout zurückgegriffen wird.

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);
 
});
};
Ein Ablauf, der zeigt, wie die lange Aufgabe optimiert wurde, die die Aktualisierung der Benutzeroberfläche blockierte, nachdem der Nutzer in der PubConsent-CMP auf die Schaltfläche „Alle akzeptieren“ geklickt hatte. Die fünf Schritte werden jetzt nach Möglichkeit ausgeführt, sodass das Rendering der Benutzeroberfläche früher aktualisiert werden kann.
Visuelle Darstellung, wie durch das Ausgeben mit yieldToMainBackground der Browser die nächste Paint-Phase (in diesem Fall das Schließen der CMP-Benutzeroberfläche) früher rendern kann.

So konnte PubTech die TBT durch die Optimierung des Rendering-Layouts weiter reduzieren

Nach der Anwendung der Ertragsstrategie wurde festgestellt, dass sich der INP für die CMP deutlich verbessert hatte. Nachdem die Verarbeitungsdauer des Ereignis-Handlers deutlich reduziert wurde, wurde eine Möglichkeit gefunden, weitere Verbesserungen beim Rendern für die nächste Paint-Aktion für die Aktion UI schließen vorzunehmen. Diese Aktion wurde ursprünglich entwickelt, um Elemente aus dem DOM zu entfernen. Dies stellte vor allem auf Websites mit einer großen Anzahl von DOM-Knoten eine Herausforderung dar, was zu einer unerwarteten Erhöhung der Rendering-Arbeit führte.

Screenshot des Bereichs „Leistung“ in den Chrome DevTools mit einem Abschnitt eines Tracings mit einem Aufrufstapel von Aktivitäten zum Schließen eines UI-Dialogfelds in der PubConsent-CMP. Die Aufgabe zum Schließen des UI-Dialogfelds selbst löst das Entfernen von DOM-Knoten aus, die die Präsentationsverzögerung der Interaktion erhöhen.

Um die erhöhte Menge an Rendering-Arbeit zu bewältigen, die zum Entfernen von Elementen aus dem DOM erforderlich war, wurde eine Lösung eingeführt, die das Team als „Lazy De-Rendering“ bezeichnete. Bei diesem Ansatz wird zuerst eine display: none-CSS-Regel auf das Einwilligungsdialogfeld der CMP angewendet, nachdem der Nutzer seine Einwilligung zum Ausblenden gegeben hat. Anschließend wird das Entfernen der mit dem CMP-Dialogfeld verknüpften DOM-Knoten mithilfe von requestIdleCallback auf einen späteren Zeitpunkt verschoben, wenn der Browser inaktiv ist. Dieser Ansatz erwies sich als viel schneller als das Entfernen von DOM-Knoten im Moment, in dem der Nutzer das Einwilligungsdialogfeld geschlossen hat.

Screenshot des Bereichs „Leistung“ in den Chrome-Entwicklertools mit demselben Ablauf wie zuvor, aber optimiert Wenn das Dialogfeld der PubConsent-CMP geschlossen ist, wird es zuerst mit der CSS-Regel „display: none“ ausgeblendet. Wenn der Browser später inaktiv ist, wird der DOM-Knoten entfernt.
DevTools-Screenshot, der die Verbesserung der INP durch Verlagerung der DOM-Entfernungsaufgabe veranschaulicht.

So hat PubTech die INP durch Verbesserung der IAB TCF-Bibliothek weiter reduziert

Nachdem die meisten Probleme mit der Reaktionsfähigkeit der CMP behoben wurden, wurden weitere Verbesserungsmöglichkeiten bei einer ihrer Hauptabhängigkeiten erkannt: der TCF (Transparency and Consent Framework) des IAB (Interactive Advertising Bureau).

Die rechenintensivsten Komponenten dieser Bibliothek waren „build strings“ und „dispatch consent“. Diese Komponenten sind integrale Bestandteile der IAB TCF-Bibliothek. Die folgenden Optimierungen dieser Komponenten wurden in einer separaten Fork speziell für die Anforderungen von PubTech angewendet:

  1. Wiederverwendung berechneter Ergebnisse für den Dekodierungsprozess, der für jeden Drittanbieter-Callback ausgeführt wird, bei dem die Einwilligung des Nutzers gelesen werden muss.
  2. Unnötige Schleifen beim Codieren von Publisher-Einschränkungen wurden vermieden und reduziert. Dieser Vorgang wird ausgeführt, wenn der Nutzer seine Einwilligung erteilt.

Durch die erste dieser Optimierungen wurde die Zeit reduziert, die die CMP für jeden Drittanbieter-Callback benötigt, der an die IAB TCF-Bibliothek angehängt ist. Durch die zweite Optimierung wurde die Verarbeitungsdauer der Komponente „build strings“ reduziert. Durch diese Optimierung konnten bis zu 60% der Schleifen reduziert werden, die jedes Mal ausgeführt wurden, wenn ein Nutzer seine Einwilligung erteilte.

Ergebnisse

Durch die zuvor erfolgreichen Strategien und die neuen Optimierungen des Rendering-Layouts stieg der INP der CMP um bis zu 65%. Dadurch wurde die Reaktionsfähigkeit der PubConsent-CMP für Nutzer erheblich verbessert.Durch die Optimierung der Zeit, zu der Anzeigen angefordert werden, konnte die Sichtbarkeit bei einigen Anzeigen sogar um 1, 5% gesteigert werden.

Zusätzlich zu diesen Verbesserungen wurde in der TCF-Bibliothek des IAB festgestellt, dass sich die INP für betroffene Kunden auf Mobilgeräten um bis zu 77% verbessert hat, da TCF-bedingte lange Aufgaben um bis zu 85 % reduziert wurden. Dadurch konnte der Overhead jedes Drittanbieter-Callbacks, der während des gesamten Lebenszyklus einer Seite ausgeführt wird, erheblich reduziert werden.

Die Anzahl der Ursprünge, die bei Verwendung der PubConsent-CMP die INP passieren, hat sich um mehr als 400 % verbessert, von 13% auf 55% auf Mobilgeräten. Bei einigen Kunden konnte die Seiten-INP durch die Optimierungen des PubTech SDK um mehr als die Hälfte reduziert werden – von 470 Millisekunden auf 230 Millisekunden.

Ein Screenshot der INP-Übereinstimmungsraten für Websites, die die PubTech-CMP verwenden. Auf dem Computer steigt die Bestehensquote von etwa 84% auf 99, 12%. Auf Mobilgeräten steigen die Abgaberaten von etwa 22% auf 55, 46%.
Herkunfts-INP-Übergang für Websites mit PubTech-CMP, wie vom HTTP Archive und Chrome User Experience Report (CrUX) erfasst.
Screenshot eines Dashboards mit INP aus RUM-Daten im 75. Perzentil Ab Juli/August 2023 liegt der INP knapp unter 500 Millisekunden. Mitte Februar 2024 liegt er jedoch knapp unter 200 Millisekunden, was dem Grenzwert „Gut“ entspricht.
Verbesserungstrend bei den mobilen INP-Daten eines PubConsent-Kunden, der mit den in dieser Fallstudie beschriebenen SDK-Änderungen zusammenhängt.

Fazit

Die Kunden von PubTech haben schnell die positiven Ergebnisse der INP-Leistung und der Geschäftsmesswerte erkannt, die sich aus unseren Optimierungsbemühungen ergeben haben. Es werden weitere Leistungsverbesserungen für die PubConsent-CMP in Betracht gezogen, wobei wertvolle RUM-Daten (Real User Monitoring) von ihren Kunden genutzt werden. Anhand dieser Daten werden sowohl Rückschritte als auch Fortschritte genau beobachtet, um die kontinuierlichen Verbesserungsbemühungen von PubTech voranzutreiben.

Als Drittanbieter erkannte PubTech auch, dass es die Möglichkeit hat, die Webleistung im großen Maßstab zu verbessern und die Reaktionsfähigkeit zu erhöhen, ohne negative Auswirkungen auf die Geschäfts-KPIs zu haben. Es ist nie zu spät, diese Art von Verbesserungen umzusetzen.

Ein besonderer Dank geht an Luca Coppola, den CTO von PubTech, für die Unterstützung bei dieser innovativen Arbeit sowie an Jeremy Wagner, Michal Mocny und Rick Viscomi von Google.