unload verschwindet: Analytics-Daten vollständig erfassen

Was Chrome bis zum 22. September abschaltet

Chrome deaktiviert unload nicht an einem Stichtag, sondern über eine Rampe. Die Umstellung auf alle Herkünfte läuft seit 2026 über acht Meilensteine und damit über rund 32 Wochen (Chrome for Developers). Sie beginnt mit einem Prozent der Seitenaufrufe in Meilenstein 146 am 10. März 2026 und steigt über 5, 10, 20, 40, 60 und 80 Prozent auf 100 Prozent in Meilenstein 154 am 22. September 2026 (Chrome for Developers). Meilenstein 153 fehlt in der veröffentlichten Tabelle. Der Zeitplan trägt den Stand vom 29. Juni 2026 und kann sich verschieben, solange das Team die Auswirkungen des Rollouts beobachtet.

Davor lief die Abschaltung rund ein Jahr als Feldversuch auf fremden Seiten. In Meilenstein 135 am 26. März 2025 betraf sie genau eine Adresse, in Meilenstein 142 am 22. Oktober 2025 waren es die fünfzig meistbesuchten Seiten (Chrome for Developers). Wichtiger als diese Zahlen ist die Zählweise: Der Rollout richtet sich nach Seitenaufrufen und nicht nach einzelnen Nutzern oder Seiten, damit einzelne Nutzer und Betreiber nicht stärker getroffen werden als andere (Chrome for Developers). Ihre Domain wird also nicht als Ganzes umgestellt. Ein wachsender Teil Ihrer Besucher sitzt in einem Chrome, der unload für diese Seite nicht mehr auslöst, während der Rest weiterhin Daten liefert.

Warum unload schon vorher unzuverlässig war

Die Abschaltung nimmt Ihnen weniger, als es zunächst aussieht, denn das Versprechen war schon vorher dünn. Auf Mobilgeräten läuft unload häufig gar nicht: Der Nutzer wechselt die App, das Betriebssystem schiebt den Tab in den Hintergrund und beendet ihn später ohne Rückfrage (Chrome for Developers). Das Dokument wird dann verworfen, statt entladen zu werden, und ein Ereignis für das Entladen entsteht folgerichtig nicht. Auf dem Desktop gilt unload in Chrome und Firefox als halbwegs verlässlich, kostet dort aber Ladezeit, weil es den Vor-/Zurück-Cache blockiert (Chrome for Developers).

Der Effekt fiel bisher kaum auf, weil er keine Fehlermeldung erzeugt. Ein nicht ausgelöstes Ereignis hinterlässt keinen Statuscode im Zugriffsprotokoll, keinen Eintrag in der Fehlerkonsole und keinen Ausschlag in der Überwachung. Es fehlt lediglich eine Zeile in der Datenbank. Eine fehlende Zeile aber sieht in jeder Auswertung genauso aus wie ein Besucher, der schneller gegangen ist, und wird deshalb als Verhalten gedeutet statt als Ausfall.

• Desktop mit klassischer Navigation: unload läuft in der Regel, sperrt dafür aber den Vor-/Zurück-Cache. Der letzte Datenpunkt wird mit einem langsameren Zurück-Schritt für jeden Besucher bezahlt.
• Mobile Browser: Tabs werden in den Hintergrund geschoben und später beendet. Der Abschlusswert entsteht dort häufig gar nicht erst, unabhängig vom Rollout.
• Rückkehr aus dem Cache: Eine wiederhergestellte Seite hat unload nicht durchlaufen und zählt in vielen Skripten auch nicht als neuer Aufruf. Die Sitzung läuft weiter, die Messung steht still.

Der zweite Schaden: der Vor-/Zurück-Cache

Der Vor-/Zurück-Cache hält eine verlassene Seite vollständig im Speicher, damit Zurück und Vorwärts ohne neuen Ladevorgang auskommen. Das ist kein Randfall: Nach Chrome-Nutzungsdaten ist eine von zehn Navigationen am Desktop und eine von fünf auf Mobilgeräten ein Zurück oder Vorwärts (web.dev). Ein registrierter unload-Handler macht die Seite für diesen Cache untauglich. Die Aufnahme unterbleibt, und jeder Zurück-Schritt kostet wieder einen vollständigen Aufbau samt Netzwerkverkehr.

Seit Chrome den Grund über die Angabe notRestoredReasons offenlegt, lässt sich das messen statt vermuten: Der Eintrag benennt den registrierten Handler, im Beispiel des Chrome-Teams als unload-listener. Auf diesen Wortlaut sollten Sie sich nicht festlegen, denn das Chrome-Team weist ausdrücklich darauf hin, dass Gründe umbenannt, ergänzt und entfernt werden; in Chrome 123 erscheint derselbe Grund als unload-handler (Chrome for Developers). Auf derselben Liste stehen häufig weitere Sperren, allen voran der Antwortkopf Cache-Control mit dem Wert no-store, den 23 Prozent der Seiten setzen, gegenüber 21 Prozent im Vorjahr (Web Almanac 2025). Wer den unload-Handler entfernt, den Kopf aber stehen lässt, gewinnt den Cache in der Regel nicht und hat nur die Hälfte der Arbeit erledigt.

Wie verbreitet das Problem tatsächlich ist

Die Verbreitung hängt stark davon ab, wo gezählt wird. Unter den tausend meistbesuchten Websites tragen 28 Prozent der Desktop-Seiten und 20 Prozent der mobilen Seiten einen unload-Handler; über den gesamten Bestand gerechnet sind es 11 Prozent am Desktop und 10 Prozent mobil (Web Almanac 2025). Der Anteil steigt also mit der Größe des Auftritts. Dort, wo Zählskripte, Zustimmungsschichten und Personalisierung übereinanderliegen, steckt der Handler typischerweise in einer Bibliothek, die niemand mehr bewusst eingebunden hat.

Die Telemetrie von Chrome misst dieselbe Sache aus einem anderen Blickwinkel und kommt auf deutlich kleinere Werte, weil sie Seitenaufrufe statt Seiten zählt: Am 4. September 2026 registrierten 0,089 Prozent der gemessenen Seitenaufrufe einen unload-Handler, ausgelöst wurde er bei 0,044 Prozent (Chrome Platform Status). Rund die Hälfte der registrierten Handler feuerte also gar nicht. Wie viel Ihres Verkehrs betroffen ist, entscheidet am Ende Ihre Browserverteilung: In Deutschland lag Chrome im August 2026 bei gut 61 Prozent (Statcounter).

Welche Kennzahlen zuerst kippen

Der Verlust trifft nicht alle Zahlen gleich. Betroffen ist alles, was erst am Ende einer Seitenansicht feststeht, und das sind ausgerechnet die Kennzahlen, mit denen Inhalt und Kaufstrecke bewertet werden. Ein Seitenaufruf wird beim Laden gezählt und bleibt deshalb vollständig. Eine Verweildauer dagegen entsteht erst beim Gehen und fällt ersatzlos weg, wenn der Auslöser ausbleibt.

Der Effekt ist einseitig: Es kommen keine falschen Daten hinzu, es fehlen echte. Deshalb wandern die Durchschnitte in eine Richtung, nämlich kürzere Verweildauer, flachere Scrolltiefe und weniger Abbrüche bei gleichbleibenden Käufen. Genau diese Mischung wird erfahrungsgemäß als Erfolg gelesen, obwohl sie ein Messausfall ist. Der Vergleich mit einer zweiten, unabhängig erhobenen Zahl trennt beides sauber: Bleibt die Zahl der Seitenaufrufe stabil, während die Zahl der gemeldeten Sitzungsenden fällt, liegt es am Auslöser und nicht am Publikum.

Der Ersatzpfad: auf den Sichtbarkeitswechsel messen

Der empfohlene Ersatz ist kein direkter Tausch, sondern ein anderer Zeitpunkt. Der Wechsel in den verborgenen Zustand ist das letzte Ereignis, das eine Seite verlässlich beobachten kann, und deshalb der geeignete Ort für das Sitzungsende (MDN Web Docs). pagehide ergänzt diesen Pfad für die Fälle, in denen das Dokument tatsächlich verlassen wird, und ist im Gegensatz zu unload mit dem Vor-/Zurück-Cache verträglich (MDN Web Docs). In Browsern ohne Unterstützung für den Sichtbarkeitswechsel ist es der Rückfallpfad.

Für das Senden selbst führt kein Weg an einer Schnittstelle vorbei, die den Auftrag überlebt. navigator.sendBeacon stellt die Daten in eine Warteschlange des Browsers, die auch nach dem Entladen abgearbeitet wird; die Gesamtgröße der eingereihten Daten ist dabei auf 64 KiB begrenzt (MDN Web Docs). Wer regelmäßig mehr senden möchte, hat kein Übertragungsproblem, sondern ein Datenmodellproblem: Am Sitzungsende gehören verdichtete Kennzahlen in die Sendung, nicht der komplette Verlauf.

// Ein Sitzungsende, zwei Auslöser, genau eine Sendung.
let sitzungsendeGesendet = false;

function sitzungsendeSenden() {
  if (sitzungsendeGesendet) return;
  sitzungsendeGesendet = true;

  const nutzlast = JSON.stringify({
    typ: 'session_end',
    sichtbar_ms: sichtbareZeitMs(),
    scrolltiefe: maxScrollProzent(),
    pfad: location.pathname
  });

  // Der Beacon überlebt das Entladen, Grenze 64 KiB Gesamtdaten.
  if (!navigator.sendBeacon('/a/p', nutzlast)) {
    fetch('/a/p', { method: 'POST', body: nutzlast, keepalive: true });
  }
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') sitzungsendeSenden();
});

// Ergänzung für das tatsächliche Verlassen des Dokuments.
window.addEventListener('pagehide', sitzungsendeSenden);

Zwei Details entscheiden über die Qualität dieser Umstellung. Erstens muss die Sendung genau einmal erfolgen, denn der verborgene Zustand kann in einer Sitzung mehrfach eintreten; ein Tabwechsel hin und zurück ist der Normalfall und kein Sitzungsende. Zweitens darf dieser Wechsel in der Auswertung nicht als Abschluss gelten, solange die Seite zurückkehrt, sonst zerfällt eine Sitzung in mehrere kurze. Ein Merker im Speicher und ein Zurücksetzen bei der Rückkehr lösen beides, kosten aber genau die Sorgfalt, die ein unload-Einzeiler früher gespart hat.

Wiederherstellungen aus dem Cache mitzählen

Sobald der unload-Handler weg ist, wird Ihre Seite für den Vor-/Zurück-Cache tauglich, und damit ändert sich eine zweite Zahl. Weil eine Wiederherstellung eine bestehende Seite zurückholt, statt einen neuen Ladevorgang anzustoßen, sinkt die Gesamtzahl der erfassten Seitenaufrufe, sobald der Cache greift (web.dev). Das ist keine Verschlechterung, sondern eine ehrlichere Zählung. Sie bricht allerdings jede Zeitreihe, die vorher stillschweigend aus Neuladevorgängen bestand.

window.addEventListener('pageshow', (ereignis) => {
  if (!ereignis.persisted) return;

  // Die Seite kam aus dem Vor-/Zurück-Cache zurück: neue Sitzungsphase.
  sitzungsendeGesendet = false;
  zaehlerZuruecksetzen();
  senden({ typ: 'pageview', navigation: 'back_forward_cache' });
});

// Beim ersten Aufbau den Navigationstyp mitschicken.
const eintrag = performance.getEntriesByType('navigation')[0];
senden({ typ: 'pageview', navigation: eintrag ? eintrag.type : 'navigate' });

Mit dem mitgesendeten Navigationstyp bleibt die Zeitreihe erklärbar: navigate, reload und back_forward lassen sich getrennt auswerten, und ein Rückgang der Neuladevorgänge bei gleichbleibender Summe ist dann sichtbar statt rätselhaft. Wer diesen Schritt auslässt, misst nach der Umstellung eine Delle im Verkehr, die es gar nicht gibt. Dasselbe Muster tritt bei vorausgeladenen Seiten über Speculation Rules auf, dort allerdings mit umgekehrtem Vorzeichen: zusätzliche Aufrufe, die niemand gesehen hat.

Prüfen, was Ihre Seite heute registriert

Vor jeder Umstellung steht ein Bestand. Die eigene Codebasis ist schnell durchsucht; die eigentliche Arbeit liegt bei eingebundenen Fremdskripten, die den Handler mitbringen, ohne dass er im Repository auftaucht. Drei Messungen reichen für ein belastbares Bild: eine Suche im Quelltext, eine Suche in den tatsächlich ausgelieferten Dateien und ein Blick auf die Antwortköpfe der Live-Adresse.

Wer die Umstellung selbst steuern will, statt auf den Rollout zu warten, setzt den Antwortkopf Permissions-Policy mit dem Wert unload=() und schaltet das Ereignis für die eigene Herkunft sofort ab (Chrome for Developers). Das ist der ehrlichere Weg, weil der Ausfall dann im Test auftritt und nicht anteilig im Bestand. Für Organisationen mit längerem Vorlauf gibt es zusätzlich eine Unternehmensrichtlinie, die das alte Verhalten vorübergehend erhält; sie verschiebt den Termin, sie ersetzt die Arbeit nicht. Solche Eingriffe gehören in ein Testfenster, das zum Zwei-Wochen-Takt der Chrome-Veröffentlichungen passt.

Fahrplan für die nächsten Wochen

1. Bestand aufnehmen: Eigene Skripte, Zählskripte und eingebundene Fremdskripte auf unload und onunload durchsuchen. Notieren, welcher Datenpunkt an welchem Auslöser hängt, und zwar je Kennzahl statt je Datei.
2. Zweitmessung aufsetzen: Eine Woche parallel messen, also Sitzungsenden über den Sichtbarkeitswechsel zusätzlich zum bestehenden Pfad. Erst die Differenz zeigt, wie viel heute schon fehlt.
3. Umstellen und entfernen: Den neuen Pfad scharfschalten und den unload-Handler löschen. Ein Handler, der nur noch für den Notfall stehen bleibt, sperrt weiterhin den Vor-/Zurück-Cache.
4. Navigationstyp erfassen: Wiederherstellungen aus dem Cache als eigene Kategorie zählen, damit der Rückgang der Neuladevorgänge erklärbar bleibt und nicht als Reichweitenverlust berichtet wird.
5. Bruch dokumentieren: Das Datum der Umstellung in der Auswertung markieren. Eine Zeitreihe ohne Markierung wird im nächsten Quartalsbericht als Trend gelesen, nicht als Methodenwechsel.
6. Fremdskripte nachhalten: Nach jedem Update eingebundener Skripte erneut suchen. Ein entfernter Handler kommt erfahrungsgemäß mit der nächsten Version einer Bibliothek zurück, nicht mit einer eigenen Zeile.

Ein Auslöser, der nur am Desktop und nur beim geordneten Verlassen feuert, liefert keine vollständige Messung. Er verteilt die Lücke bloß so gleichmäßig, dass sie über Jahre wie ein Messwert aussah.

— XICTRAQ

Sitzungsenden verlässlich erfassen

Die Umstellung ist überschaubar, solange sie geplant ist, und teuer, sobald sie im Quartalsbericht auffällt. Unsere cookielose Reichweitenmessung sendet Sitzungsenden über den Sichtbarkeitswechsel, zählt aus dem Vor-/Zurück-Cache zurückgeholte Seiten als eigenen Navigationstyp und kommt dabei ohne Zugriff auf Endgeräte-Speicher aus. Für eingebundene Fremdskripte zeigt die Überwachung der Skript-Integrität, wann sich eine Datei geändert hat, und damit den Moment, in dem ein entfernter Handler zurückkommen kann. Welche Auswertungen in welchem Umfang enthalten sind, steht in der Preisübersicht.

Zwei weitere Messstellen gehören in dieselbe Runde. Wer hinter einem Proxy oder einem Lastverteiler misst, braucht die richtige Besucher-IP aus X-Forwarded-For, sonst verschiebt sich die Zuordnung zusätzlich zum fehlenden Sitzungsende. Und wer Verhaltensdaten aufbewahrt, sollte wissen, was davon bei einer Auskunft nach Artikel 15 herauszugeben ist; diese Frage wird mit jedem zusätzlichen Ereignisfeld größer, das am Sitzungsende mitgesendet wird.