Cookie-Banner und Core Web Vitals: So bleiben LCP, CLS und INP grün

Ein Cookie-Banner kann alle drei Core Web Vitals verschlechtern: Er kann den Largest Contentful Paint (LCP) verzögern oder selbst zum LCP-Element werden, Inhalte verschieben und so den Cumulative Layout Shift (CLS) erhöhen, und er kann den Akzeptieren-Button träge wirken lassen, was sich in der Interaction to Next Paint (INP) niederschlägt. Die Lösungen sind bekannt: das Consent-Skript asynchron laden, den Banner als fixiertes Overlay rendern, sekundäre Oberflächen nachladen und Klick-Handler schlank halten.

Warum beeinflussen Cookie-Banner die Core Web Vitals?

Ein Banner ist oft das Erste, was ein neuer Besucher sieht, und er besteht aus JavaScript, CSS und Text, die mit Ihren eigentlichen Inhalten um Bandbreite und Main-Thread-Zeit konkurrieren. Die Core Web Vitals messen genau diese Konkurrenz, bewertet am 75. Perzentil echter Seitenaufrufe.

Metrik	Was sie misst	Schwellenwert für „gut“	Wie ein Banner sie verschlechtern kann
LCP	Wann das größte Bild oder der größte Textblock gerendert wird	2,5 s oder weniger	Ein renderblockierendes Consent-Skript oder der Banner selbst als größtes Element
CLS	Wie stark sich sichtbare Inhalte unerwartet verschieben	0,1 oder weniger	Ein in den Seitenfluss eingefügter Banner, der Inhalte nach unten schiebt
INP	Wie schnell die Seite auf Klicks, Taps und Tastatureingaben reagiert	200 ms oder weniger	Aufwendige Verarbeitung im Handler für Akzeptieren oder Ablehnen

INP hat im März 2024 den First Input Delay (FID) abgelöst, und das ist für Consent relevant. FID hat nur die Verzögerung gemessen, bis die erste Interaktion verarbeitet wurde; INP misst die gesamte Zeit von jeder Interaktion bis zum nächsten Frame, und „Alle akzeptieren“ ist oft das Erste, was ein Besucher anklickt.

Wie verhindere ich, dass das Consent-Skript den LCP blockiert?

Laden Sie es mit async und halten Sie es klein. Ein synchrones Skript im <head> hält den HTML-Parser an, bis es heruntergeladen und ausgeführt ist. Das verzögert Ihre Überschrift und Ihr Hero-Bild ebenso wie alles andere.

<head>
  <script src="https://consent.example.com/loader.js" async></script>

  <!-- Inaktiv, bis das Consent-Skript es nach einem Opt-in aktiviert -->
  <script type="text/plain" data-consent="analytics"
          src="https://analytics.example.com/script.js"></script>
</head>

Asynchrones Laden ist unbedenklich, wenn nicht notwendige Tags wie hier inaktiv sind: Nichts läuft, bevor das Consent-Skript es erlaubt. Auto-Blocking-Ansätze, die Skripte beim Einfügen abfangen, müssen in der Regel synchron vor allen anderen Skripten laufen, was Renderzeit kostet. Unser Leitfaden zum Blockieren von Skripten bis zur Einwilligung vergleicht die Methoden.

Die zweite LCP-Falle ist der Banner selbst. Der LCP meldet das größte Bild oder den größten Textblock, der im Viewport gerendert wird, bevor der Besucher interagiert. Auf einem kleinen Smartphone kann ein Banner mit einem langen Absatz größer sein als Ihre Überschrift, und wenn er spät gerendert wird, ist Ihr LCP spät. Halten Sie den Text der ersten Ebene knapp, verwenden Sie eine Systemschrift, damit er nie auf einen Webfont warten muss, und liefern Sie den Banner nie als Bild aus.

Den Banner zu verzögern hilft nicht: Ein später Banner kann trotzdem zum LCP-Element werden, nur eben später.

Wie verhindere ich, dass der Banner Layout Shifts verursacht?

Rendern Sie ihn als fixiertes Overlay. Der CLS zählt Bewegungen bestehender Inhalte, ein Element mit position: fixed, das über der Seite erscheint, verschiebt also nichts. Der klassische Fehler ist eine Leiste, die nach dem ersten Rendern oben in den <body> eingefügt wird und die gesamte Seite nach unten schiebt.

.consent-banner {
  position: fixed;
  inset: auto 0 0 0; /* am unteren Rand fixiert, außerhalb des Dokumentflusses */
  z-index: 1000;
  font: 1rem/1.5 system-ui, sans-serif; /* kein Webfont, auf den gewartet werden muss */
  animation: consent-in 200ms ease-out;
}

@keyframes consent-in {
  from { transform: translateY(100%); }
}

@media (prefers-reduced-motion: reduce) {
  .consent-banner { animation: none; }
}

Wenn Sie animieren, animieren Sie transform oder opacity. Animationen von top, height oder margin verändern das Layout und können als Verschiebungen gezählt werden. Braucht Ihr Design tatsächlich einen Banner im Seitenfluss, reservieren Sie seinen Platz im serverseitig gerenderten HTML. Das funktioniert nur dann gut, wenn der Server das Consent-Cookie ausliest und den Platz für wiederkehrende Besucher weglässt.

Planen Sie auch, was nach der Einwilligung passiert. Verschiebungen innerhalb von 500 ms nach einem Klick oder Tastendruck werden beim CLS nicht berücksichtigt, ein Anzeigenplatz, ein Video-Embed oder ein Chat-Widget, das ein paar Sekunden später lädt, hingegen schon. Geben Sie diesen Containern feste Abmessungen oder ein aspect-ratio.

Wie lade ich Banner-Oberflächen nach, ohne die Compliance zu gefährden?

Liefern Sie die erste Ebene sofort aus und laden Sie das Präferenzcenter bei Bedarf nach. Die erste Ebene besteht aus einer kurzen Nachricht und einigen Buttons; die zweite Ebene mit Kategorieschaltern, Anbieterlisten und Cookie-Tabellen ist in der Regel der schwere Teil.

Was Sie nicht aufschieben dürfen, ist die Wahlmöglichkeit. „Alle ablehnen“ gehört auf die erste Ebene, genauso prominent wie „Alle akzeptieren“. Im Dezember 2021 verhängte die französische CNIL gegen Google ein Bußgeld von 150 Mio. € und gegen Facebook eines von 60 Mio. €, weil das Ablehnen von Cookies schwieriger war als das Akzeptieren. Lesen Sie dazu Dark Patterns in Cookie-Bannern und unsere Best Practices für das Banner-Design.

Wie halte ich Akzeptieren und Ablehnen für INP reaktionsschnell?

Erledigen Sie vor dem nächsten Rendern nur das Nötigste und geben Sie dann den Main Thread frei. Ein langsamer Handler schreibt typischerweise das Consent-Cookie, sendet ein Einwilligungsprotokoll, aktualisiert Google Consent Mode und fügt mehrere Anbieter-Skripte in einem einzigen langen Task ein, sodass der Button wie eingefroren wirkt.

function yieldToMain() {
  if (globalThis.scheduler?.yield) return globalThis.scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

acceptButton.addEventListener('click', async () => {
  banner.remove();                                    // 1. zuerst sichtbares Feedback
  saveConsent({ analytics: true, marketing: true });  // 2. klein und synchron
  await yieldToMain();                                // 3. den Browser rendern lassen
  activateTags(['analytics', 'marketing']);           // 4. aufwendige Arbeit in einem späteren Task
});

customizeButton.addEventListener('click', async () => {
  customizeButton.setAttribute('aria-busy', 'true');
  const { openPreferences } = await import('./preference-center.js'); // bei Bedarf geladen
  openPreferences();
});

Senden Sie das Einwilligungsprotokoll mit navigator.sendBeacon(), damit Netzwerkarbeit die Interaktion nie aufhält, und aktivieren Sie viele Tags in Gruppen mit einem Yield dazwischen. scheduler.yield() ist noch nicht in jedem Browser verfügbar, daher der Fallback.

Wie teste ich die Auswirkungen eines Banners?

Testen Sie als neuer Besucher und anschließend als wiederkehrender. Lab-Tools wie Lighthouse starten mit leerem Speicher und sehen den Banner daher immer:

1. Öffnen Sie die Seite in einem frischen Browserprofil aus einer Region, in der der Banner erscheint.
2. Führen Sie Lighthouse oder PageSpeed Insights aus und prüfen Sie, welches Element als LCP-Element gemeldet wird.
3. Zeichnen Sie im Performance-Panel der Chrome DevTools einen Trace auf, klicken Sie auf „Alle akzeptieren“ und suchen Sie nach langen Tasks nach dem Klick.
4. Prüfen Sie im selben Trace, ob Layout Shifts auftreten, während der Banner erscheint und nachdem Tags geladen wurden.
5. Wiederholen Sie den Test als wiederkehrender Besucher mit gespeicherter Einwilligung, da dann mehr Tags laufen.
6. Vergleichen Sie anschließend die Felddaten in der Search Console oder in PageSpeed Insights. Sie decken ein rollierendes 28-Tage-Fenster ab, Änderungen zeigen sich also nach und nach.

Fazit

Ein Consent-Banner muss Sie keine guten Core-Web-Vitals-Werte kosten. Laden Sie ihn asynchron, halten Sie ihn aus dem Dokumentfluss heraus, laden Sie die schwere zweite Ebene nach und halten Sie Klick-Handler schlank, während jede Wahl gleich einfach bleibt. Tools wie Cookiesh können die Ladeseite übernehmen, mit einem asynchronen Loader unter 5 kB (gzip), ausgeliefert über ein globales Edge-CDN und so gebaut, dass Layout Shifts vermieden werden.

Dieser Artikel dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für Entscheidungen zu Ihrer konkreten Situation wenden Sie sich an qualifizierte Datenschutzfachleute.