Schnelle Seiten, falsche Einwilligung

Seiten-Caching gehört zu den besten Maßnahmen für Geschwindigkeit und Hosting-Kosten. Es ist auch eine der einfachsten Möglichkeiten, ein Consent-Setup unbemerkt zu zerstören. Ein Cache tut genau, was man ihm sagt: Er speichert eine Antwort einmal und liefert sie an alle aus, die zum selben Schlüssel passen. Enthält die gespeicherte Antwort etwas, das spezifisch für die Einwilligung oder den Standort eines Besuchers ist, bekommt es der nächste Besucher ebenfalls.

Dieser Leitfaden behandelt die Caching-Ebenen, die typischerweise vor einer Publisher-Website sitzen — CDN-Edge-Caches, Full-Page-Caching-Plugins, Reverse Proxys, Service Worker und der Browser selbst — und wie Sie verhindern, dass jede davon das falsche Einwilligungserlebnis ausliefert.

Die Kernregel: Einwilligung aus dem gecachten HTML heraushalten

Die sicherste Architektur rendert die gecachte HTML-Seite einwilligungsneutral. Die Seite enthält den CMP-Loader und Ihre Tags in einem blockierten oder wartenden Zustand, aber keine Entscheidung über diesen einen Besucher. Die CMP läuft dann im Browser, liest die gespeicherte Entscheidung, entscheidet, ob das Banner angezeigt wird, und gibt Tags entsprechend frei.

Probleme beginnen, wenn der Server beim Rendern Einwilligungsentscheidungen trifft, zum Beispiel:

• ein Theme oder Plugin, das Werbe- oder Analytics-Tags nur ausgibt, wenn ein Einwilligungs-Cookie vorhanden ist;
• serverseitiger Code, der das Banner-Markup für Besucher weglässt, die bereits gewählt haben;
• Templates, die den Einwilligungsstatus eines Besuchers in eine Inline-Skriptvariable einbetten.

Sobald diese Seite gecacht ist, wird der Status des ersten Besuchers zum Status aller. Ein Besucher, der Tracking abgelehnt hat, erhält womöglich eine Seite mit bereits aktiven Tags, oder ein neuer Besucher sieht nie ein Banner, weil die gecachte Kopie von jemandem stammt, der es bereits weggeklickt hat.

Warum „Vary: Cookie“ selten die Antwort ist

Die Lehrbuchlösung für besucherspezifische Inhalte ist, Caches anzuweisen, nach dem Cookie-Header zu variieren. In der Praxis tragen Besucher viele Cookies mit eindeutigen Werten, sodass das Variieren nach dem gesamten Cookie-Header Ihre Cache-Trefferquote meist auf nahezu null drückt. Einige CDNs erlauben stattdessen, den Cache-Schlüssel aus dem Wert eines einzelnen Cookies zu bilden, was praktikabel ist, wenn Ihr Einwilligungs-Cookie nur wenige mögliche Zustände hat, aber es erhöht die Komplexität und vervielfacht trotzdem die Zahl der gecachten Kopien. Die Entscheidung in den Browser zu verlagern ist einfacher und hält den Cache effizient.

Geografie am Edge

Viele Publisher zeigen je nach Region unterschiedliche Banner: ein Opt-in-Banner für die EU und UK, einen Opt-out-Hinweis für US-Bundesstaaten und etwas Schlankeres anderswo. Wählt der Server die Variante anhand der IP-Adresse des Besuchers und wird diese Seite gecacht, kann ein europäischer Leser eine gecachte US-Seite erhalten oder umgekehrt.

Drei Muster vermeiden das:

1. Clientseitige Geolokalisierung. Lassen Sie die CMP die Region im Browser bestimmen, sodass das gecachte HTML für alle gleich bleibt.
2. Land im Cache-Schlüssel. Wenn Sie am Edge entscheiden müssen, nehmen Sie den vom CDN gelieferten Ländercode in den Cache-Schlüssel auf. Sie erhalten eine gecachte Kopie pro Land, was vorhersehbar ist.
3. Ungecachte Edge-Logik. Führen Sie die regionale Entscheidung in einer Edge-Funktion aus, die einen kleinen, ungecachten Wert in eine ansonsten gecachte Seite einfügt.

Für welches Sie sich auch entscheiden, dokumentieren Sie es. Geo-Fehler gehören zu den am schwersten reproduzierbaren, weil sie nur bei Besuchern an einem Ort auftreten, die zufällig eine von jemandem an einem anderen Ort gecachte Seite erhalten.

Das CMP-Skript selbst cachen

Den CMP-Loader lange zu cachen ist gut für die Performance, hat aber einen Preis, wenn sich die Konfiguration ändert. Aktualisieren Sie Vendors, Zwecke oder Banner-Text, und das Skript oder die Konfigurationsdatei ist ein Jahr lang gecacht, sehen manche Besucher weiter die alte Version. Prüfen Sie, wie Ihre CMP ihre Dateien versioniert: Ein sich ändernder Dateiname oder Versionsparameter erlaubt aggressives Caching und dennoch sofortiges Ausrollen von Änderungen. Bestätigen Sie außerdem, dass Ihr eigenes CDN keine Query-Strings aus URLs von Drittanbieter-Skripten entfernt, wenn die CMP auf sie angewiesen ist.

Service Worker und Offline-Caches

Websites mit einer Progressive-Web-App-Schicht cachen HTML oft in einem Service Worker. Es gilt dieselbe Regel: Speichern Sie nie eine Seite, die eine bestimmte Einwilligungsentscheidung widerspiegelt. Schließen Sie einwilligungsbezogene Endpunkte und Seiten des Präferenzcenters vom Service-Worker-Caching aus und stellen Sie sicher, dass immer eine frische CMP-Konfiguration abgerufen werden kann.

Der Back/Forward-Cache

Moderne Browser halten kürzlich besuchte Seiten im Speicher, damit die Zurück-Taste sie sofort wiederherstellt. Öffnet ein Besucher auf einer Seite das Präferenzcenter, widerruft die Einwilligung und drückt dann „Zurück“, laufen auf der wiederhergestellten Seite womöglich noch Tags von vorher. Achten Sie auf das Ereignis pageshow und prüfen Sie dessen Eigenschaft persisted: Wird eine Seite aus diesem Cache wiederhergestellt, lesen Sie den gespeicherten Einwilligungsstatus erneut aus und stoppen oder starten Sie Tags entsprechend.

Eine Testroutine

• Laden Sie eine Seite in einer sauberen Sitzung, lehnen Sie ab, laden Sie dann eine zweite Seite und bestätigen Sie, dass keine Tracking-Tags feuern.
• Wiederholen Sie das mit einem zweiten sauberen Browser und bestätigen Sie, dass das Banner erscheint, womit belegt ist, dass es nicht weggecacht wurde.
• Prüfen Sie die Antwort-Header, um zu sehen, ob Seiten aus dem Cache ausgeliefert werden, und vergleichen Sie das HTML mit und ohne Einwilligungs-Cookie — es sollte identisch sein.
• Testen Sie nach dem Leeren des Caches aus mindestens zwei Regionen und dann erneut, nachdem der Cache warm ist.
• Widerrufen Sie die Einwilligung, nutzen Sie die Zurück-Taste und prüfen Sie, dass Tags stoppen.

Wichtigste Erkenntnisse

• Gecachtes HTML sollte einwilligungsneutral sein; lassen Sie die CMP im Browser entscheiden.
• Variieren Sie nicht nach dem gesamten Cookie-Header; das zerstört die Trefferquote.
• Wenn Banner je nach Region abweichen, entscheiden Sie clientseitig oder nehmen Sie das Land in den Cache-Schlüssel auf.
• Versionieren Sie CMP-Dateien, damit lange Cache-Laufzeiten Konfigurationsänderungen nicht verzögern.
• Berücksichtigen Sie Service Worker und den Back/Forward-Cache und testen Sie bei warmem Cache, nicht nur nach dem Leeren.