8.000 Cookies, die keiner bestellt hat – wie ein Login-Popup das Cookie-Banner lahmlegte

Christopher Zechendorf

21.09.2026

Share:

Warum die mobile VINUM-Seite plötzlich langsam war, obwohl sich am Code nichts geändert hatte – und wie ein Login-Formular das Cookie-Banner aufblähte.

„Auf dem Handy geht nichts mehr”

Die Meldung kam vom Kunden: Die Website der internationalen Weinplattform VINUM, die wir technisch betreuen, arbeite auf dem Handy schwer. Die Seite lade sehr langsam, das Menü lasse sich nicht anklicken. Die naheliegende Vermutung des Kunden: ein Update, das etwas kaputt gemacht hat.

Nur: Es gab kein Update. Die letzte Änderung an Templates, Styles und JavaScript lag zehn Tage zurück. Trotzdem ließ sich das Problem nachstellen – beim Tippen auf das Burger-Menü fror die Seite ein.

Die Ursache lag am Ende weder allein im eigenen Code noch allein beim Drittanbieter, sondern im Zusammenspiel beider. Genau deshalb ist dieser Fall lehrreich: Er zeigt, wie sich ein unscheinbares Detail im eigenen System und ein nützliches Werkzeug eines Dienstleisters gegenseitig hochschaukeln können.

Die Herausforderung

Wenn sich eine Website verschlechtert, ohne dass sich an ihr etwas geändert hat, fällt die übliche Frage „Was haben wir zuletzt angefasst?” weg. Dazu kam:

• Auf dem Desktop war kaum etwas zu merken. Ein schneller Rechner steckt viel weg, was ein Mittelklasse-Handy in die Knie zwingt.
• Das Symptom war nicht die Ursache. Ein hakendes Menü lädt dazu ein, im Menü-JavaScript zu suchen. Dort war aber alles in Ordnung.
• Die Website hängt nicht nur von eigenem Code ab. Wie fast jede Seite mit Werbung und Statistik bindet VINUM externe Dienste ein – unter anderem die Consent-Lösung CookieYes, die das Cookie-Banner ausliefert. Deren Inhalte ändern sich, ohne dass im eigenen Repository ein Commit entsteht.

Unsere Lösung

1. Messen statt raten

Statt im Code zu suchen, haben wir die Live-Seite so vermessen, wie ein Handy sie erlebt: mit dem Browser-Automatisierungswerkzeug Playwright, einem emulierten iPhone und einer sechsfach gedrosselten CPU. Gezählt wurden die Elemente im Seitenaufbau (DOM), die geladenen Dateien und ihre Größe sowie die Phasen, in denen der Browser so beschäftigt ist, dass er auf nichts anderes reagieren kann.

Das Ergebnis war eindeutig:

• Beim Abschluss des Ladens bestand die Startseite aus 2.653 Elementen. Kurz danach waren es 84.156.
• Über 81.000 davon steckten in einem Bereich, den kein Besucher sieht: in den versteckten Cookie-Einstellungen des Banners, genauer in der Liste aller Cookies, die die Website angeblich verwendet.
• Diese Liste lud das Banner als eigene Datei nach: 1,5 MB Daten mit 8.138 Einträgen.

Und das bei jedem Besucher, auf jeder Seite – auch bei Stammlesern, die längst eingewilligt hatten und das Banner nie zu Gesicht bekamen.

2. Die Gegenprobe

Eine Vermutung ist erst belastbar, wenn man sie abschalten kann. Deshalb haben wir dieselbe Seite ein zweites Mal geladen und die Cookie-Liste im Test durch eine leere ersetzt. Der Unterschied:

• 84.156 → 10.902 Elemente im Seitenaufbau
• Längste Blockade des Browsers: rund 1.000 ms → rund 450 ms

Eine Sekunde, in der ein Handy auf keinen Fingertipp reagiert, erklärt ein „eingefrorenes” Menü gut. Im emulierten Browser ließ sich das Menü übrigens trotzdem noch öffnen. Die tatsächliche Blockade hängt stark vom Gerät ab – auf einem echten Mittelklasse-Handy kommen noch Arbeitsspeicher und ein langsamerer Prozessor dazu. Das ist einer der Gründe, warum wir Performance nie nur am Schreibtisch beurteilen.

3. Woher kommen 8.000 Cookies?

Die spannendere Frage war, warum eine Website mit rund 20 echten Cookies eine Liste mit über 8.000 Einträgen hat. Ein Blick in die Liste beantwortete sie: 8.118 Einträge trugen fast denselben Namen – typo3nonce_ gefolgt von einer zufälligen Zeichenfolge. Keiner davon hatte eine Beschreibung.

Solche Cookies setzt TYPO3 als Teil seines Schutzes gegen gefälschte Formularübermittlungen (CSRF). Wer ein Formular abschickt, muss belegen, dass er es vorher wirklich von der Website erhalten hat – dafür bekommt jedes ausgelieferte Formular ein Einmal-Merkmal, und der Browser ein passendes Cookie mit eindeutigem, zufälligem Namen. Das ist sinnvoll und gewollt.

Das Problem war, wo dieses Formular steckte: Das Login-Fenster für Abonnentinnen und Abonnenten war als unsichtbares Popup im Footer jeder Seite eingebaut – inklusive vollständigem, signiertem Login-Formular. Jeder anonyme Seitenaufruf erzeugte damit ein neues Cookie mit neuem Namen, auch wenn niemand sich anmelden wollte.

Jetzt kommt der Cookie-Scanner ins Spiel. Consent-Lösungen durchsuchen die Website regelmäßig automatisch nach Cookies, damit die Liste im Banner vollständig ist. Nach einem Tarifwechsel lief bei VINUM der erste Scan seit langer Zeit – über rund 8.000 Seiten. Der Scanner besuchte jede Seite wie ein neuer Besucher, bekam auf jeder ein Cookie mit anderem Namen und trug jedes brav als eigenes Cookie in die Liste ein. Diese Liste wurde veröffentlicht, und ab diesem Moment lud jeder Besucher sie mit.

Keines der beiden Systeme hat für sich genommen etwas falsch gemacht. Erst zusammen wurde es zum Problem.

4. Sofortmaßnahme: die Liste bereinigen

Die schnellste Entlastung lag beim Cookie-Banner selbst: Wir haben die 8.118 überzähligen Einträge noch am selben Tag im CookieYes-Konto entfernt und das Banner neu veröffentlicht. Die Liste schrumpfte von 1,5 MB auf 5 KB, die Seite reagierte auf dem Handy wieder normal.

Das allein wäre aber nur eine Frage der Zeit gewesen. Der nächste Scan hätte die Liste genauso wieder gefüllt. Bis zur dauerhaften Lösung galt deshalb: keine neuen Scans, kein automatischer Scan-Zeitplan.

5. Dauerhafte Lösung: das Login-Formular erst bei Bedarf laden

Naheliegend wäre gewesen, den Formularschutz beim Login einfach abzuschalten. Das hätte die Cookies beseitigt – und gleichzeitig den Login gegen eine bekannte Angriffsart geschwächt. Ein Performance-Problem mit einer Sicherheitslücke zu bezahlen, kam für uns nicht in Frage.

Stattdessen haben wir die Frage umgedreht: Warum muss das Formular auf jeder Seite stehen, wenn es nur ein Bruchteil der Besucher je öffnet?

• Im Footer steht jetzt nur noch ein leerer Platzhalter für das Login-Fenster.
• Erst wenn jemand auf „Anmelden” klickt, lädt die Seite das Formular per AJAX von einer eigenen, schlanken Adresse nach – einmal pro Seitenaufruf, und ausdrücklich ohne Zwischenspeicherung (no-store), damit jeder Besucher sein eigenes, frisches Formular bekommt.
• Der CSRF-Schutz bleibt unverändert. Das Einmal-Cookie entsteht weiterhin – aber nur noch für die Person, die tatsächlich gerade ein Login-Formular vor sich hat.
• Die Adresse des Formulars wird serverseitig erzeugt und behält so die jeweilige Sprach- und Länderversion (Deutschland, Schweiz, Frankreich) bei.

Ein Detail war dabei nicht offensichtlich: Wird das Formular über die eigene Nachlade-Adresse erzeugt, „erbt” das abgeschickte Formular diese Adresse. Nach dem Login hätte der Besucher dann nur das nackte Login-Fragment gesehen statt der Seite. Das Formular zeigt deshalb ausdrücklich wieder auf die normale Seite.

Ein angenehmer Nebeneffekt: Weil der Footer nun keinen besucherspezifischen Teil mehr enthält, können normale Seiten wieder vollständig zwischengespeichert werden.

6. Gründlich prüfen – auch dort, wo nichts kaputt sein sollte

Bevor die Änderung live ging, haben wir nachgeprüft, dass sie wirklich tut, was sie soll, und nichts anderes:

• 60 Seiten aus allen Sprachversionen automatisch abgerufen: Keine setzt mehr ein Einmal-Cookie – außer der Login-Seite selbst, wo es hingehört. Auch kein anderes Formular auf der Website fällt in dasselbe Muster.
• Den Login-Ablauf in Deutsch, Schweiz und Französisch im Browser durchgespielt: Fenster öffnen, falsches Passwort, richtiges Passwort, Abmelden.
• Die Gegenprobe zum Sicherheitsschutz: Ein Login-Versuch ohne gültiges Einmal-Merkmal wird weiterhin abgewiesen – genau wie vorher.
• Den Fehlerfall: Kann das Formular nicht geladen werden, erscheint ein verständlicher Hinweis statt eines endlos drehenden Ladesymbols, und ein erneuter Klick versucht es noch einmal.

Das Ergebnis

• Ordentliche Cookie-Liste: Auf der Live-Seite setzen die üblichen Seiten quer durch alle Sprachversionen null Einmal-Cookies. Vorher war es eines pro Seitenaufruf.
• Scans sind wieder erlaubt: Der Kunde kann CookieYes wieder regelmäßig scannen lassen, ohne dass die Liste explodiert. Der erste neue Scan lief direkt nach der Freigabe.
• Schnelle mobile Seite: Statt 1,5 MB lädt jeder Besucher wieder eine Liste von wenigen Kilobyte, das Menü reagiert normal.
• Login unverändert sicher: Der Schutz gegen gefälschte Anmeldungen ist vollständig erhalten.

Was Website-Betreiber daraus mitnehmen können

1. Consent-Tools regelmäßig auf Wildwuchs prüfen. Ein Blick in die Cookie-Liste des Banners genügt: Stehen dort Hunderte fast gleichnamige Einträge ohne Beschreibung, stimmt etwas nicht. Solche Listen sind nicht nur ein Performance-Risiko, sondern auch für Besucher nicht mehr nachvollziehbar – was dem eigentlichen Zweck einer Einwilligung zuwiderläuft. Warum eine saubere Einwilligung überhaupt nötig ist, haben wir in einem früheren Beitrag beschrieben.
2. Scan-Ergebnisse nicht blind veröffentlichen. Ein automatischer Scan ist ein Vorschlag, keine Wahrheit. Wer das Ergebnis vor der Veröffentlichung kurz durchsieht, erspart seinen Besuchern im Zweifel Megabytes.
3. Auf echten Handys messen. Ein schneller Büro-Rechner verzeiht vieles. Die meisten Besucher sind mit einem Mittelklasse-Smartphone unterwegs – und genau dort entscheidet sich, ob eine Seite als schnell oder als kaputt wahrgenommen wird.
4. Nur ausliefern, was gebraucht wird. Ein Formular, das fast niemand öffnet, muss nicht in jeder Seite stecken. Bei Bedarf nachladen spart nicht nur Daten, sondern verhindert auch unerwünschte Nebenwirkungen wie hier.

Ihre Website ist auf dem Handy langsamer, als sie sein sollte – und niemand weiß genau, warum? Wir finden die Ursache mit Messungen statt Vermutungen und beheben sie so, dass sie nicht wiederkommt. Sprechen Sie uns an – wir schauen uns Ihre Seite gerne an.