caching - Stoppen Sie den Browser, um HTTP-Anforderungen für Bilder zu stellen, die zwischengespeichert bleiben sollen - mod_expires

Translate

Nachdem Sie viele Artikel und einige Fragen hier gelesen haben,Es gelang mir schließlich, den Apachen zu aktivierenmod_expiresUm dem Browser mitzuteilen, MUSS er Bilder für 1 Jahr zwischenspeichern.

<filesMatch "\.(ico|gif|jpg|png)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</filesMatch>

Und zum Glück scheinen die Serverantworten korrekt zu sein:

HTTP/1.1 200 OK 
Date: Fri, 06 Apr 2012 19:25:30 GMT 
Server: Apache 
Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT 
Accept-Ranges: bytes 
Content-Length: 24884 
Cache-Control: max-age=31536000, public 
Expires: Sat, 06 Apr 2013 19:25:30 GMT
Connection: close
Content-Type: image/jpeg 

Nun, ich dachte, dies würde den Browser stoppen, um den Server herunterzuladen und sogar 1 Jahr lang nach den Bildern zu fragen. Aber es ist teilweise wahr: UrsacheWenn Sie den Browser schließen und erneut öffnen, lädt der Browser die Bilder NICHT heruntervom Server nicht mehr,Der Browser fragt den Server jedoch weiterhin mit einer HTTP-Anforderung für jedes Bild ab.

Wie zwinge ich den Browser, keine HTTP-Anfragen mehr für jedes Bild zu stellen? Auch wenn auf diese HTTP-Anforderungen kein Image heruntergeladen wird, handelt es sich dennoch um Anforderungen an den Serverdas erhöht unnötig die Latenz und verlangsamt das Rendern der Seite!

Ich habe dem Browser bereits gesagt, dass die Bilder 1 Jahr lang im Cache bleiben MÜSSEN! Warum fragt der Browser immer noch den Server für jedes Bild ab (auch wenn das Bild nicht heruntergeladen wird)?!


Beim Betrachten von Netzwerkdiagrammen in FireBug (Menü FireBug> Net> Images) kann ich verschiedene Caching-Verhaltensweisen feststellen (ich habe offensichtlich damit begonnen, dass der Browser-Cache vollständig leer ist, ich habe das Löschen des Caches im Browser mithilfe von "Alle Verlauf löschen" erzwungen):

  • Wenn die Seite zum ersten Mal geladen wird, werden alle Bilder heruntergeladen(und dasselbe passiert, wenn ich ein erneutes Laden der Seite erzwinge, indem ich auf die Schaltfläche zum erneuten Laden der Seite des Browsers klicke).Das macht Sinn!

  • Wenn ich auf der Website navigiere und zur gleichen Seite zurückkehreDie Bilder werden überhaupt nicht heruntergeladen und dieDer Browser fragt NICHT einmal den Server abfür eines der Bilder.Dies ist sinnvoll (und ich würde dieses Verhalten auch gerne sehen, wenn der Browser geschlossen ist)!

  • Wenn ich den Browser schließe und ihn auf derselben Seite wieder öffne, sendet der alberne Browser trotzdem einmal pro Bild eine HTTP-Anfrage an den Server: Das Bild wird NICHT heruntergestuft, aber es wird immer noch eine HTTP-Anfrage gestellt, als würde der Browser die anfragen Server über das Bild(Server antwortet mit 200 OK).Das ist derjenige, der mich irritiert!

Ich füge auch die folgenden Grafiken hinzu, wenn Sie interessiert sind:

enter image description here

enter image description here

BEARBEITEN: Gerade jetzt auch mit FireFox 11.0 getestet, nur um sicherzugehen, dass mein FireFox 3.6 nicht zu alt ist. Das gleiche passiert !!!Ich habe auch die Google-Site und die Stackoverflow-Site getestet, senden sie beide dieCache-Control: max-age=...aberDer Browser sendet weiterhin eine HTTP-Anfrage an den Server für jedes Bild, sobald der Browser auf derselben Seite geschlossen und erneut geöffnet wirdNach der Antwort des Servers lädt der Browser das Bild NICHT herunter (wie oben erläutert), stellt jedoch die verdammte Anfrage, die die Zeit zum Anzeigen der Seite verlängert.

EDIT2: und entfernen Sie dieLast-ModifiedHeader wie vorgeschlagenHier, löst das Problem nicht, es macht keinen Unterschied.

This question and all comments follow the "Attribution Required."

Alle Antworten

Translate

Sie haben das falsche Tool zum Analysieren der Anforderungen verwendet.

Ich würde das wirklich nützliche Firefox-Addon empfehlenLive-HTTP-HeaderSo können Sie sehen, was wirklich im Netzwerk vor sich geht.

Und nur um sicher zu gehen, können Sie Ihren Server ssh / putty und so etwas tun

tail -f /var/log/apache2/access.log
Quelle
Translate

Das Verhalten, das Sie sehen, ist beabsichtigt (sieheRFC7234für weitere Details), angegebenes Verhalten:

Alle modernen Browser senden HTTP-Anforderungen für jedes angezeigte Seitenelement an den Server, unabhängig vom Cache-Status. Dies war eine Entwurfsentscheidung, die auf Anfrage von Webdiensten (insbesondere Werbenetzwerken) getroffen wurde, um sicherzustellen, dass HTTP-Server Aufzeichnungen über jede Anzeige jedes Elements führen können.

Wenn die Browser diese Anforderungen nicht stellen würden, würde der Server niemals benachrichtigt, dass dem Benutzer ein Bild angezeigt wurde. Für Werbenetzwerke wäre dies katastrophal. Schon früh haben sich Werbenetzwerke "gehackt", indem sie dasselbe Anzeigenbild mit zufällig generierten Namen (z. B. "coke_ad_1_98719283719283.gif") geschaltet haben. Für ISPs führte diese Vorgehensweise jedoch zu einer enormen Zunahme der Datenübertragungen, da jeder ihrer Benutzer diese identischen Anzeigenbilder erneut herunterlud und alle Caching- / Proxyserver umging, die von ihrem ISP betrieben wurden.

So wurde ein Waffenstillstand geschlossen: Browser sendeten immer HTTP-Anfragen, auch für nicht abgelaufene zwischengespeicherte Elemente. Server würden mit HTTP 304-Statuscodes antworten ("nicht geändert"). Auf diese Weise können die Server die Tatsache aufzeichnen, dass das Bild dem Client angezeigt wurde. Infolgedessen WerbenetzwerkeallgemeinVerwenden Sie keine zufälligen Bildnamen mehr, um Netzwerk-Cache-Server zu umgehen.

Dies gab den Werbenetzwerken das, was sie wollten - eine Aufzeichnung jedes angezeigten Bildes - und ISPs das, was sie wollten - cachefähige Bilder und statische Inhalte.

Aus diesem Grund können Sie nicht viel tun, um zu verhindern, dass Browser HTTP-Anforderungen für zwischengespeicherte Seitenelemente senden.

Wenn Sie sich jedoch andere verfügbare clientseitige Lösungen ansehen, die mit HTML5 geliefert wurden, gibt es einen Bereich, der das Laden von Ressourcen verhindert

  1. Cache-Manifest(trotz seiner Fallstricke)
  2. IndexedDB(nette asynchrone Funktionen, ermöglicht die Speicherung von Blobs)
  3. Lokaler Speicher(nicht asynchron)
Quelle
Translate

Es gibt einen Unterschied zwischen "Nachladen" und "Aktualisieren". Nur das Navigieren zu einer Seite mit Zurück- und Vorwärtsschaltflächen löst normalerweise keine neuen HTTP-Anforderungen aus. Wenn Sie jedoch speziell F5 drücken, um die Seite zu "aktualisieren", überprüft der Browser den Cache. Dies ist browserabhängig, scheint jedoch die Norm für FF und Chrome zu sein (dh die Browser, die in der Lage sind, ihren Netzwerkverkehr einfach zu überwachen). Wenn Sie F6 drücken, sollten Sie die URL-Adressleiste fokussieren und dann "dorthin" gehen, was sollte Laden Sie die Seite neu, aber überprüfen Sie die Assets auf der Seite nicht noch einmal.

Aktualisieren: Klärung des Navigationsverhaltens vor und zurück. Es heißt "Back Forward Cache" oderBFCachein Browsern. Wenn Sie mit den Schaltflächen Zurück / Vorwärts navigieren, soll Ihnen genau angezeigt werden, wie die Seite war, als Sie sie in Ihrer eigenen Zeitleiste gesehen haben. Bei der Verwendung von Vor- und Zurück werden keine Serveranforderungen gestellt, selbst wenn ein Server-Cache-Header angibt, dass ein bestimmtes Element abgelaufen ist.

Wenn Sie in Ihrem Entwickler-Netzwerkfenster (200 OK BFCache) sehen, wurde der Server nie getroffen - auch nicht, um zu fragen, ob er seitdem geändert wurde.

http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfcache/

Quelle
Translate

Wenn ich eine Aktualisierung mit F5 oder F5 + Strg erzwinge, wird eine Anfrage gesendet. Wenn ich jedoch den Browser schließe und die URL erneut eingebe, wird KEINE Anforderung gesendet. Die Art und Weise, wie ich getestet habe, ob eine Anfrage gesendet wird oder nicht, war die Verwendung von Haltepunkten beim Start der Anfrage auf dem Server, auch wenn eine Anfrage nicht gesendet wird. Sie wird in Firebug immer noch als 7 ms Wartezeit angezeigt. Achten Sie also darauf.

Quelle
Translate

Was Sie hier beschreiben, spiegelt nicht meine Erfahrung wider. Wenn Inhalte mit einer No-Store-Direktive bereitgestellt werden oder Sie eine explizite Aktualisierung durchführen, würde ich erwarten, dass sie zum Ursprungsserver zurückkehren, andernfalls sollte sie bei Neustarts des Browsers zwischengespeichert werden (vorausgesetzt, sie dürfen und können schreiben eine Cache-Datei).

Wenn Sie Ihre Wasserfälle etwas genauer betrachten (was schwierig ist, weil sie etwas klein und verschwommen sind), scheint der Browser genau das zu tun, was er sollte - eshatEinträge für die Bilder - aber diese werden nur geladenaus dem lokalen Cachenicht vom Ursprungsserver - überprüfen Sie den 'Date'-Header in der Antwort (warum dauert es Ihrer Meinung nach Millisekunden statt Sekunden?). Deshalb sind sie unterschiedlich gefärbt.

Quelle
Translate

Nachdem ich viel Zeit damit verbracht hatte, nach einer vernünftigen Antwort zu suchen, fand ich den folgenden Link am nützlichsten und er beantwortet die hier gestellte Frage.

https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests

Quelle
Translate

Wenn es um Leben oder Tod geht (Wenn Sie das Laden von Seiten auf diese Weise optimieren oder die Belastung des Servers so weit wie möglich reduzieren möchten, egal was passiert), gibt es eine Problemumgehung.

Verwenden Sie HTML5lokaler SpeicherBilder zwischenzuspeichern, nachdem sie zum ersten Mal angefordert wurden.

  • [+]Sie können verhindern, dass der Browser HTTP-Anforderungen sendet, die in 99% 304 (nicht geändert) zurückgeben, unabhängig davon, wie sehr sich der Benutzer bemüht (F5, Strg + F5, einfach die Seite erneut aufrufen usw.).

  • [-]Sie müssen dafür einige zusätzliche Anstrengungen in die Javascript-Unterstützung investieren.

  • [-]Bilder werden in base64 gespeichert (wir können keine Binärdaten speichern), deshalb werden sie jedes Mal auf der Clientseite dekodiert. Welches istmeistensZiemlich schnell und keine große Sache, aber es ist immer noch eine zusätzliche CPU-Auslastung auf Client-Seite und sollte beachtet werden.

  • [-]Der lokale Speicher ist begrenzt. Sie können ~ 5 MB Daten pro Domain verwenden (Hinweis: base64 erhöht die ursprüngliche Bildgröße um ~ 30%).

  • [?]Unterstützt durchMehrheitvon Browsern.http://caniuse.com/#search=localstorage

Beispiel

Prüfung

Quelle
Translate

Was Sie in Chrome sehen, ist keine Aufzeichnung der tatsächlichen HTTP-Anforderungen, sondern eine Aufzeichnung der Asset-Anforderungen. Chrome zeigt Ihnen damit, dass ein Asset tatsächlich von der Seite angefordert wird. Diese Ansicht zeigt jedoch nicht wirklich an, ob die Anforderung gestellt wird. Wenn ein Asset zwischengespeichert wird, erstellt Chrome die zugrunde liegende HTTP-Anforderung niemals.

Sie können dies auch bestätigen, indem Sie den Mauszeiger über die violetten Segmente in der Zeitleiste bewegen. Zwischengespeicherte Ressourcen haben eine(from cache)im Tooltip.

Um die tatsächlichen HTTP-Anforderungen anzuzeigen, müssen Sie auf einer niedrigeren Ebene suchen. In einigen Browsern kann dies mit einem Plugin (wie Live-HTTP-Headern) erfolgen.

In der Realität müssen Sie jedoch Ihre Serverprotokolle überprüfen oder einen Debugging-Proxy wie Charles oder Fiddler verwenden, um zu überprüfen, ob die Anforderungen nicht tatsächlich gestellt werden. Dies funktioniert auf HTTP-Ebene, um sicherzustellen, dass die Anforderungen nicht tatsächlich ausgeführt werden.

Quelle
Translate

Cache-Validierung und die 304-Antwort

Es gibt eine Reihe von Situationen, in denen Internet Explorer überprüfen muss, ob ein zwischengespeicherter Eintrag gültig ist:

  • Der zwischengespeicherte Eintrag hat kein Ablaufdatum und der Inhalt wird zum ersten Mal in einer Browsersitzung aufgerufen

  • Der zwischengespeicherte Eintrag hat ein Ablaufdatum, ist jedoch abgelaufen

  • Der Benutzer hat eine Seitenaktualisierung angefordert, indem er auf die Schaltfläche Aktualisieren klickt oder F5 drückt

Wenn der zwischengespeicherte Eintrag ein letztes Änderungsdatum hat, sendet der IE es im If-Modified-Since-Header einer GET-Anforderungsnachricht:

GET /images/logo.gif HTTP/1.1
Accept: */*
Referer: http://www.google.com/
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.google.com

Der Server überprüft den If-Modified-Since-Header und reagiert entsprechend. Wenn der Inhalt seit dem angegebenen Datum / der angegebenen Uhrzeit nicht geändert wurde, antwortet er mit einem Statuscode von 304 und einer Antwortnachricht, die nur Überschriften enthält:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: GWS/2.1
Content-Length: 0
Date: Thu, 04 Oct 2004 12:00:00 GMT

Die Antwort kann schnell heruntergeladen werden, da sie keinen Inhalt enthält und der IE die erforderlichen Daten aus dem Cache liest. In der Tat ist es wie eine Umleitung in den lokalen Browser-Cache.

Wenn sich das angeforderte Objekt seit dem Datum / der Uhrzeit im Header If-Modified-Since tatsächlich geändert hat, antwortet der Server mit einem Statuscode von 200 und liefert die geänderte Version der Ressource.

Quelle
Translate

Diese Frage hat eine bessere AntwortHierauf der Webmaster Stack-Exchange-Site.

Weitere Informationen, die auch im obigen Link zitiert werden, finden Sie unterhttpwatch

Nach dem Artikel:

Es gibt eine Reihe von Situationen, in denen Internet Explorer überprüfen muss, ob ein zwischengespeicherter Eintrag gültig ist:

  • Der zwischengespeicherte Eintrag hat kein Ablaufdatum und der Inhalt wird zum ersten Mal in einer Browsersitzung aufgerufen
  • Der zwischengespeicherte Eintrag hat ein Ablaufdatum, ist jedoch abgelaufen
  • Der Benutzer hat eine Seitenaktualisierung angefordert, indem er auf die Schaltfläche Aktualisieren klickt oder F5 drückt

    Code hier eingeben

Quelle
Leave a Reply
You must be logged in to post a answer.
Über den Autor