Ihr Analytics-Skript deaktiviert vermutlich den Back/Forward-Cache
Der Back/Forward-Cache macht Navigationen über den Zurück-Button nahezu sofortig, aber ein einziger unload-Listener deaktiviert ihn für die gesamte Seite. Tracking-Skripte sind meist die Ursache — und CrUX misst inzwischen den Schaden.
Die schnellste Navigation im Web ist die, bei der überhaupt nichts geladen wird. Der Back/Forward-Cache (bfcache) liefert genau das — und eine einzige Zeile im Skript Ihres Analytics-Anbieters kann ihn für jede Seite Ihrer Website abschalten.
bfcache ist eine Browser-Optimierung, die einen vollständigen In-Memory-Snapshot einer Seite — einschließlich des JavaScript-Heaps — vorhält, wenn der Nutzer wegnavigiert. Drücken Sie den Zurück-Button, stellt der Browser diesen Snapshot wieder her und setzt die Ausführung fort, was zu einem nahezu sofortigen Laden ohne Netzwerkanfrage führt. Navigationen über Zurück und Vorwärts machen schätzungsweise 10–20 % aller Navigationen aus, das ist also kein Randfall.
Ein einziger Listener disqualifiziert die ganze Seite
Die bfcache-Eignung ist konstruktionsbedingt fragil. Der Browser friert eine Seite nicht ein, die einen unload-Event-Listener registriert hat, denn unload impliziert, dass die Seite erwartet, abgebaut zu werden. Auf dem Desktop machen Chrome und Firefox jede Seite mit einem unload-Listener für den bfcache ungeeignet — keine Ausnahmen, keine Teilanrechnung.
Der Listener muss nicht von Ihnen stammen. Drittanbieter-Skripte, die unload aus Ihrer Seite heraus registrieren — oder sogar innerhalb eines Subframes — disqualifizieren das Dokument auf oberster Ebene. Lighthouse liefert ein eigenes no-unload-listeners-Audit aus, gerade weil der verursachende Code so oft Code ist, den der Website-Autor nie geschrieben hat.
beforeunload ist in modernen Browsern nicht mehr disqualifizierend, aber unzuverlässig und sollte weiterhin am besten vermieden werden, es sei denn, ein Nutzer hat ungespeicherte Änderungen.
Tracking-Skripte sind die üblichen Verdächtigen
Das unload-Event ist der klassische Ort, um einen letzten Beacon abzusetzen — eine Session zu flushen, ein „Seite geschlossen"-Event zu senden — daher greifen Verhaltens-Tracking- und Werbeskripte ständig darauf zurück.
Facebooks fbevents.js registriert einen unload-Handler und erscheint laut HTTP Archive auf etwa 9 % aller Webseiten. PayPals Tag injiziert ein iframe, das ein unload-Event hinzufügt und so den bfcache bei vielen Checkout-Flows blockiert. Subframe-Skripte wie hCaptcha haben dasselbe getan. Keines davon erfordert eine Änderung an Ihrem eigenen Code, um Sie Performance zu kosten — ein Anbieter, der ein Update ausrollt, genügt.
CrUX zeigt Ihnen jetzt die Rechnung
Früher war das in Felddaten unsichtbar. Seit dem Datensatz vom März 2024 liefert der Chrome User Experience Report (CrUX) eine Aufschlüsselung nach navigation_types — einschließlich des Anteils der Besuche, die aus dem Back/Forward-Cache bedient werden — sodass Sie sehen können, wie vielen echten Nutzern der sofortige Pfad entgeht.
Die Korrelation ist deutlich. CrUX-Analysen fanden einen starken statistischen Zusammenhang (ρ=0.87) zwischen einem hohen back_forward_cache-Anteil und instant_lcp_density — dem Anteil der Ladevorgänge mit einem LCP unter 200 ms. Nachdem Googles Update vom März 2026 das Ranking-Gewicht von LCP, INP und CLS erhöht hat, ist eine selbstverschuldete bfcache-Blockade ein messbarer Nachteil im 75. Perzentil, kein Rundungsfehler.
Erkennen und Beheben
Öffnen Sie die DevTools, gehen Sie zu Application → Back/forward cache und klicken Sie auf Run Test. Chrome listet jeden blockierenden Grund auf, einschließlich unload-Handler, die von Drittanbietern hinzugefügt wurden.
Um bfcache-Wiederherstellungen in Ihrem eigenen Code zu erkennen, verwenden Sie niemals unload. Verwenden Sie pageshow und prüfen Sie persisted:
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// restored from bfcache — no fresh page load fired
}
})
Um zu verhindern, dass Drittanbieter Sie disqualifizieren, setzen Sie einen Response-Header, der unload-Listener vollständig verbietet:
Permissions-Policy: unload=()
Das neutralisiert unload-Handler aus jedem Skript — Anbieter-Tags, Erweiterungen oder Ihrem eigenen Legacy-Code — sodass die Seite bfcache-fähig bleibt, unabhängig davon, was geladen wird.
Der Tracker, der ihn nie anfasst
Der strukturelle Fix besteht darin, eine Instrumentierung zu verwenden, die von vornherein keinen Grund hat, auf unload zu lauschen. Ein Privacy-First-Tracker erfasst einen Pageview mit einer einzigen keepalive-Anfrage und lässt die Anfrage die Seite von selbst überdauern — kein Teardown-Beacon, kein unload-Handler, nichts, was der Browser markieren könnte:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
Wenn ein Tracker auf das Backgrounding einer Seite reagieren muss, ist das korrekte Signal visibilitychange oder pagehide — beide werden ausgelöst, ohne die Seite bfcache-ungeeignet zu machen. Der Tracker von Monoid ist rund 2 KB groß, setzt keine Cookies und hängt sich für SPA-Routenwechsel an history.pushState statt an den Page-Lifecycle — er hat also keinen unload-Listener zu registrieren und nichts, was Ihren Back/Forward-Cache deaktivieren würde.
Überwachungs-Analytics belastet die Performance auf Weisen, die in einem Labor-Durchlauf nicht auftauchen. Eine bfcache-Blockade ist eine der leisesten: kein Fehler, kein langsames Rendering, nur ein Zurück-Button, der aus dem Netzwerk neu lädt, obwohl er aus dem Speicher hätte wiederherstellen sollen.
Comments
Loading comments…