ich Fragen, um die Forschung begonnen:
aktualisieren Ich fand ein. Wenn ich das letzte geänderte Datum jeder Unterquelle einer Seite zusammen mit der anfänglichen HTML-Seite senden könnte, könnte ein Browser vermeiden, nach geänderten Kopfzeilen zu fragen, sobald er jede Ressource mindestens einmal geladen hat. Dies wäre in der Tat besser, als alle Ressourcen mit der ursprünglichen Anforderung zu senden, da dies nur beim ersten Laden vorteilhaft wäre und bei nachfolgenden Ladevorgängen nachteilig wäre, da es für Browser besser wäre, ihren Cache zu verwenden (wie Barmar betonte). .
Jetzt stellt sich heraus, dass Sie selbst mit einer Web-Erweiterung den if-modified-since-Header nicht bekommen können und Sie dem Browser sicher nicht mitteilen können, die zwischengespeicherte Version zu verwenden, anstatt den Server zu kontaktieren.
Ich fand dann diesen Beitrag von Facebook auf, wie sie versuchten, den Verkehr zu reduzieren, indem sie ihre statischen Dateien hauchten und ihnen ein Ablaufdatum von 1 Jahr gaben. Dies würde bedeuten, dass die URL den Inhalt der Datei garantiert. Sie sahen immer noch viele unnötige, wenn-modifizierte-Anfragen und sie konnten Firefox und Chrome dazu bringen, das Verhalten ihrer Reload-Buttons zu ändern, um statische Ressourcen nicht mehr neu zu laden. Für Firefox benötigt dies einen neuen cache-control: immutable Header, für Chrome nicht.
Ich erinnerte mich dann, dass ich so etwas schon einmal gesehen hatte und es stellt sich heraus, dass es eine Lösung für dieses Problem gibt, die bequemer ist, als den Inhalt von Ressourcen zu haschen und sie mindestens zehn Jahre lang aus einer Datenbank zu bedienen. Es ist nur eine neue Versionsnummer im Dateinamen. Die noch bequemere Lösung wäre, nur eine Versionsabfrage hinzuzufügen, aber turns out that that doesn't always work.
Zugegebenermaßen ist die ständige Änderung Ihrer Dateinamen ein Ärgernis, da Dateien, die auf diese Dateien verweisen, ebenfalls geändert werden müssen. Die Dateien müssen jedoch nicht geändert werden. Wenn Sie den Server steuern, kann es so einfach sein wie das Schreiben einer Weiterleitungsregel, um sicherzustellen, dass logo.vXXXX.png zu logo.png umgeleitet wird (wobei XXXX der letzte modifizierte Zeitstempel in Sekunden seit der Epoche ist) [1]. Lassen Sie nun Ihr Vorlagensystem den Zeitstempel automatisch erzeugen, wie in Wordpress 'wp_enqueue_script.WordPress befriedigt sich tatsächlich mit der Query-String-Technik. Jetzt können Sie das Ablaufdatum in eine ferne Zukunft setzen und den unveränderlichen Cache-Header verwenden. Wenn Browser die Cache-Kontrolle respektieren, können Sie jetzt sicher Etags und Wenn-modifiziert-seit-Header ignorieren, da sie jetzt komplett redundant sind.
Diese Lösung garantiert, dass der Browser niemals nach einer Überprüfung des Caches fragt, und doch sollten Sie niemals eine veraltete Ressource sehen, ohne vorher über das Ablaufdatum entscheiden zu müssen.
Es beantwortet hier nicht die ursprüngliche Frage, wie vermieden werden kann, mehrere Anfragen zum Abrufen der Ressourcen auf derselben Seite in einem leeren Cache zu stellen, aber immer danach (solange der Browser-Cache nicht gelöscht wird)), Du bist gut! Ich nehme an, das ist gut genug für mich.
[1] Sie können sogar den Server-Overhead vermeiden, indem Sie den Zeitstempel für jede Ressource jedes Mal überprüfen, wenn eine Seite mit der Versionsnummer Ihrer Anwendung darauf verweist. Im Debug-Modus kann man zur Zeitentwicklung den Zeitstempel verwenden, um zu vermeiden, dass die Version bei jeder Änderung der Datei verändert werden muss.
Sie müssten das HTTP-Protokoll ändern und die Browser so umgestalten, dass sie mit diesem neuen Modell funktionieren. – Barmar
Vergessen Sie nicht, dass Browser viele Komponenten zwischenspeichern, so dass sie nicht jedes Mal heruntergeladen werden müssen. – Barmar
@Barmar Ich weiß, aber sie könnten auch die gesamte Version der Web-App zwischenspeichern. Wenn Daten über Ajax abgerufen werden, ändert sich die App nur einmal pro Version einer neuen Version. – nus