🤜🏾 🗂️ 🥔 BFCache oder Hin und zurück. Yandex-Bericht 🌋 👍🏾 👫

Die Benutzer verwenden die Schaltfläche "Zurück" zur vorherigen Seite im Browser sehr häufig - möglicherweise häufiger als Sie denken. Und wenn ja, warum dann sofort die Seite aus dem Speicher des Browsers werfen und nach einer Sekunde Zeit und Verkehr damit verbringen, sie wieder zu öffnen? Damit der Benutzer schnell zurückkehren kann, wurde die BFCache-Technologie erfunden, die bei der Entwicklung von Schnittstellen unbedingt zu beachten ist. Victor KhomyakovVictor-Homyakov fand "Round-Trip-Caching" heraus und erstellte eine BFCache-Kompatibilitätstabelle mit verschiedenen APIs.

- Hallo, ich heiße Victor. Ich arbeite als Teil eines ziemlich großen Teams, das sich mit der Suchseite befasst.

Zumindest haben Sie bereits dieselbe oder eine ähnliche Seite bei Google gesehen. Insbesondere beschäftige ich mich mit dem Problem der Download-Geschwindigkeit dieser Seite - damit sie so schnell wie möglich auf dem Server gerendert und so schnell wie möglich heruntergeladen und den Clients angezeigt wird. Warum ist es wichtig? Je weniger Kunden auf das Laden Ihrer Seite warten, desto unwahrscheinlicher ist es, dass er nicht wartet und Sie verlässt. Und je wahrscheinlicher es ist, dass der Kunde erfolgreich zu etwas anderem konvertiert, desto höher ist die Netto-Promotion-Punktzahl. Das heißt, der Kunde wird jedem, den er kennt, gerne mitteilen, dass dies eine großartige coole Seite ist - sie wird sehr schnell geladen und ist sehr bequem zu verwenden. Und letztendlich, je mehr Geld Sie verdienen können. Oder Ihre Firma, dann gibt es Ihnen einen Preis.

Ich werde einige Beispiele bekannter Unternehmen nennen. Google hat ein Experiment durchgeführt. Sie haben absichtlich eine Verzögerung in die Suchseite eingebettet und gemessen, wie sich dies auf die Leistung auswirkt. Es stellte sich heraus, dass durchschnittlich ein halbes Prozent weniger Suchanfragen pro Benutzer durchgeführt wurden. Was ist ein halbes Prozent? Berechnen Sie: Ein halbes Prozent von Hunderten Millionen Google-Nutzern ist eine ziemlich große Zahl.

Bing machte das gleiche Experiment. Sie glaubten Google nicht, sie beschlossen, es noch einmal zu überprüfen. Sie erzielten ähnliche Ergebnisse: Deutlich weniger Umsatz pro Benutzer, wenn die Seite langsamer wird. Warum langsamer werden? Weil es einfacher ist, die Seite um die genaue Anzahl von Millisekunden zu verlangsamen, damit sie in der Produktion problemlos reproduziert werden kann, als sie um denselben Betrag zu beschleunigen.

Beispiel von AliExpress. Sie haben ihre Website um 36% beschleunigt und deutlich mehr Bestellungen von Nutzern erhalten. Bestellungen sind direktes Geld. Im Allgemeinen ist bereits allen klar, dass Geschwindigkeit sehr wichtig ist und durch eine bestimmte Anzahl von Metriken das verdiente Geld beeinflusst.

Und noch ein Faktor. Wir haben bereits heute über Bildoptimierung gesprochen. Indem Sie Ihren Datenverkehr optimieren und die Anzahl der Downloads reduzieren, zahlen Sie Ihren Hostern weniger Geld für ausgehenden Datenverkehr. Dies ist auch das Geld, das in Ihrer Tasche bleibt. Was ist, wenn ich Ihnen plötzlich einen Rabatt von 10% auf den Datenverkehr von einem Host ohne Einschränkungen und Bedingungen anbiete? Und wenn ich sicherstellen möchte, dass der Anteil Ihrer Seiten - zum Beispiel zehn Prozent - fast sofort vom Benutzer geladen wird? Niemand wird sich weigern.

Die Technologie, über die ich heute sprechen werde, ist eine der möglichen Lösungen, die nur wenige Einschränkungen für den Stack auferlegt, mit dem Sie arbeiten, für welche Technologien, aber gleichzeitig verspricht, Ihnen so bedeutende Gewinne zu bringen.

Zunächst sammelt Google Statistiken darüber, wie diese Browser in ihren Browsern verwendet werden. Und sie haben eine solche Zahl veröffentlicht: Es stellt sich heraus, dass im Durchschnitt aller Seiteneröffnungen und der gesamten Navigation in mobilem Chrome etwa 19% eine Bewegung in der Geschichte hin und her sind. Überlegen Sie, was das bedeutet? Wenn Sie runden, stellt sich heraus, dass 20% der Navigation auf die Seite verschoben werden, auf der sich der Benutzer gerade befunden hat.

Für uns wie für die Autoren der Seiten bedeutet dies: Selbst wenn der Benutzer sie verlässt, besteht eine beträchtliche Chance, dass er bald zurückkehrt. Einerseits kann dies das Problem von Mobiltelefonen sein: Alles ist klein, es ist leicht, einen Finger zu übersehen, auf den Link zu klicken und die Seite zu verlassen und dann zu sagen: "Oh, verdammt! Ich möchte zurückkehren ". Auf Desktops ist die Situation jedoch ungefähr gleich: Dort ist die Anzahl geringer, aber es gibt immer noch einen signifikanten Prozentsatz der Renditen.

Was machen wir gerade? Wir verbringen ineffektiv mit Benutzerzeit und Datenverkehr. Das heißt, wir beginnen, dieselbe Seite neu zu laden, sie zu analysieren, das DOM neu zu erstellen, alles auf dem Bildschirm neu zu zeichnen, JavaScript zu laden und auszuführen.

Der Browser ist eine ziemlich mächtige Sache. Er versucht, wo immer möglich Caches zu verwenden. Und die meisten Ressourcen befinden sich möglicherweise in seinem Cache. Er wird nicht aus dem Netzwerk auf sie warten, sondern sie direkt aus dem Cache abholen. In der V8-Engine wird beispielsweise auch das Ergebnis des Parsens von JavaScript zwischengespeichert. Das heißt, der Browser lädt JS nicht neu und analysiert es nicht. In den meisten Fällen dauert es, bis es sofort ausgeführt wird. Das Wiederherstellen des DOM, das Neuladen nicht zwischengespeicherter Ressourcen und das Ausführen von JS nimmt jedoch viel Zeit in Anspruch.

Die Lösung bietet sich an. Was machen wir? Wenn der Benutzer unsere Seite verlässt, bereinigen wir sie nicht sofort. Wir speichern einfach seinen Status und verbergen ihn visuell vor dem Benutzer, damit er unter der Haube dem Browser zur Verfügung steht.

Was tun wir, wenn der Benutzer sich für eine Rückkehr entscheidet? Zeigen Sie ihm einfach dieselbe gespeicherte Seite. Es kann fast sofort angezeigt werden.

Diese Technologie wird von den Wörtern "hin und her" als Vorwärts- / Rückwärts-Cache bezeichnet. Abkürzung für bfcache.

Hier ist ein Beispiel dafür, wie sich derselbe Browser, dieselbe Assembly, verhält, wenn bfcache ein- und ausgeschaltet ist. Das Öffnen der ersten Seite ist dort und dort gleich langsam. Wenn wir uns jedoch weiter durch die Geschichte bewegen, ist links eine Pause erkennbar, nicht rechts. Links nimmt die übliche Bewegung durch die Geschichte spürbare Zeit in Anspruch. Rechts geht alles sehr, sehr schnell.

GIF anzeigen

Ein ähnliches Beispiel aus unserer Suche. Links ist die übliche Safari unter macOS mit deaktiviertem bfcache, rechts die gleiche Safari mit den Standardeinstellungen und aktiviertem bfcache. Dies ist ein ziemlich häufiger Fall: Eine Person kommt auf die Suche, weiß möglicherweise nicht genau, wonach sie sucht, und fragt möglicherweise nach mehreren Abfrageoptionen. Ich habe die erste Anfrage gestellt - etwas stimmt nicht. Die zweite Anfrage scheint besser zu sein. Drittens - nein, schlimmer noch, gehen Sie zurück zur vorherigen Anfrage. Und in diesem Moment wäre es sehr gut, ihn nicht warten zu lassen. Er hat gerade diese vorherige Anfrage gesehen, zeige sie sofort.

Oder die zweite Option, wenn Sie eine Paginierung und mehrere Seiten zu diesem Thema haben. Mann blättert durch das Thema. Ich ging zur zweiten, dritten, vierten Seite und schaute - nein, da stimmt etwas nicht, ich komme wieder. Und wir können ihm wieder die vorherigen Seiten fast sofort zeigen.

Ein wichtiges Thema ist die Sicherheit. Während sich die Seite, auf der sich der Benutzer nicht in einem verborgenen Zustand befand, auf verschiedene APIs zugreifen konnte, mit denen Sie den Hardwarestatus Ihres Telefons oder Computers lesen können. Hier ist eine kurze Liste der Dinge, die Ihnen sofort in den Sinn kamen: Geolokalisierung, Ändern der Position Ihres Geräts im Weltraum, Zugriff auf die Kamera und Ton vom Mikrofon.

Wenn die Seite dann angezeigt wird, ist es wichtig, dass sie nicht auf alle Ereignisse zugreifen kann, die während der Zeit aufgetreten sind, als sie ausgeblendet wurde. Andernfalls wird ein zusätzlicher Kanal zum Ausspionieren von Benutzern geöffnet. Es ist wichtig, dass sie während dieser ganzen Zeit keine Historie Ihrer Bewegungen und der Aufzeichnung von Mikrofon und Kamera erhält. Browserentwickler sollten dies auch nicht vergessen.

API- und Browser-Unterstützung

Näher am Thema. Angenommen, ich habe Sie bereits überzeugt, Sie sind: "Ja, ein gutes Thema, wir müssen damit arbeiten." Welche APIs stehen uns zur Verfügung, womit können wir arbeiten, wenn wir uns bereit erklärt haben, bfcache zu berücksichtigen, und wie wird dies von Browsern unterstützt?

Wo existiert bfcache bereits, wo kann ich es sehen?

- Es ist seit langem in den Browsern Firefox, Safari (und macOS und iOS) sowie in Internet Explorer 11 (!) Implementiert. Normalerweise schimpfen wir mit Microsoft-Entwicklern, aber hier haben sie es nur versucht.

- Es ist im Browser UC Browser 11/12, Version für Android, implementiert.

- Plötzlich ist er nicht mehr in Chrome. Und in Chromium befindet sich diese Funktion in der Entwicklung.

Wenn sie dies in Chromium tun, erhalten fast alle diese Browser (und dies ist keine vollständige Liste) früher oder später diese Funktionalität - kostenlos, ohne SMS und Registrierung.

Gibt es irgendeine Art von API? Ich möchte bfcache verwalten, ich möchte es direkt über JavaScript ein- und ausschalten, um herauszufinden, ob es eine Seite in bfcache gibt oder nicht. Wie wäre es mit einer solchen API? Es gibt keine solche API. Und das wurde bewusst gemacht: Die Seite sollte bfcache nicht für alle und für sich selbst ein- oder ausschalten wollen. Oder finden Sie heraus, ob sich jemand in diesem Bfcache befindet oder nicht. Dies ist alles aus Sicherheitsgründen.

^{_{Link von der Folie}}

Aber was haben wir? Arten der Navigation. Es gibt eine Art Link - Link Prerender, wenn wir eine Seite im Voraus rendern möchten. Für ihn gibt es eine spezielle Art der Navigation: Diese Seite wird mit dem NavigationType „Prerender“ geöffnet. Wenn wir die Seite nur in einem Browser öffnen, wird "navigiert". Wenn wir auf die Schaltfläche "Aktualisieren" klicken, wird "neu laden".

Wir interessieren uns hier für den Navigationstyp "back_forward". Dies zeigt deutlich, dass sich der Benutzer durch die Geschichte hin und her bewegt hat. Dies ist genau die Art der Navigation, mit der unser bfcache arbeiten kann.

Eine weitere API sind die Pageshide-Ereignisse von pageshow. Sie existierten bereits in Browsern. Dementsprechend wird die Seitenshow ausgelöst, wenn Ihre Seite dem Benutzer im Browser angezeigt wird. Die Seitenausblendung wird ausgelöst, wenn die Seite aus irgendeinem Grund ausgeblendet wird. Und sie wurden durch das anhaltende Feld ergänzt. Wenn sich die Seite versteckt und gleichzeitig in bfcache platziert wird, ist das persistierte Feld wahr. Wenn die Seite beim Aufrufen aus bfcache angezeigt wird, ist das persistierte Feld wieder wahr.

Wenn der Browser die Seite nicht zwischenspeichert, bleibt pagehide dementsprechend false. Und wenn der Browser die Seite während des normalen Ladens anzeigt oder bfcache nicht verwendet, bleibt pageshow auch false.

^{_{Link von der Folie}}

Ereignisunterstützung ist in fast allen Browsern verfügbar, auch in solchen, die bfcache noch nicht unterstützen.

^{_{Link von der Folie}}

Gleiches gilt für das persistierte Feld. Es ist bereits in Chrome vorhanden und Chrome unterstützt bfcache immer noch nicht. Das heißt, dieses Feld wird immer darin sein, aber im Moment wird es falsch sein.

Als ich auf dieses Phänomen stieß, musste ich es studieren, auf alle Seiten tippen und beobachten, wie es funktioniert. Ich wollte sofort auf meiner Seite sehen, wann ich den Wert des persistierten Feldes in meinen Handlern öffne.

Es scheint, dass alles ganz einfach ist. Ich habe einen Handler geschrieben und an console.log () ausgegeben, was mir einfällt. Beim Öffnen von DevTools in einigen Browsern wird bfcache möglicherweise plötzlich heruntergefahren. Das heißt, ich habe DevTools geöffnet, gehe die Seiten hin und her und meine Beharrlichkeit ist immer falsch, die Seite gelangt nicht in den bfcache. Okay, ich habe ein anderes mächtiges Werkzeug - Alarm.

Aber nein. Moderne Browser ignorieren beim Entladen einer Seite in der Seitenhaut, vor dem Entladen und Entladen einfach die Warnung, es funktioniert dort einfach nicht. Und wieder sehe ich nicht, was ich will.

Okay, ich habe ein noch besseres Produkt. Ich bin in einem Block direkt auf meiner eigenen Seite, die ich erforsche. Ich füge nur den Text des Inhalts meiner Veranstaltung hinzu und protokolliere dabei alles. Diese Methode hat funktioniert.

Alles kann bitte verwendet werden. Ich habe meinen Code getestet, es funktioniert für mich, ich kann damit fortfahren. Natürlich vergesse ich nicht, dass ein externes statisches Skript besser geeignet ist, um nicht denselben Inline-Code auf die Seite zu laden, sondern um das Zwischenspeichern von Dateien zu verwenden.

Ich habe diesen debuggten Code in ein externes Skript eingefügt.

Aber nein, die Pageshide-Handler von Pageshow sind in Safari abgefallen! Aus irgendeinem Grund funktionieren sie nicht mit einem externen Skript.

Okay, ich habe bereits eine funktionierende Version. Ich musste es so lassen.

Ich werde kurz auflisten, was ich an nur einem Tag geschafft habe. Erstens können DevTools das Caching deaktivieren. Sie erinnern sich wahrscheinlich, dass in DevTools auf der Registerkarte "Netzwerk" in Chrome das Kontrollkästchen "Cache deaktivieren" aktiviert ist. Es deaktiviert den Netzwerkcache, hat möglicherweise keinen Einfluss auf den BFCache oder auf den Netzwerkcache. Die Analogie ist klar: Wir haben DevTools geöffnet, was bedeutet, dass wir uns weiterentwickeln und möglicherweise kein Caching benötigen. Vielleicht stört es uns.

Die zweite Funktion ist Alarm. Firefox und Safari ignorieren es stillschweigend und führen die Handler weiter aus, als ob es keine Warnung gäbe. Und nur ein gutes altes Chrome in der Konsole schreibt einen Fehler in Rot - Sie haben eine Warnung, ich habe sie blockiert, wissen Sie Bescheid!

Ich erinnere Sie noch einmal daran, dass Handler aus einem externen Skript in Safari möglicherweise nicht aufgerufen werden. Dies ist sehr seltsam.

Und noch eine wichtige Neuigkeit. Wenn Ihre Seite zwischengespeichert ist, das heißt, Sie haben ein Pagehide-Ereignis erhalten, und es heißt "persistiert wahr", und der Browser sagt zu Ihnen: "Ja, ich habe es in den Cache gestellt" - dies gibt keine Garantie dafür, dass die Seite jemals später sein wird aus diesem Cache wird ausgelöst und dem Benutzer wieder angezeigt. Weil der Browser möglicherweise beschließt, diesen Cache zu leeren, wenn ihm der Speicher ausgeht. Weil der Benutzer den Browser schließen und nirgendwo navigieren kann. Merk dir das.

Implementierungsfunktionen

Ich begann mich weiter mit der Dokumentation zu beschäftigen, um zu erforschen, wie ich mit diesem Wissen leben kann. Überraschenderweise war die Dokumentation. Das heißt, Sie können im Internet eine Beschreibung der Funktionsweise von bfcache in Browsern finden. Aber je weiter ich lese, desto mehr Unterschiede häufen sich zwischen verschiedenen Browsern.

In einem funktioniert es so, in dem anderen funktioniert es. In einem stört einer, der andere stört nicht. Entwickler wissen nicht, wie sie eine Reihe von APIs beim Platzieren einer Seite in bfcache korrekt verarbeiten können. Sie sagen: OK, wenn die Seite diese API verwendet, dann ignoriere ich sie einfach und lege sie unter keinen Umständen in den Cache. Und diese Liste ist in verschiedenen Browsern unterschiedlich, jeder tut, was er passt.

Und dann fing ich an, das Gelernte in einem Tisch zu kombinieren. Ich habe so etwas wie das Folgende:

Ich habe die Dokumentation für Browser gelesen - für Firefox, Safari, die Chromium-Familie. Es gab Dokumentation zum IE, wenn auch veraltet. Wir Programmierer möchten die Dokumentation nach Änderungen im Browser nicht aktualisieren? Als ich feststellte, dass die Informationen nicht mehr aktuell waren, begann ich, meine kleinen Seiten in Browsern zu testen und zu überprüfen, welche API funktioniert und welche nicht.

Auch dies war nicht genug: Ich weiß nicht, welche APIs im Prinzip zu betrachten sind, aber überhaupt nicht zu sortieren? Und ich musste den Quellcode der Browser-Engines selbst untersuchen, dh der Code erwies sich als die genaueste und zuverlässigste Wissensquelle. Im Moment ist diese Platte (vor Ihnen ist ein Teil davon, hier ist ein Link zur Vollversion) die umfassendste Sammlung von Wissen darüber, welche APIs es bfcache erlauben oder verbieten, in Browsern zu arbeiten.

APIs, die ein Häkchen und die grüne Farbe nicht beeinträchtigen. Diejenigen, die definitiv verhindern, dass die Seite in den bfcache gelangt, sind rot markiert. Weiße Felder sind Leerzeichen, die nirgendwo beschrieben werden.

Feuerfuchs

Hier sind einige interessante Details aus bestimmten Browsern. Ich fange mit Firefox an, er war der erste, der alles gemacht hat.

^{_{Link von der Folie}}

Das Wichtigste, was ich aus den Quellen von Firefox gelernt habe, ist, dass bei der Arbeit mit bfcache alle Gründe, warum die Seite nicht in den Cache gestellt werden kann, in das Textprotokoll auf der Festplatte geschrieben werden können.

^{_{Link von der Folie}}

Und ich habe es sogar geschafft herauszufinden, wie ich es dazu bringen kann. Es gibt zwei geheime Umgebungsvariablen: In einer geben wir an, was protokolliert werden soll, in der zweiten - in welcher Datei ein Protokoll geschrieben werden soll. Danach starten wir die Binärdatei und voila! Wir werden ungefähr sehen, dass auf der vorherigen Folie Zeilen der Form "solches HTML kann aus einem solchen Grund, aus einem anderen Grund, nicht zwischengespeichert werden können". Wir können es sofort lesen, sehr praktisch.

Wenn Sie einmal experimentieren möchten, können Sie die Seite about: networking in Firefox öffnen. Dort können Sie im Bereich "Journal" die gleichen Felder eingeben. Wir können in zwei Feldern angeben, was und wo protokolliert werden soll, und mit den Schaltflächen das Protokoll starten und stoppen.

^{_{Link von der Folie}}

Wann weigert sich Firefox, die Seite zwischenzuspeichern? Wenn Sie unvollständige Anfragen haben, einschließlich AJAX-Anfragen oder Anfragen nach Ressourcen wie Bildern, lehnt er es ab, die Seite in den bfcache zu stellen. Er glaubt, dass es nicht abgeschlossen ist, das Herunterladen noch nicht abgeschlossen ist und es eine verdächtige Aktivität gibt. Dies alles gilt jedoch nicht für Favicon. Wenn Sie Favicon vergessen haben und es nicht geladen wird, denkt er - okay, er wird es tun, es ist normal für Ihre Website.

Wenn Sie ein Skript mit langer Laufzeit haben, werden Sie vom Browser gefragt: Da es einige Zeit dauert, blockiert es die Benutzeroberfläche und schlägt es möglicherweise? Und wenn Sie einverstanden sind, wird eine solche Seite als etwas falsch angesehen, und wir speichern sie nicht zwischen.

Wenn Sie IndexedDB verwenden ... Dies ist eine lehrreiche Geschichte. Zuvor sahen sie in der ersten Implementierung so aus: Wenn Sie IndexedDB haben und eine unvollständige Transaktion vorliegt, wird eine solche Seite nicht zwischengespeichert, da nicht klar ist, wie Sie damit arbeiten sollen (wir versuchen, sie mitten in der Transaktion auszublenden). Aber dann haben sie diesen Code beim Refactoring einfach verloren. Und wie Sie sich vorstellen können, hatten sie keine Tests dafür. Sie haben sogar einen Fehler im Bugtracker. Er ist schon zwei Jahre alt mit etwas. Die Leute schrieben: "Mein bfcache mit IndexedDB funktioniert nicht richtig. Was soll ich tun?" Firefox-Entwickler antworteten - es bricht wirklich zusammen, wir haben diesen Text gerade während des Refactorings verloren, okay, lass es weitergehen. Moral: Schreibe Tests, auch wenn du Firefox schreibst, sonst kann alles traurig enden.

Und noch ein interessanter Faktor für die Nichtverfügbarkeit in bfcache - wenn gemischte Inhalte ausdrücklich erlaubt sind. Was ist das?

^{_{Link von der Folie}}

Angenommen, Ihre Seite wird über HTTPS geöffnet, Sie laden jedoch weiterhin einige Ressourcen über HTTP, insbesondere Skripte. Das heißt, Sie haben ein Nicht-Sicherheits-Skript, das von jedem geändert werden kann.

^{_{Link von der Folie}}

Standardmäßig führt Firefox wie andere Browser derzeit kein solches Nicht-Sicherheits-Skript aus. Wenn es für Sie jedoch sehr wichtig ist, dass Sie in die Einstellungen geklettert sind und die Ausführung zugelassen haben, wird eine solche Seite dementsprechend nicht zwischengespeichert. Er wird sagen - nun, Sie haben mir gesagt, ich soll den Code nicht ausführen, aber dann nein, nein!

Eine weitere Optimierung ist die Größe von bfcache. Hier ist der Standardwert minus eins. Das bedeutet, wie viel Speicher Firefox hat, so viele Seiten, die es zwischenzuspeichern versucht. Wir können den Cache jedoch zwangsweise deaktivieren, indem wir eine Null setzen oder explizit eine Zahl festlegen. Denken Sie beispielsweise an nicht mehr als fünf Seiten.

Warnung: Die nächste Folie enthält Beispielcode in der beängstigenden C ++ - Sprache. Dies kann bei einer Front-End-Konferenz gefährlich sein. Versuchen Sie nicht, es zu kopieren, sondern führen Sie es in der Browserkonsole aus. Ihre Festplatte ist möglicherweise formatiert, der Bildschirm explodiert oder Bitcoins werden möglicherweise abgebaut. Ich habe dich gewarnt.

^{_{Link von der Folie}}

Also der Gecko-Code. Es kann kostenlos im Internet geöffnet, gelesen und angezeigt werden. Und ich kramte. Es gibt die wichtigste Methode - CanSavePresentation (), die die Frage beantwortet: Ist es möglich, dieses Dokument zwischenzuspeichern? Das heißt, dies ist die ultimative Quelle der Wahrheit über das, was jetzt in Firefox implementiert ist. Und doch - von dort habe ich gelernt, dass Sie das Protokoll lesen können. Es gibt eine solche Variable - gPageCacheLog. Dies ist das Protokoll, in das alles geschrieben ist. Hier ist eine so interessante Geschichte über einen Ausflug in C ++.

Das heißt, Sie öffnen den Link, sehen sich den Code an, suchen (es gibt eine bequeme und darüber hinaus schnelle Suche) und können die tatsächlichen Implementierungsdetails in der neuesten Version des Browsers herausfinden - diejenigen, die einfach in der Dokumentation fehlen.

Safari

Das Grausamste, was Safari tut, wenn eine Seite auf bfcache trifft: Wenn Sie AJAX-Anfragen ausstehen, werden diese von Safari einfach beendet.

Selbst wenn Sie sie mit Fehlerbehandlungsroutinen überlagern und versuchen, alles zu überprüfen, korrigieren Sie dies - es scheint, als ob die Anforderung überhaupt nicht vorhanden war. Nach der Wiederherstellung von bfcache haben Sie keinen Fehler, kein "OK", überhaupt nichts.

Die Handler von Pageshow Pagehide in Safari werden, wie gesagt, nur aufgerufen, wenn sie in einem Skript geschrieben sind, das in die Seite integriert ist. Von einem externen Skript aus können sie funktionieren oder nicht - wie viel Glück. Aber ich habe dich gewarnt.

Ein weiterer interessanter Unterschied: Handler vor dem Entladen und Entladen stören die Seite nicht, die in den bfcache gelangt. In diesem Fall wird beforeunload immer aufgerufen, und wenn es in den Cache gelangt und nicht getroffen wird. Das Entladen, wenn die Seite den Cache erreicht, wird jedoch nicht aufgerufen. Und hier ist ein weiterer Rake: Die Seite wird möglicherweise in den Cache verschoben und wird dort nie angezeigt. Wenn Sie beim Entladen einen wichtigen Code geschrieben haben, wird dieser möglicherweise nie aufgerufen, obwohl auf der Seite kein einziger Fehler aufgetreten ist. Das heißt, es ging korrekt in den Cache und von dort ins Nirgendwo, und Ihr Entladen wird niemals aufgerufen.

Ein weiterer interessanter Punkt. Wie Sie wissen, können Sie über window.open () mehrere Fenster öffnen. Gleichzeitig haben diese Fenster Links zueinander. Das heißt, sie können gleichzeitig in das Fenster des anderen klettern und verschiedene Eigenschaften lesen / schreiben. Dieses Öffnen von untergeordneten Fenstern stört bfcache nicht. Und hier ist Safari höchstwahrscheinlich genauso grausam wie bei AJAX-Anfragen, das heißt, alles reißt hart und auf Wiedersehen. Apple-Entwickler lieben es schwerer.

Wieder eine Minute C ++! WebKit-Quellen sind ebenfalls nicht geheim, sie können auch geöffnet, gelesen und untersucht werden.

^{_{Link von der Folie}}

Sie befinden sich auf GitHub. Dort habe ich zwei wichtige Funktionen hervorgehoben:

- canCacheFrame () - Überprüfen Sie, ob dieser Frame zwischengespeichert werden kann.
- In verschiedenen Objekten auf der Seite, z. B. einem HTML-Element oder einer Schriftart, gibt es canSuspendForDocumentSuspension () -Methoden. Dieses Objekt ist dafür verantwortlich, ob es zwischenspeichern, einfrieren kann oder nicht.

Und noch ein wichtiger Aspekt: WebKit bietet sehr praktische Tests. Dort, direkt im Ordner LayoutTests / fast / history, gibt es in Form eines kleinen, kompakten und präzisen HTML-Tests Tests für die Arbeit verschiedener APIs, die in Safari mit bfcache implementiert sind. Dies ist ein lebendiges Beispiel dafür, wie Sie mit diesen APIs Code in Safari schreiben können und wie sie sich darauf auswirken oder nicht, ob sie bfcache-Treffer zulassen oder nicht. Sehr interessant zu sehen.

Von dort erfuhr ich, dass Safari auch sein gesamtes Wissen über bfcache und alle Funktionen in ein Textprotokoll schreibt. Leider habe ich nie herausgefunden, wie diese Protokollierung aktiviert werden kann oder wo diese Datei auf der Festplatte zu finden ist, wenn sie aktiviert ist. Wenn jemand weiß, sag es mir, ich werde sehr dankbar sein.

Chrom.

Wie ich bereits sagte, dort wird noch gearbeitet, alles ist unter der Flagge geschlossen. Sie können den frischen Chrome Canary herunterladen und zu den Flaggen gehen. Die Einstellung ist dort versteckt - Sie können versuchen, damit zu spielen. Sie könnten etwas sehen.

Aus dem Interessanten - ich habe bereits über das Öffnen einer Seite durch window.open () gesprochen. In Chromium werden solche Seiten bisher nicht zwischengespeichert. Sie haben nicht herausgefunden, wie sie das alles richtig lösen können, und haben es schamlos abgeschnitten, wie in Safari, ihr Gewissen erlaubt es ihnen nicht.

Wenn DOMContentLoaded nicht auftritt, wird die Seite auch nicht zwischengespeichert.

Es gibt viele neue APIs, die mit "Web" beginnen - es ist auch schwierig und unverständlich mit ihnen, und bis jetzt deaktivieren alle standardmäßig bfcache. Das heißt, wenn auf der Seite etwas Trendiges, Neues verwendet wird, wie z. B. WebGL, WebVR, WebUSB, WebBluetooth usw., wird eine solche Seite nicht in den bfcache gelangen.

Servicemitarbeiter. Außerdem wird eine solche Seite noch nicht zwischengespeichert, aber wir planen, sie korrekt zu verarbeiten und sie vor den wachsamen Augen des Servicemitarbeiters zu verbergen.

Wenn die Geolokalisierung aktiviert ist, wird sie auch noch nicht zwischengespeichert. So einfach für jetzt.

Wenn während der Zeit, in der sich die Seite im Cache befand, die Cookies verrottet waren, glauben wir, dass eine Autorisierung abgelaufen ist. Vielleicht war es Online-Banking oder etwas anderes. Dies bedeutet, dass die Seite nicht mehr gültig ist - wir löschen sie aus dem Cache.

^{_{Link von der Folie}}

Die Google-Leute gingen noch weiter. Sie schlugen vor, alles zu vereinheitlichen, in allen Browsern zu vereinheitlichen, eine Spezifikation für den Seitenlebenszyklus für alle Zustände vorzuschlagen und neue Ereignisse zu Übergängen zwischen verschiedenen Zuständen hinzuzufügen. Sie können sich den Link ansehen, den sie sich dort ausgedacht haben.

^{_{Link von der Folie}}

Quellen. Wie Sie wissen, sind auch Chromquellen verfügbar. All dies liegt in einer Klasse namens BackForwardCacheImpl - sehr gute Benennung, musste fast nicht aussehen. Die Hauptmethode, die prüft, ob ein Dokument gespeichert werden kann, heißt CanStoreDocument (). Es gibt auch eine GetDisallowedFeatures () -Methode, die einfach alle neuen Funktionen und APIs auflistet, die in bfcache nicht unterstützt werden. Sehr praktisch: an einem Ort konzentriert, gelesen und realisiert, was derzeit möglich ist und was nicht.

Internet Explorer 11

Ein Ausflug in die Geschichte für diejenigen, die noch IE 11 haben. Für diejenigen, die alles schlecht haben.

Dort gibt es bfcache, und dies ist das Hauptproblem, weil Sie sich damit befassen müssen. Die Dokumentation besagt, dass bfcache angeblich nur über HTTP funktioniert. Tatsächlich funktioniert es in der Produktion aus irgendeinem Grund auch mit HTTPS. Moral: Wenn Sie Entwickler sind, achten Sie bitte auf Ihre Dokumentation. Dann musst du wegen ihr leiden.

Wenn es einen Handler vor dem Laden gibt, wird verhindert, dass er in den Cache gelangt. Sie haben in der Dokumentation nichts über das Entladen gesagt - vielleicht haben sie es nicht gewusst oder vergessen.

Wenn die Seite noch nicht vollständig geladen wurde, wird sie auch nicht zwischengespeichert. Wenn jemand ActiveX-Komponenten verwendet, wird dieser auch nicht zwischengespeichert. Und wenn DevTools auch dort geöffnet ist. Dies ist ein wichtiger Punkt.

Wie ohne Fehler? Behobenes Feld hinzugefügt, aber manchmal funktioniert es nicht. Das heißt, die Seite gelangt wirklich in den Cache, kehrt von dort zurück und wird nicht auf true gesetzt. Was zu tun ist?

Wir hatten einen schönen Code, der bestimmt, ob wir aus dem Cache zurückgekehrt oder vom Server neu geladen wurden.

Jetzt musste es mit einer Krücke für IE ergänzt werden. Wir stellen fest, dass wir IE haben, und in einigen Problemumgehungen verstehen wir, dass die Seite immer noch aus dem Cache extrahiert wurde und gleichzeitig eine Verlaufsnavigation (back_forward) hatten.

Woher wissen Sie außerdem, ob eine Seite zwischengespeichert ist? Wir nehmen ihr Ladezeit. Wenn es in 50 Millisekunden oder schneller vom Server geladen wird, kann dies im Grunde nicht im IE sein - es bedeutet, dass es aus dem Cache stammt! :) :)

Ich habe bereits die Navigation durch die Geschichte erwähnt. Wenn wir den Navigationstyp back_forward haben, haben wir den Verlauf durchgesehen, und wenn die Seite aus dem Cache stammt, bedeutet dies bfcache, dass es im IE keine anderen Optionen gibt.

Was weiter?

Was tun als nächstes mit diesem Wissen? Ich möchte nicht, dass du rausgehst und das alles wie ein Albtraum vergisst.

- Erstens ist hier das Wertvollste, auf das ich gestoßen bin und worauf ich Sie drängen möchte: Verwenden Sie Open-Source-Browser! Im offenen Zugang zum Internet befinden sich derzeit die Quellcodes aller führenden Browser, die unsere Kunden verwenden. Und dies ist die relevanteste Dokumentation darüber, wie und wie es unterstützt wird, wo und wie es funktioniert. Dazu gehören Tests, die direkt in HTML und JS geschrieben sind. Verwenden Sie, schauen Sie!

- Zweitens sollten Sie in vorhandenen Anwendungen berücksichtigen, dass sie in bfcache ausgeführt werden können. Informieren Sie Ihre Tester darüber, damit sie beim Überprüfen der Navigation wissen, dass beim Navigieren durch den Verlauf die Seite sowohl vom Server als auch vom bfcache aus geöffnet werden kann. Hier ist ein Video des echten Fehlers, den wir behoben haben, als bfcache für uns gearbeitet hat:

Öffnen Sie GIF

Der Benutzer gibt vier Anforderungen ein und sieht vier Probleme. Danach geht es zurück, sieht Problem 3 und Abfrage 4. Ein anderes vorheriges Problem ist 2 und Abfrage 3. Das heißt, es hat einen nicht übereinstimmenden Status der Seite - der Inhalt der Such- und Suchzeichenfolgen widerspricht sich. Beachten Sie dies in Ihren Anwendungen.

- Und drittens, wenn Sie neuen Code schreiben, überlegen Sie, ob Sie bfcache benötigen. Verwenden Sie in diesem Fall die API-Kompatibilitätstabelle. Wenn nicht, verwenden Sie nicht, aber wenn Sie versehentlich in bfcache geraten, sollten Sie die Funktionen von Safari und anderen Browsern berücksichtigen, die ich erwähnt habe. Einige Dinge können unverschämt reißen, und Sie werden nicht verstehen können, warum dies geschieht.

Wie versprochen ein Link zu den Materialien.

BFCache oder Hin und zurück. Yandex-Bericht