Fast jede Website in Europa begrüßt ihre Besucher mit einem Consent-Dialog. Technisch ist dieser Dialog kein Beiwerk: Er liegt über dem sichtbaren Bereich, er wird sehr früh geladen, und auf Mobilgeräten enthält er regelmäßig das größte gezeichnete Textelement der Seite. Damit entscheidet er über den Largest Contentful Paint mit, über die Reaktionszeit des allerersten Klicks und über die Layoutstabilität beim Ein- und Ausblenden. Dieser Beitrag zeigt, wie sich der Einfluss des Consent-Layers im Feld sauber messen lässt, mit welchen Umbauten er den kritischen Pfad verlässt und wo der rechtliche Rahmen die Gestaltungsfreiheit begrenzt.
Das Wichtigste in Kürze
- Ein bildschirmfüllender Consent-Layer wird selbst zum LCP-Element, weil er Überschrift, Text und Schaltflächen mitbringt und später erscheint als das Hero-Bild; mobil stellt bei 23,7 Prozent (HTTP Archive Web Almanac 2025) der Seiten ein Textblock den LCP.
- Die erste Dialogebene gehört als Markup in das ausgelieferte HTML und ihr CSS inline in das Dokument. Rechtlich trägt das, weil nur das Speichern und Auslesen auf dem Endgerät einwilligungsbedürftig ist, nicht die Anzeige eines Hinweises.
- Ein fixiert positioniertes Overlay verschiebt beim Ein- und Ausblenden nichts, während ein Blockelement am Dokumentanfang den gesamten Inhalt nach unten drückt; Übergänge laufen über transform und opacity statt über Höhen.
- Der Klick auf Zustimmen ist häufig die erste gemessene Interaktion. Werden dort alle Tags gleichzeitig gestartet, wächst die Verarbeitungsdauer; gestaffeltes Nachladen in Leerlaufphasen hält den INP unter 200 Millisekunden (Google web.dev).
- § 25 TDDDG und die DSK-Orientierungshilfe verlangen, dass einwilligungsbedürftige Skripte erst nach der Entscheidung starten; verdeckt das Banner Inhalte, braucht die erste Ebene eine gleichwertige Ablehnoption (DSK).
- Zweck- und Anbieterlisten gehören auf die zweite Ebene, damit die erste mit wenigen DOM-Knoten auskommt; welches Element den LCP stellt, klärt eine Feldmessung mit protokolliertem LCP-Element statt ein Laborlauf mit leerem Profil.
Warum der Consent-Layer im kritischen Pfad landet
Der kritische Pfad umfasst alles, was der Browser laden, parsen und ausführen muss, bevor er den sichtbaren Bereich zeichnen kann. Ein Consent-Dialog gehört dort per Konstruktion hinein: Er soll erscheinen, bevor irgendein einwilligungsbedürftiges Skript startet, und er soll dabei nicht flackern. Viele Implementierungen lösen beides, indem sie ein externes Skript möglichst weit oben im Dokument einbinden, häufig ohne defer und oft mit einem zusätzlichen Stylesheet. Vor dem ersten Bildpunkt steht damit eine vollständige Kette: DNS-Auflösung, TLS-Handshake, Download, Parsen, Ausführen, DOM-Aufbau, Stilberechnung. Jeder dieser Schritte kostet auf einer Mobilverbindung deutlich mehr Zeit als im Büro-WLAN, unter dem der Dialog meist entwickelt wurde.
Wie groß dieser Block ausfällt, hängt an der Verbreitung von Drittanbietern. Der HTTP Archive Web Almanac 2025 stellt fest, dass mindestens 90 Prozent (HTTP Archive Web Almanac 2025) aller Seiten einen oder mehrere Drittanbieter einbinden; über den gesamten Datensatz zählt die Auswertung rund 79 Drittanbieter-Anfragen (HTTP Archive Web Almanac 2025) pro Seite auf Mobilgeräten. Das Kapitel Privacy ergänzt: 74 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten laden mindestens einen Drittanbieter-Tracker. Nahezu jede dieser Ressourcen ist einwilligungsbedürftig, und damit hängt sie am Consent-Layer: Er wird zur Schleuse, durch die der gesamte Rest der Seite muss.
Die Felddaten zeigen, wo das mündet. Nach den Messwerten des Chrome UX Report erreichen 62 Prozent (HTTP Archive Web Almanac 2025) der Seiten auf Mobilgeräten einen guten LCP-Wert, während 13 Prozent (HTTP Archive Web Almanac 2025) im schlechten Bereich liegen; auf dem Desktop sind es 74 Prozent (HTTP Archive Web Almanac 2025) gute Werte. Die Lücke zwischen beiden Gerätetypen ist genau dort am größten, wo ein Overlay den kleinen Viewport dominiert. Wer seine eigenen Werte einordnen möchte, findet die Grundlagen der drei Metriken auf unserer Seite zur Optimierung der Core Web Vitals.
Der Dialog ist Pflichtprogramm, keine Zutat
Wann das Banner selbst zum LCP-Element wird
Largest Contentful Paint misst den Zeitpunkt, zu dem das größte Bild- oder Textelement im sichtbaren Bereich gezeichnet wurde. Als Kandidaten gelten unter anderem Bilder, Videoposter, Elemente mit CSS-Hintergrundbild und Blockelemente, die Text enthalten. Der Wert wird laufend fortgeschrieben: Zeichnet der Browser später ein größeres Element, ersetzt dieses den bisherigen Kandidaten. Genau das geschieht, wenn ein bildschirmfüllender Consent-Layer nach dem Hero-Bereich erscheint und ihn überdeckt. Der Messwert bezieht sich dann nicht mehr auf das Hero-Bild, sondern auf einen Dialog, der erst nach dem Fremdskript existiert.
Auf Mobilgeräten ist der Effekt am stärksten ausgeprägt. 76 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten haben ein Bild als LCP-Element, 23,7 Prozent (HTTP Archive Web Almanac 2025) dagegen einen Textblock; auf dem Desktop sind es nur 14,4 Prozent (HTTP Archive Web Almanac 2025) Text. Ein Dialog, der auf einem 390 Pixel breiten Viewport zwei Drittel der Fläche einnimmt, bringt eine Überschrift, einen Beschreibungstext und zwei Schaltflächen mit. Er ist damit ein ernsthafter LCP-Kandidat, und er wird typischerweise später gezeichnet als das Hero-Bild darunter. In Performance-Audits ist dieser Befund einer der am häufigsten wiederkehrenden überhaupt (Projekterfahrung).
Der Schaden entsteht doppelt. Erstens verschiebt der spät gezeichnete Layer den Messzeitpunkt nach hinten. Zweitens konkurriert das Consent-Skript beim Verbindungsaufbau und beim Herunterladen mit genau den Ressourcen, die den sichtbaren Bereich füllen sollen. Auf einer Mobilverbindung mit begrenzter Bandbreite kostet jede zusätzliche Verbindung zu einem fremden Host Zeit, die dem Hero-Bild fehlt. Der Consent-Layer verlangsamt damit nicht nur sich selbst, sondern auch alles, was er eigentlich nur überdecken wollte.
Überdeckung des Hero-Bereichs
Der Layer legt sich über das Hero-Bild und bringt einen eigenen, großen Textblock mit. Der Browser wertet ihn als neuen, größeren Kandidaten und schreibt den LCP-Zeitpunkt fort.
Später Paint durch Fremdskript
Muss der Dialog erst durch ein externes Skript erzeugt werden, entstehen Verbindungsaufbau, Download, Parsen und DOM-Erzeugung, bevor überhaupt ein Pixel des Dialogs erscheint.
Eigene Schrift und Icons
Bringt der Layer eine eigene Webschrift oder eine Icon-Datei mit, wartet die Textdarstellung zusätzlich auf diese Ressourcen. Die Renderverzögerung wächst ohne inhaltlichen Gewinn.
Den Einfluss sauber messen statt schätzen
Ein Laborlauf zeigt den Consent-Layer selten in seiner echten Wirkung. Manche Testaufbauten starten mit leerem Profil, in dem der Dialog zwangsläufig erscheint, während ein großer Teil der realen Besucher ihn wegen einer gespeicherten Entscheidung gar nicht mehr sieht. Andere Aufbauten blockieren Fremdhosts und blenden den Dialog damit versehentlich aus. Belastbar wird die Bewertung erst mit Felddaten, die beide Fälle in ihrer tatsächlichen Häufigkeit enthalten. Wie sich Labor- und Feldmessung sinnvoll ergänzen, beschreibt der Beitrag zu Felddaten aus CrUX und eigenem Monitoring.
Der entscheidende Schritt ist, im Feld nicht nur den LCP-Wert, sondern auch das LCP-Element zu protokollieren. Der Chrome UX Report liefert die Verteilung der Werte, nicht aber die Information, welches Element sie verursacht. Diese Information liefert der Browser selbst über die Performance-Schnittstellen. Drei Beobachter genügen, um die Rolle des Consent-Layers zu klären: einer für das LCP-Element, einer für die Anteile der Zustimmen-Interaktion und einer für Layout-Verschiebungen samt Verursacher.
// LCP-Element im Feld protokollieren
new PerformanceObserver((list) => {
const entry = list.getEntries().at(-1);
const el = entry.element;
report('lcp', {
value: Math.round(entry.startTime),
tag: el ? el.tagName : null,
id: el ? el.id : null,
imConsentLayer: !!(el && el.closest('#consent-layer'))
});
}).observe({ type: 'largest-contentful-paint', buffered: true });
// Anteile der Zustimmen-Interaktion (INP)
new PerformanceObserver((list) => {
for (const e of list.getEntries()) {
if (!e.interactionId) continue;
report('interaction', {
ziel: e.target ? e.target.id : null,
eingabeverzoegerung: Math.round(e.processingStart - e.startTime),
verarbeitung: Math.round(e.processingEnd - e.processingStart),
darstellung: Math.round(e.startTime + e.duration - e.processingEnd)
});
}
}).observe({ type: 'event', durationThreshold: 40, buffered: true });
// Layout-Verschiebungen samt Verursacher
new PerformanceObserver((list) => {
for (const e of list.getEntries()) {
if (e.hadRecentInput) continue;
for (const q of e.sources || []) {
report('shift', { wert: e.value, knoten: q.node ? q.node.nodeName : null });
}
}
}).observe({ type: 'layout-shift', buffered: true });Für die Interaktion gelten klare Schwellen: Ein guter INP-Wert liegt bei 200 Millisekunden (Google web.dev) oder darunter, ab 500 Millisekunden (Google web.dev) gilt er als schlecht, jeweils gemessen am 75. Perzentil. Jede Interaktion zerfällt in Eingabeverzögerung, Verarbeitungsdauer der Ereignisbehandler und Darstellungsverzögerung (Google web.dev). Beim Klick auf Zustimmen laufen alle drei Anteile zusammen: Der Hauptthread ist noch mit dem Consent-Skript beschäftigt, die Ereignisbehandler starten anschließend eine ganze Reihe von Tags, und der Browser muss danach ein Bild ohne den Dialog zeichnen. Die Systematik dahinter behandelt der Beitrag zur Optimierung von Interaction to Next Paint.
Bei der Layoutstabilität kommt es auf die Bauweise an. Ein fixiertes Overlay steht außerhalb des Textflusses und verschiebt nichts. Ein Banner, das als Blockelement am Seitenanfang eingefügt wird, drückt den gesamten Inhalt nach unten und erzeugt beim Einblenden wie beim Entfernen eine Verschiebung. In den Felddaten erreichen 81 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten einen guten CLS-Wert, auf dem Desktop sind es 72 Prozent (HTTP Archive Web Almanac 2025). Wo der Wert reißt, ist ein spät eingefügter Layer ein naheliegender Verdächtiger.
| Metrik | Typischer Beitrag des Consent-Layers | Messmethode im Feld | Zielbereich |
|---|---|---|---|
| LCP | Layer überdeckt den Hero und wird selbst zum größten Element | LCP-Element mit Tag, ID und Container protokollieren | unter 2,5 Sekunden |
| INP | Zustimmen startet mehrere Tags gleichzeitig | Event Timing mit interactionId, Anteile getrennt erfassen | unter 200 Millisekunden |
| CLS | Einblenden schiebt Inhalt, Entfernen lässt ihn zurückspringen | Layout-Shift-Quellen mit Knotennamen protokollieren | unter 0,1 |
| TTFB | Zusätzlicher Fremdhost verlängert den Verbindungsaufbau | Navigation Timing und Server-Timing auswerten | rund 40 Prozent des LCP |
| Blockierzeit | Parsen und Ausführen des Consent-Skripts vor dem ersten Paint | Long Animation Frames mit verursachendem Skript | möglichst nahe null |
Das Banner-Markup serverseitig ausliefern
Die wirksamste Einzelmaßnahme ist zugleich die unspektakulärste: Die erste Ebene des Dialogs gehört in das HTML-Dokument, das der Server ohnehin ausliefert. Sie muss nicht von einem Skript erzeugt werden, das der Browser zuvor herunterlädt, parst und ausführt. Steht das Markup im Dokument, erscheint der Dialog mit dem ersten Bild der Seite. Die Ressourcen-Ladeverzögerung, die sonst zwischen Serverantwort und Darstellung liegt, entfällt für dieses Element vollständig.
Google web.dev empfiehlt als Orientierung eine Aufteilung des LCP, bei der die Serverantwortzeit rund 40 Prozent (Google web.dev) ausmacht, das Laden der LCP-Ressource ebenfalls rund 40 Prozent (Google web.dev) und die beiden Verzögerungsanteile - Ressourcen-Ladeverzögerung und Element-Renderverzögerung - jeweils unter 10 Prozent (Google web.dev) bleiben. Ein per Fremdskript nachgeladener Dialog schlägt exakt in diese beiden Verzögerungsanteile ein, also in die Bereiche, die laut derselben Quelle möglichst nahe null liegen sollten. Wer zusätzlich an der Serverantwortzeit arbeitet, findet die Hebel in unserer TTFB-Optimierung und im Beitrag zu Early Hints und der Serverdenkzeit.
<!-- Erste Ebene direkt in der Serverantwort, ohne Fremdskript -->
<style>
#consent-layer{position:fixed;inset:auto 0 0 0;z-index:9999;background:#fff;
border-top:1px solid #d3d8e2;padding:16px;contain:layout paint;
font:16px/1.5 system-ui,-apple-system,sans-serif}
#consent-layer[hidden]{display:none}
.cl-actions{display:flex;gap:12px;margin-top:12px}
.cl-actions button{flex:1 1 0;min-height:44px;font:inherit;cursor:pointer;
border:1px solid #2356a0;border-radius:8px;background:#fff;color:#132d5c}
</style>
<div id="consent-layer" role="dialog" aria-modal="true" aria-labelledby="cl-title">
<h2 id="cl-title">Cookies und Reichweitenmessung</h2>
<p>Optionale Cookies setzen wir erst nach Ihrer Einwilligung.</p>
<div class="cl-actions">
<button type="button" data-consent="deny">Ablehnen</button>
<button type="button" data-consent="allow">Akzeptieren</button>
</div>
<p><a href="/de/datenschutz/">Datenschutz</a> | <a href="/de/impressum/">Impressum</a></p>
</div>Rechtlich ist dieser Umbau unproblematisch, denn das Banner selbst ist nicht einwilligungsbedürftig. Einwilligung braucht das Speichern von Informationen auf dem Endgerät und das Auslesen bereits gespeicherter Informationen, nicht die Darstellung eines Hinweistextes. Serverseitig geliefertes Markup setzt keinen Cookie und ruft keinen fremden Host auf. Es erfüllt die Anforderung sogar besser als eine Skript-Lösung, die für die Anzeige des Dialogs zuerst eine Verbindung zu einem Drittanbieter aufbauen muss.
Den Consent-Zustand serverseitig kennen
Den Layer ohne Layout-Verschiebung aufbauen
Ein Consent-Layer verursacht keine Layout-Verschiebung, wenn er den Textfluss nicht anfasst. In der Praxis heißt das: position: fixed statt eines Blockelements am Dokumentanfang, eine Positionierung über inset statt über Abstände, die andere Elemente verdrängen, und contain: layout paint, damit Änderungen im Dialog keine Neuberechnung der übrigen Seite auslösen. Soll der Hinweis bewusst im Fluss stehen, gehört ihm ein Container mit fester Mindesthöhe, der vom ersten Bild an reserviert ist. Nachträgliches Einschieben erzeugt sonst zuverlässig eine Verschiebung.
Häufig kommt ein zweites Problem hinzu. 62 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten setzen bei mindestens einem Bild keine Abmessungen. Trifft ein spät eingefügter Layer auf Bilder ohne reservierten Platz, addieren sich zwei Verschiebungen zu einem sichtbaren Springen des gesamten Einstiegs. Die Systematik dahinter und die passenden Gegenmittel beschreibt der Beitrag zum Vermeiden von Layout-Verschiebungen.
Fixiert statt im Fluss
Ein Overlay mit fester Positionierung liegt außerhalb des Layouts. Ein- und Ausblenden verändern die Position keines anderen Elements, der CLS-Beitrag bleibt bei null.
Platz vorab reservieren
Soll der Hinweis im Fluss stehen, bekommt er einen Container mit fester Mindesthöhe, der bereits im ersten gerenderten Bild vorhanden ist. Der Inhalt füllt ihn, statt ihn aufzuspannen.
Nur kompositierte Animationen
Ein- und Ausblenden über transform und opacity laufen ohne Layoutberechnung. Höhen- oder Randanimationen erzwingen dagegen ein Neuberechnen des Layouts bei jedem Bild.
CSS, Schriften und Icons des Dialogs
Ein eigenes Stylesheet für den Consent-Layer ist eine render-blockierende Datei mehr, und zwar an der empfindlichsten Stelle des Ladevorgangs. Die erste Ebene braucht selten mehr als zwei bis vier Kilobyte CSS: Hintergrund, Rahmen, Typografie, zwei Schaltflächen, ein Fokusstil. Diese wenigen Regeln gehören inline in das Dokument. Alles Weitere - die Einstellungsebene mit Zwecken, Beschreibungen und Anbieterliste - kann nachgeladen werden, wenn jemand sie tatsächlich öffnet. Das Vorgehen entspricht dem Prinzip, das der Beitrag zu Critical CSS für den sichtbaren Bereich beschreibt.
Bei Schriften lohnt derselbe strenge Blick. 87 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten binden mindestens eine Webschrift ein. Bringt der Consent-Layer eine zusätzliche Schrift mit, weil das Werkzeug ein eigenes Design mitliefert, wartet die Textdarstellung des Dialogs auf eine weitere Datei von einem weiteren Host. Sinnvoll ist stattdessen die Schrift, die die Seite ohnehin lädt, oder der System-Schriftstapel. Welche Stellschrauben es dabei gibt, zeigt der Beitrag zur Performance von Webschriften.
Icons folgen der gleichen Logik. Ein Dialog braucht selten mehr als zwei oder drei Symbole; diese gehören als Inline-SVG in das Markup, nicht als Icon-Schrift oder Sprite-Datei. Damit entfällt eine weitere Anfrage im kritischen Pfad, und die Symbole erscheinen zeitgleich mit dem Text. Wer diese Punkte zusammen angeht, arbeitet an derselben Baustelle wie die Frontend-Optimierung insgesamt.
- CSS der ersten Ebene inline im Dokument, kein eigenes Stylesheet im kritischen Pfad
- Keine zusätzliche Webschrift allein für den Dialog, stattdessen vorhandene Schrift oder Systemschrift
- Symbole als Inline-SVG statt als Icon-Schrift oder externe Sprite-Datei
- Kein Hintergrundbild und kein Verlaufsbild, das der Browser erst laden muss
- Schaltflächen mit mindestens 44 Pixel Zielgröße, damit Fehlklicks keine zweite Interaktion erzwingen
- Fokusreihenfolge und Beschriftungen im Markup, nicht per Skript nachträglich ergänzt
Nachlade-Skripte erst nach der Einwilligung starten
Dass einwilligungsbedürftige Skripte vor der Entscheidung nicht laufen dürfen, ist keine Optimierungsfrage, sondern Vorgabe. Die Orientierungshilfe der Datenschutzkonferenz formuliert es unmissverständlich: Während das Einwilligungsbanner angezeigt wird, werden zunächst keine weitergehenden Skripte geladen, die auf die Endgeräte zugreifen oder personenbezogene Daten verarbeiten, und insbesondere auch keine Inhalte von fremden Servern, soweit dafür eine Einwilligung erforderlich ist (DSK-Orientierungshilfe). Die Performance-Wirkung ist ein willkommener Nebeneffekt: Alles, was hinter die Entscheidung rückt, liegt nicht mehr im kritischen Pfad.
Der zweite Teil wird häufig übersehen. Nach der Zustimmung starten viele Implementierungen sämtliche Tags in einem einzigen Rutsch, ausgelöst direkt im Klick-Ereignis. Genau in diesem Moment misst der Browser die Interaktion. Aus einem an sich trivialen Klick wird so eine Interaktion mit langer Verarbeitungsdauer und verzögerter Darstellung. Sinnvoller ist ein gestaffelter Start: Der Klick blendet nur den Layer aus und speichert die Entscheidung; die Tags folgen in Leerlaufphasen, nach Sichtbarkeit oder auf Interaktion. Welche Muster sich dafür bewährt haben, beschreibt der Beitrag zum Entschlacken von Drittanbieter-Skripten.
const layer = document.getElementById('consent-layer');
layer.addEventListener('click', async (ev) => {
const btn = ev.target.closest('[data-consent]');
if (!btn) return;
const erlaubt = btn.dataset.consent === 'allow';
layer.hidden = true; // fixiertes Overlay: Ausblenden ohne Layout-Sprung
speichereConsent(erlaubt); // eigener First-Party-Cookie, kein Fremdaufruf
if (!erlaubt) return;
// Erst jetzt und gestaffelt: nichts davon liegt im kritischen Pfad
await naechsteLuecke();
ladeSkript('/assets/messung.js');
await naechsteLuecke();
beiSichtbarkeit('.karten-einbettung', () => ladeSkript('/assets/karte.js'));
});
function naechsteLuecke() {
return new Promise((fertig) => {
if (window.scheduler && scheduler.yield) return scheduler.yield().then(fertig);
if (window.requestIdleCallback) return requestIdleCallback(fertig, { timeout: 500 });
setTimeout(fertig, 0);
});
}Der erste Klick prägt den Qualitätseindruck
Den DOM-Umfang des Dialogs begrenzen
Consent-Werkzeuge liefern häufig vollständige Zweck- und Anbieterlisten mit, auch wenn niemand sie öffnet. Aus einem Dialog mit fünf sichtbaren Zeilen werden so schnell mehrere tausend DOM-Knoten. Google web.dev weist ausdrücklich darauf hin, dass die Renderarbeit mit wachsender DOM-Größe steigt: Bei kleinem DOM ist sie schnell erledigt, bei sehr großem DOM skaliert sie mit (Google web.dev). Betroffen sind damit nicht nur der erste Aufbau, sondern jede spätere Stiländerung und jede Interaktion.
Die Schachtelung verstärkt den Effekt. Der HTTP Archive Web Almanac 2025 misst für Einbindungsketten von Drittanbietern eine mediane Tiefe von 3 Ebenen (HTTP Archive Web Almanac 2025) und im Extremfall 2.285 Ebenen (HTTP Archive Web Almanac 2025). Ein Consent-Werkzeug, das Anbieterlisten dynamisch nachlädt und dabei selbst wieder Ressourcen einbindet, sitzt genau in dieser Kette. Sinnvoll ist deshalb eine klare Trennung: Ebene eins mit Text, zwei gleichwertigen Schaltflächen und den Pflichtangaben im Markup, alles Weitere erst beim Öffnen.
Wenn lange Listen unvermeidbar sind, hilft es, dem Browser die Renderarbeit für nicht sichtbare Abschnitte zu ersparen. Wie das funktioniert, zeigt der Beitrag zu content-visibility und eingesparter Renderarbeit; die allgemeine Systematik zur Knotenzahl behandelt der Beitrag zum Reduzieren der DOM-Größe.
Ein Consent-Dialog braucht auf der ersten Ebene selten mehr als dreißig DOM-Knoten. Alles darüber hinaus ist Vorratshaltung für einen Fall, der bei den meisten Besuchen ausbleibt - und er wird trotzdem bei jedem einzelnen Aufruf bezahlt.
Was der Rechtsrahmen vorgibt
Die Grundlage bildet § 25 TDDDG, die Nachfolgevorschrift des früheren TTDSG, zusammen mit den Anforderungen der DSGVO an eine wirksame Einwilligung. Die Datenschutzkonferenz stellt klar, dass die Willenserklärung bereits erteilt sein muss, bevor der einwilligungsbedürftige Zugriff auf die Endeinrichtung erfolgt; es ist nicht zulässig, einwilligungsbedürftige Cookies bereits mit dem erstmaligen Aufruf einer Website zu setzen und erst anschließend die Einwilligung abzufragen (DSK-Orientierungshilfe). Eine Optimierung, die Skripte vorzieht, um den Ladevorgang zu glätten, ist damit ausgeschlossen.
Ebenso klar sind die Anforderungen an die Gestaltung. Nach der Orientierungshilfe wird die Freiwilligkeit spürbar beeinflusst, wenn die Ablehnung aller einwilligungsbedürftigen Zugriffe einen messbaren Mehraufwand bedeutet, etwa weil sie erst auf einer zweiten Banner-Ebene und damit mit einer höheren Anzahl an Klicks möglich ist (DSK-Orientierungshilfe). Eine Ablehnfunktion auf der ersten Ebene halten die Aufsichtsbehörden dann für erforderlich, wenn Nutzerinnen und Nutzer mit dem Banner interagieren müssen, um den Besuch fortzusetzen (DSK-Orientierungshilfe). Damit hängt die rechtliche Anforderung unmittelbar an derselben Designentscheidung, die auch die Metrik beeinflusst: Wer den sichtbaren Bereich mit einem Layer verdeckt, braucht die gleichwertige Ablehnoption.
Der Europäische Datenschutzausschuss hat die wiederkehrenden Muster in seinem Bericht der Cookie Banner Taskforce zusammengetragen. Zu den beanstandeten Gestaltungen gehören unter anderem vorangekreuzte Kästchen, irreführend gestaltete Verweise und Farbgebungen sowie das Setzen einwilligungsbedürftiger Cookies vor der Entscheidung (EDPB Cookie Banner Taskforce). Hinzu kommt Artikel 7 Absatz 3 DSGVO: Der Widerruf einer Einwilligung muss so einfach möglich sein wie ihre Erteilung. Ein Consent-Layer, der beim ersten Aufruf schlank ist, seine Widerrufsmöglichkeit aber nur über verschachtelte Menüs anbietet, löst das Problem nur zur Hälfte.
| Maßnahme | Wirkung auf die Ladezeit | Rechtliche Bewertung |
|---|---|---|
| Banner-Markup im HTML ausliefern | Entfernt eine komplette Skript-Runde aus dem kritischen Pfad | Zulässig, die Anzeige selbst ist nicht einwilligungsbedürftig |
| CSS der ersten Ebene inline | Spart eine render-blockierende Datei | Zulässig, betrifft nur die Darstellung |
| Skripte erst nach aktiver Handlung laden | Verlagert die gesamte Drittanbieter-Last hinter den ersten Paint | Vorgeschrieben nach § 25 TDDDG und DSK-Orientierungshilfe |
| Anbieterliste erst auf der zweiten Ebene rendern | Senkt den DOM-Umfang deutlich | Zulässig, sofern die erste Ebene vollständig informiert |
| Ablehnen-Schaltfläche weglassen, um Knoten zu sparen | Vernachlässigbarer Gewinn | Unzulässig, wenn das Banner Inhalte verdeckt (DSK) |
| Zustimmung durch Scrollen oder Weiterklicken werten | Erspart eine Interaktion | Keine wirksame Einwilligung (EDPB Cookie Banner Taskforce) |
Tempo rechtfertigt keine Abkürzung
In welcher Reihenfolge der Umbau wirkt
Die Maßnahmen unterscheiden sich deutlich in Aufwand und Wirkung. Wer mit der Messung beginnt, vermeidet Umbauten an Stellen, die im Feld gar keine Rolle spielen. Erst wenn feststeht, dass der Layer tatsächlich als LCP-Element auftaucht oder die Zustimmen-Interaktion die INP-Verteilung dominiert, lohnt der Eingriff in die Auslieferung. Die folgende Reihenfolge hat sich in Audits bewährt.
- LCP-Element im Feld protokollieren und getrennt nach Erst- und Wiederbesuch auswerten
- Anteile der Zustimmen-Interaktion messen: Eingabeverzögerung, Verarbeitung, Darstellung
- Layout-Verschiebungen mit Verursacherknoten erfassen, um Einblenden und Ausblenden zu trennen
- Erste Ebene des Dialogs serverseitig ausliefern und das zugehörige CSS inline stellen
- Overlay fixiert positionieren oder Platz reservieren, Animationen auf transform und opacity begrenzen
- Schrift- und Icon-Last des Dialogs entfernen, Anbieterliste auf die zweite Ebene verlagern
- Nachlade-Skripte gestaffelt nach der Entscheidung starten und erneut im Feld gegenmessen
In den meisten Projekten sind die ersten drei Schritte an einem Tag erledigt, weil sie keine Änderung am Produktivsystem erfordern. Die Umbauten selbst hängen davon ab, wie tief das eingesetzte Consent-Werkzeug in die Seite eingreift. Wir ordnen den Befund im Rahmen einer technischen Performance-Analyse ein, prüfen ihn gegen den Lighthouse-Audit und setzen die Umbauten als Teil der Frontend-Optimierung um. Den Gesamtüberblick über die Metriken und ihre Ursachen bietet die Seite zu den Core Web Vitals, einen Überblick über den Leistungsumfang die Leistungsübersicht.
Ein Element, drei Metriken
Quellen und Studien
Verwandte Artikel
Speculation Rules: Instant-Navigation per Prerendering
Wie die Speculation Rules API Folgeseiten prefetcht oder prerendert, Eagerness richtig tunt, verschwendete Prerenders und Analytics-Nebenwirkungen vermeidet.
Mobile Performance: Shops auf Smartphones beschleunigen
Wie gedrosselte CPU, langsames Netz, Viewport und Touch die mobilen Core Web Vitals verschieben und Ihren Shop auf dem Smartphone messbar beschleunigen.
Lange Tasks aufteilen: INP mit scheduler.yield senken
Lange JavaScript-Tasks über 50 ms mit scheduler.yield() in Häppchen zerlegen, den Hauptthread zwischen den Chunks freigeben und den INP unter 200 ms halten.