Gestaltung für den Zurück/Vorwärts-Cache: Eignung, Wiederherstellung und Zustand

Wenn ein Benutzer auf „Zurück“ klickt, führen die meisten Anwendungen stillschweigend die Arbeiten erneut aus, die der Browser eigentlich überspringen könnte: Wiederherstellung des HTML, Ausführung aller Skripte, Neubau des DOMs und Neu laden der Daten. Der Back/Forward Cache (bfcache) existiert genau, um das zu vermeiden – doch im Alltag deaktivieren Programme ihn oft unbemerkt oder handhaben die zurückgeholte Seite falsch. Diese Anleitung erklärt, wie sich bfcache von herkömmlichem Caching unterscheidet, welche Gewohnheiten ihn blockieren, wie man eine wiederhergestellte Seite erkennen und darauf reagieren kann sowie wie man das Verhalten auf eigenen Bildschirmen überprüfen kann.

Warum der Historien-Navigationsmechanismus besondere Aufmerksamkeit verdient

Leistungsoptimierungen konzentrieren sich in der Regel auf den ersten Besuch. Teams komprimieren Bilder, teilen Dateien auf, laden Schriftarten im Voraus hoch, reduzieren die Initialisierungszeit, optimieren API-Aufrufe und achten auf den Zeitpunkt des größten inhaltlichen Darstellungsabschnitts. All das ist sinnvoll – doch es geht stillschweigend davon aus, dass jeder Seitenaufruf von einem leeren Tab und einer frisch eingegebenen URL ausgeht.

So durchsuchen die Menschen nicht das Internet. Ein Käufer öffnet ein Produkt, kehrt zu den Ergebnissen zurück, öffnet ein anderes Artikel und geht erneut dorthin. Ein Leser klickt auf einen Link in einem Artikel und kehrt zurück, um ihn zu beenden. Jemand besucht erneut ein halb ausgefülltes Formular. Die „Zurück“- und „Weiter“-Schaltflächen gehören zu den am häufigsten genutzten Steuerelementen in jedem Browser, und solche Vorgänge sind Routine und nicht außergewöhnlich.

Browser optimieren dieses Muster mit bfcache. Anstatt eine Seite abzurufen, sobald der Benutzer sie verlässt, kann der Browser ein Abbild des gesamten Dokuments im Speicher behalten. Wenn der Benutzer über die Sitzungshistorie zurückkehrt, kann der Browser dieses Abbild anzeigen, anstatt erneut eine Netzwerkanfrage zu senden, HTML zu parsen, Skripte auszuführen, Daten zu laden und das Dokument anzuzeigen. Jeder große Browser implementiert eine Variante davon, wobei sich die genauen Kriterien und internen Abläufe zwischen den Browsern unterscheiden.

Vom Standpunkt des Benutzers wirkt eine erfolgreiche Wiederherstellung fast sofortig. Der Scroll-Offset bleibt dort, wo er war, das DOM ist unverändert, die Formulare können weiterhin ihre Werte enthalten, und der JavaScript-Heap funktioniert ununterbrochen. Das Problem hat jedoch zwei Aspekte: Viele Teams überprüfen nie, ob ihre Seiten dafür geeignet sind, und Code, der davon ausgeht, dass jeder Besuch eine völlig neue Seite ist, kann falsch reagieren, wenn eine alte Seite wieder angezeigt wird.

Daher ist bfcache mehr als nur eine kostenlose Geschwindigkeitssteigerung. Es ermöglicht ein realistischeres Lebenszyklusmodell: Eine Seite kann inaktiv bleiben, während sie weiterhin „lebt“, und später wieder aktiv werden, ohne dass ihr Startcode ein zweites Mal ausgeführt wird.

Wie bfcache sich vom HTTP-Cache unterscheidet

Das gemeinsame Wort „Cache“ verursacht zunächst Verwirrung. Man neigt dazu anzunehmen, bfcache bedeute lediglich die Wiederverwendung von zuvor heruntergeladenem CSS, Scripts, Bildern oder API-Antworten. Das ist der HTTP-Cache, und er arbeitet in viel feinerer Granularität.

Der HTTP-Cache speichert einzelne Antworten. Das Zurückkehren auf eine Seite kann es dem Browser ermöglichen, einige Downloads zu überspringen, doch das Dokument selbst muss dennoch neu erstellt werden: HTML wird analysiert, Skripte ausgeführt, das Framework gestartet, ein DOM erstellt, Abonnements wiederhergestellt und neue Anfragen gesendet.

bfcache speichert die gesamte Seite, einschließlich ihres DOMs und ihres JavaScript-Heaps. Wenn der Benutzer wechselt, kann die Ausführung von Skripten pausiert werden; wenn er über den Historie-Button zurückkehrt, zeigt der Browser die gespeicherte Seite an und setzt ihre Ausführung fort. Deshalb ist ein bfcache-Hit sogar besser als eine gut abgestimmte Neu laden, die größtenteils aus dem HTTP-Cache stammt: Es bleibt einfach viel weniger Arbeit zu erledigen.

Dies verändert die Art und Weise, wie man über Navigation nachdenken sollte. Bei einer Wiederherstellung aus dem bfcache wird der übliche Startvorgang nicht unbedingt erneut ausgeführt. Eine variablen auf Modulebene kann weiterhin ihren ursprünglichen Wert beibehalten. Der DOM spiegelt weiterhin wider, was der Benutzer vor dem Verlassen getan hat. Timer und andere Laufzeitaktivitäten setzen dort an, wo sie aufgehört haben, anstatt von vorne erstellt zu werden.

Code, der davon ausgeht, dass ein Zurückkehren immer einen vollständigen Neuladen bedeutet, kann daher Aktualisierungen übersehen, veralteten Zustand auf dem Bildschirm beibehalten oder Duplikate erzeugen, wenn er versucht, etwas einzurichten, das bereits existiert. Das zu übernehmende Denkmuster ist einfach: Der Browser hat keine alte HTML-Antwort neu gerendert; er hat eine vorübergehend pausierte Seite wieder aktiviert.

Ein großer Vorteil, der fast keine neue Benutzeroberfläche erfordert

Die meisten Leistungsverbesserungen haben einen sichtbaren Preis: neu gestaltete Komponenten, neue Ladezustände, Serverrendering oder eine andere Strategie zur Datenerfassung. bfcache ist ungewöhnlich, weil der Browser diesen Mechanismus bereits implementiert hat.

Ihre Aufgabe besteht nicht darin, einen Cache zu erstellen. Vielmehr sollen Sie verhindern, dass der Browser den bereits vorhandenen Cache nicht nutzen kann, und sicherstellen, dass der Lebenszyklus Ihrer Seite mit einer Wiederherstellung kompatibel ist.

Deshalb zählt es zu den am effektivsten einsetzbaren Optimierungen für viele Teams. Eine aus dem Speicher wiederhergestellte Seite vermeidet wiederholte Übertragungen sowie den größten Teil der Verarbeitung, die bei einer normalen Navigation erforderlich ist. Der Vorteil ist am größten auf langsamen Geräten und Netzwerken, doch selbst schnelle Rechner zeigen einen deutlichen Unterschied zwischen dem Neubau einer Seite und deren einfacher Anzeige.

Außerdem wird nicht nur die Zeitpunktangabe, sondern auch das gesamte Erlebnis beibehalten. Stellen Sie sich jemanden vor, der mitten in einem langen Artikel ist, einen damit verbundenen Link öffnet und anschließend zurückkehrt. Eine herkömmliche Neu laden muss die Seite neu erstellen und versucht dann, die Scrollposition wiederherzustellen – oft nachdem sich das Layout bereits verändert hat. Eine Wiederherstellung mit bfcache bringt den Nutzer fast genau dorthin zurück, wo er war.

Produktkataloge machen diesen Punkt noch deutlicher. Jemand verwendet vier oder fünf Filter, um einen Katalog einzugrenzen, scrollt durch eine lange Liste, klickt auf ein bestimmtes Produkt und kehrt anschließend zurück. Wenn die Liste sofort im selben Zustand angezeigt wird, wirkt der Vorgang kontinuierlich. Wenn sie neu geladen, erneut abgerufen, die Filter entfernt oder auf die erste Zeile zurückgesetzt wird, wirkt die Website instabil – egal wie gut ihre Werte bei der ersten Ladenzeit aussehen.

Leistung bedeutet nicht nur, wie schnell die Nutzer zu einer Anwendung gelangen. Ebenso wichtig ist, wie viel wiederholte Arbeit das Produkt ihnen erspart, wenn sie zwischen den Bildschirmen wechseln.

Wie die Gewohnheit, Seiten zu löschen, den Vorteil heimlich beseitigt

Ein Grund, warum bfcache oft übersehen wird, ist, dass nichts sichtbar fehlschlägt, wenn eine Seite nicht für die Caching-Funktion geeignet ist. Der Browser führt einfach eine normale Navigation durch das Historie-Verzeichnis durch. Alles funktioniert weiterhin; die Nutzer verlieren lediglich die sofortige Wiederherstellung der Seite.

Das unload-Event ist der klassische Schuldige. Älterer Code verwendet es, um Analysedaten zu senden, Ressourcen freizugeben oder einem Server mitzuteilen, dass die Seite geschlossen wird – unter der Annahme, dass jede Navigation die Seite zerstört und somit eine letzte Gelegenheit zur Aufräumarbeit bietet.

Diese Theorie entspricht nicht mehr der Realität. Eine Seite kann statt gelöscht zu werden wegen bfcache gesperrt werden, und unload ist seit Langem unzuverlässig, insbesondere auf Mobilgeräten, wo es häufig überhaupt nicht ausgelöst wird. Das Verhalten unterscheidet sich je nach Browser, doch das Registrieren eines unload-Listeners kann dazu führen, dass eine Seite in einigen Browsern für bfcache ungeeignet wird. Die aktuellen Richtlinien der Plattform empfehlen dringend, unload zu vermeiden, und stattdessen Lebenszyklusereignisse zu verwenden, die dem modernen Modell entsprechen. Zum Zeitpunkt der Erstellung arbeitet Chrome ebenfalls daran, unload zu deprecieren; daher sollten Sie die aktuelle Browser-Dokumentation prüfen, um den neuesten Stand zu erfahren.

Der Zuhörer muss nicht einmal aus Ihrem eigenen Code stammen. Analytics-Snippets, Werbetags, Support-Chat-Widgets sowie ältere Abhängigkeiten registrieren manchmal einen intern. Er besteht die Code-Überprüfung, da er keine sichtbaren Auswirkungen hat, kann jedoch bei jedem Besuch dieser Seite eine Optimierung auf Browser-Ebene entfernen.

Die Ersetzung von unload bedeutet nicht einfach nur das Umbenennen des Events. Der richtige Ersatz hängt davon ab, wofür der Code tatsächlich dient:

• Analytics-Daten können mit navigator.sendBeacon() oder einer entsprechend konfigurierten fetch-Anfrage (zum Beispiel mit keepalive) gesendet werden, wenn die Sichtbarkeit der Seite auf „versteckt“ geändert wird.
• Warnungen vor ungespeicherten Formdaten können beforeunload verwenden, doch dieser Zuhörer sollte nur solange hinzugefügt werden, solange es ungespeicherte Änderungen gibt, und nach dem Speichern wieder entfernt werden – anstatt ihn für die gesamte Lebensdauer der Seite zu aktivieren.

Ressourcen, die mit der aktiven Seite verbunden sind, können durch Lebenszyklusereignisse, die mit bfcache kompatibel sind und im Folgenden erläutert werden, pausiert und wieder aufgenommen werden.

Die wichtigere Erkenntnis: Das Verlassen der Seite bedeutet nicht das Ende ihres Lebenszyklus. Code, der auf dieser Annahme beruht, ist letztendlich weniger zuverlässig und langsamer, als es notwendig wäre.

Aufspüren der Wiederherstellung mit pageshow und pagehide

Zwei Ereignisse umgeben die versteckte Periode. pagehide tritt auf, wenn eine Navigation das Dokument außer Sicht bringt, und pageshow tritt auf, wenn eine Navigation das Dokument erneut aktuell macht – was auch ein Zurücksetzen aus dem bfcache beinhaltet. Beide Ereignisse weisen eine persisted-Eigenschaft auf. Bei pageshow ist persisted auf true, wenn die Seite aus dem bfcache zurückgeholt wurde; bei pagehide gibt sie an, dass der Browser versucht, die Seite beizubehalten. Im Gegensatz zu unload ist pagehide so konzipiert, dass er mit bfcache koexistieren kann.

Der untenstehende Auszug zeigt die grundlegende Struktur. Der pageshow-Handler gibt bei einer normalen Ladeung bereits frühzeitig zurück, sodass die Aktualisierungslogik nur dann ausgeführt wird, wenn eine gespeicherte Seite wieder geladen wird. Der pagehide-Handler pausiert die Echtzeitverbindungen, sobald die Seite versteckt wird – unabhängig davon, ob sie in der Zwischenzeit im Cache gespeichert wurde. Die Hilfsfunktionen dienen als Platzhalter für Ihre eigene Anwendungslogik.

window.addEventListener("pageshow", (event) => {
  if (!event.persisted) {
    return;
  }

refreshSessionState();
  refreshTimeSensitiveData();
});

window.addEventListener("pagehide", () => {
  pauseRealtimeConnections();
});

Achten Sie darauf, was hier nicht geschieht: Es werden nicht alle Daten erneut abgerufen. Das Wiederlaufen der gesamten Datenschicht bei jeder Wiederherstellung würde den größten Teil des Vorteils zunichtemachen. Ziel ist es, nur die Informationen zu aktualisieren, deren Richtigkeit während des Aussetzens der Seite tatsächlich ändern kann.

Was das bedeutet, hängt von der Seite ab:

• Eine Nachrichtenseite möchte möglicherweise nach aktuellen Schlagzeilen suchen.
• Ein Benutzerkonto-Display muss möglicherweise überprüfen, ob die Sitzung nicht in einem anderen Tab beendet wurde.

Ein Bestellschritt kann eine erneute Überprüfung von Lagerbeständen und Preisen erfordern.

Eine Referenzseite mit statischen Dokumenten kann in der Regel die Wiederherstellungslogik ganz überspringen.

Die eigentliche Verbesserung besteht darin, dass die Anwendung nun zwischen einem neuen Laden und einer Wiederherstellung unterscheiden kann. Ohne diese Unterscheidung müssen Teams in der Regel zwischen zwei schlechten Optionen wählen: Entweder nie aktualisieren und das Risiko veralteter Inhalte in Kauf nehmen oder die vollständige Initialisierung erneut durchführen und damit den größten Teil der Geschwindigkeit opfern. Eine Anwendung, die bfcache versteht, behandelt die Wiederherstellung als eine eigene Phase des Lebenszyklus, behält das noch Gültige bei und aktualisiert nur das, dem nicht mehr vertraut werden kann.

Wenn der wiederhergestellte Zustand zu einem Korrektheitsproblem wird

Sofortige Wiederherstellung klingt zunächst völlig positiv – bis die gespeicherte Seite etwas enthält, das eigentlich nicht mehr angezeigt werden sollte.

Betrachten Sie einen Benutzer, der ein Kontrollpanel öffnet, zu einer anderen Seite wechselt, sich aus einem zweiten Tab ausloggt und schließlich auf „Zurück“ klickt. Das wiederhergestellte Bild kann immer noch Details aus der früheren Sitzung anzeigen. Der Browser verstößt damit gegen keine Sicherheitsregel, indem er sich an eine Seite innerhalb derselben Suchsession erinnert, doch Ihre Anwendung muss prüfen, ob die Sitzung noch gültig ist, bevor weitere Interaktionen erlaubt werden.

Auch zeitkritische Daten stellen das gleiche Problem dar. Ein Ticket könnte in einem anderen Tab gekauft worden sein, ein Datensatz von einem Kollegen bearbeitet oder ein Verfügbarkeitszeitraum bereits abgelaufen sein. Eine wiederhergestellte Seite kann ein perfekt getreues Abbild der Vergangenheit sein und dennoch die falsche Quelle für aktuelle Informationen darstellen.

Eine gängige Reaktion ist es, das Caching vollständig deaktivieren. Das ist in der Regel zu drastisch. Die Seite kann ihren DOM- und Interaktionszustand beibehalten, während nur die Daten aktualisiert werden, die aktuell sein müssen, und pageshow ist der geeignete Zeitpunkt für diese Abstimmung. Offizielle Richtlinien besagen klar, dass Seiten mit häufig wechselndem Inhalt nach dem Neuladen frische Daten laden können, anstatt bfcache ganz zu deaktivieren.

Sicherheitskritische Seiten benötigen weiterhin gezielte Caching- und Sitzungspolitiken, und die Art und Weise, wie Browser Header wie Cache-Control: no-store behandeln, ändert sich ständig. Chrome erlaubt beispielsweise unter bestimmten Bedingungen, dass bestimmte no-store-Seiten in bfcache aufgenommen werden. Vermeiden Sie es, von einer einzigen vereinfachten Annahme darüber auszugehen, wie jeder Browser diesen Header handhabt, und prüfen Sie vor der Nutzung die aktuelle Browser-Dokumentation.

Der sicherere Ansatz ist es, explizit zu entscheiden:

• welcher Zustand sicher unverändert beibehalten werden kann;
• welcher Zustand nach einer Wiederherstellung erneut überprüft werden muss;
• welche Benutzeraktionen immer eine erneute Autorisierungsprüfung auf dem Server erfordern, unabhängig davon, was die Benutzeroberfläche derzeit anzeigt.

Die letzte Kategorie ist am wichtigsten. Der Client kann seine Ansicht aktualisieren, doch der Server darf niemals einer wiederhergestellten Seite trauen, um zu beweisen, dass ein Benutzer weiterhin eingeloggt ist.

Pause von langlebigen Verbindungen während der Pause

Offene Verbindungen wie WebSockets, IndexedDB-Handles, gemeinsame Sperrmechanismen sowie laufende Anfragen erschweren die Nutzung von bfcache, da der Browser die Seite einfrieren muss, während andere Tabellen und Dokumente weiterhin laufen. Eine eingefrorene Seite, die einen gemeinsamen Sperrmechanismus oder eine offene Datenbankverbindung besitzt, kann den Betrieb aktiver Seiten behindern. Die Kriterien für die Aufnahme in den Cache unterscheiden sich je nach Browser, und in einigen Fällen reicht bereits eine offene oder aktive Verbindung aus, um eine Seite außerhalb des Caches zu halten. Das empfohlene Vorgehen besteht darin, solche Ressourcen zu freigeben oder vorübergehend auszusetzen, sobald die Seite versteckt wird, und sie anschließend vorsichtig wieder herzustellen, sobald sie sichtbar wird.

Das bedeutet nicht, dass jeder Event-Listener oder Observer deaktiviert werden muss. Zustände, die vollständig innerhalb der Seite liegen, wie beispielsweise DOM-Listener, können in der Regel unverändert bleiben. Konzentrieren Sie sich stattdessen auf alles, was über das eingefrorene Dokument hinaus zu externen Systemen reicht oder das nicht als aktiv erscheinen sollte, solange niemand die Seite anblickt.

Ein Echtzeit-Dashboard könnte beispielsweise seinen WebSocket bei pagehide schließen und einen neuen öffnen, wenn die Seite wiederhergestellt wird. Die Implementierung muss vor Doppelverbindungen schützen, da sowohl der normale Startvorgang als auch der Wiederherstellungshandler versuchen könnten, eine Verbindung herzustellen; eine einzige connect()-Funktion, die überprüft, ob bereits eine Verbindung besteht, ist eine einfache Möglichkeit, dies idempotent zu gestalten. Ein IndexedDB-Wrapper könnte seine Datenbankverbindung vor der Pause schließen und sie beim nächsten Bedarf nachträglich wieder öffnen.

Diese Disziplin bringt Vorteile jenseits von bfcache. Sie zwingt das Team dazu, festzulegen, wer für jede externe Ressource verantwortlich ist, wann sie vorhanden sein sollte und was passiert, wenn das Dokument inaktiv wird. Solche Vereinbarungen sind genauso wertvoll für Hintergrundtabellen, Mobilgeräte, die Seiten einfrieren, sowie unterbrochene Sitzungen.

Einfachseitige Anwendungen profitieren weiterhin

bfcache arbeitet mit Navigationen zwischen Dokumenten, die vom Browser verwaltet werden. Routenänderungen, die in JavaScript abgewickelt werden und bei denen kein neues Dokument geladen wird, fallen außerhalb seines Anwendungsbereichs. Der Wechsel von /products zu /products/42 über einen clientseitigen Router wird weiterhin von der SPA und ihrem Framework eigenständig gesteuert.

Trotzdem haben SPAs viel zu gewinnen. Nutzer wechseln regelmäßig von einer SPA zu einer separaten Seite, einer Website Dritter, einem Anmeldedienst oder einer völlig anderen App und kehren später zurück. In diesem Fall kann der Browser die gesamte Anwendung wieder laden, anstatt erneut Bundle herunterzuladen, alle Komponenten neu darzustellen und die Einrichtung erneut durchzuführen. Offizielle Leitfäden weisen ausdrücklich auf diesen Vorteil hin und betonen zugleich, dass Änderungen der internen Routen außerhalb der Kontrolle von bfcache liegen.

Diese Rückkehrvorgänge können Annahmen auf Framework-Ebene offenlegen:

• Es wird erwartet, dass die Initialisierung der Wurzelkomponente jedes Mal ausgeführt wird, wenn das Dokument sichtbar wird;
• eine Datenschicht, die davon ausgeht, dass ihre Caches stets leer starten;
• eine Echtzeitverbindung, die neu erstellt wird, während die alte Verbindung gleichzeitig wiederhergestellt wird;
• eine Komponente, die Zahlen anzeigt, die zum Zeitpunkt des Verlassens korrekt waren und nun möglicherweise veraltet sind.

Kein Framework abstrahiert den eigenen Lebenszyklus des Browsers. Egal, ob Sie React, Vue, Angular oder Svelte verwenden – der Code läuft weiterhin innerhalb eines Dokuments, das der Browser speichern und wiederherstellen kann. Ein Framework ist gut darin, den Zustand zu organisieren, hat aber keine Möglichkeit, für Sie festzustellen, welche Geschäftsdaten nach einer Pause noch gültig sind. In React beispielsweise werden Komponenten bei einer Wiederherstellung aus dem bfcache nicht erneut geladen, sodass Effekte, die beim Laden ausgeführt wurden, nicht noch einmal ablaufen; ein pageshow-Listener ist die Methode, mit der die Anwendung erkennt, dass Zeit vergangen ist.

Viele Frontend-Entwickler kennen das Laden- und Entladenverhalten ihres Frameworks weitaus besser als den Dokumentenlebenszyklus des Browsers. bfcache zeigt, dass Laden und Entladen nur eine Schicht dessen beschreiben, was tatsächlich mit einer Seite geschieht.

bfcache in wenigen Minuten testen

bfcache wird teilweise ignoriert, weil es schwierig ist zu erkennen, ob es funktioniert. Der Zurückgekehrte Weg mag bereits schnell erscheinen, und das Netzwerk-Panel ist nicht besonders hilfreich, da eine wiederhergestellte Seite die übliche Anfrageabfolge vollständig überspringt.

Chrome DevTools bietet einen speziell dafür entwickelten bfcache-Check, der unter dem Anwendungs-Panel zu finden ist. Wenn man ihn ausführt, navigiert Chrome weg und zurück, wobei berichtet wird, ob die Seite wiederhergestellt wurde. Wenn die Seite nicht geeignet ist, listet DevTools handlungsbedürftige Gründe auf und zeigt an, welche Frames dafür verantwortlich sind.

Machen Sie diesen Check zu einem Bestandteil der regelmäßigen Leistungsüberprüfungen für wichtige Seiten – insbesondere Suchergebnisse, Artikel, Produktlisten, Dashboards sowie alle Bildschirme, die Nutzer häufig wieder aufsuchen. Führen Sie ihn auch mit aktivierten Drittanbieter-Skripten durch, da die Eignung oft durch Code außerhalb Ihres eigenen Pakets blockiert wird.

Für Felddaten kann die über die Performance API bereitgestellte Information notRestoredReasons (im Eintrag zu den Navigationstimen) erklären, warum tatsächliche Historien-Navigierungen nicht wiederhergestellt wurden. Die Unterstützung ist nicht universell, daher sollte man sie eher als schrittweise Implementierung betrachten und nicht als etwas, auf das Ihr Code in allen Browsern angewiesen ist. Dennoch ist sie wertvoll, denn kein lokaler Test kann jede Browsererweiterung, jeden Drittanbieter-iframe, jede offene Verbindung, jeden Header oder jede Browserkonfiguration nachbilden, die Ihre Nutzer mitbringen. Eine leichtgewichtige Alternative besteht darin, event.persisted von pageshow in Ihren Analytics-Systemen zu erfassen, um Ihre tatsächliche Trefferquote zu messen.

Erwarten Sie nicht, dass jede Historien-Navigation im Cache landet. Browser löschen Snapshots, um den Speicher zu verwalten, und einige Blockierungen liegen außerhalb der Kontrolle der Seite. Das realistische Ziel ist es, die vermeidbaren Blockierungen zu beseitigen und im Falle eines Wiederherstellungsversuchs diese korrekt zu handhaben.

Zusammenfassung

bfcache fällt gerade deshalb leicht übersehen, weil nichts in Ihrer Codebasis es aktiviert. Es gibt weder ein Paket noch eine Komponente oder eine Konfigurationsdatei, die es als Teil der Architektur erscheinen lassen; der Browser versucht einfach, den Nutzern eine bessere Erfahrung zu bieten. Diese Unsichtbarkeit hat zwei Seiten: Wenn es funktioniert, erhalten die Nutzer eine nahezu sofortige Historien-Navigation mit fast keinem Codeaufwand; wenn es blockiert wird, verlangsamt sich die Seite ohne jeglichen Fehler; und wenn die Wiederherstellung falsch gehandhabt wird, taucht der veraltete Zustand wieder auf, weil die Anwendung davon ausging, dass ein Zurückkehren immer einen Neuladen bedeutet.

Eine praktische Checkliste für Ihre am häufigsten besuchten Seiten:

• Entfernen Sie unload-Listener, einschließlich solcher, die von Drittanbieter-Skripten hinzugefügt wurden, und verlagern Sie deren Funktionalität auf pagehide, visibilitychange oder sendBeacon().
• Fügen Sie beforeunload nur dann hinzu, wenn ungespeicherte Änderungen vorhanden sind.
• Schließen oder pausieren Sie externe Verbindungen in pagehide und verbinden Sie sich bei Wiederherstellung idempotent neu.
• Verwenden Sie pageshow zusammen mit event.persisted, um nur jene Daten aufzuladen, die veralten können, und führen Sie Autorisierungsprüfungen auf dem Server durch.
• Führen Sie den Cache-Test in den DevTools durch und verfolgen Sie die tatsächlichen Wiederherstellungsraten, sofern die APIs dies zulassen.

Der zugrundeliegende Wandel betrifft die Art und Weise, wie man sich eine Seite vorstellt. Anstatt einer einzigen geraden Linie von der Erstellung bis zur Zerstörung kann ihr Lebenszyklus auch Setup, Verstecken, Einfrieren, Wiederherstellen, Abgleichen und Fortsetzen umfassen. Teams investieren viel Mühe darauf, die Rekonstruktion von Seiten zu beschleunigen, während der Browser oft bereit ist, diese Rekonstruktion ganz wegzulassen und den Nutzern die Seite zurückzugeben, die sie bereits hatten.