caching - Ferma il browser per fare richieste HTTP per immagini che dovrebbero rimanere nella cache - mod_expires

Translate

Dopo aver letto molti articoli e alcune domande qui,Alla fine sono riuscito ad attivare l'Apachemod_expiresper dire al browser che DEVE memorizzare nella cache le immagini per 1 anno.

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

E per fortuna le risposte del server sembrano essere corrette:

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 

Bene, pensavo che questo avrebbe fermato il download del browser e persino chiesto al server informazioni sulle immagini per 1 anno. Ma è parzialmente vero: causase chiudi e riapri il browser, il browser NON scarica le immaginipiù dal server,ma il browser richiede ancora al server una richiesta HTTP per ogni immagine.

Come impongo al browser di interrompere le richieste HTTP per ogni immagine? Anche se queste richieste HTTP non sono seguite da un'immagine in fase di download, sono comunque richieste fatte al serverche inutilmente aumenta la latenza e rallenta il rendering della pagina!

Ho già detto al browser che DEVE mantenere le immagini nella cache per 1 anno! Perché il browser richiede ancora al server ogni immagine (anche se non scarica l'immagine) ?!


Guardando i grafici di rete in FireBug (menu FireBug> Rete> Immagini) posso vedere diversi comportamenti di caching (ovviamente ho iniziato con la cache del browser completamente vuota, ho forzato una cancellazione della cache sul browser usando "Clear All History"):

  • Quando la pagina viene caricata per la prima volta, tutte le immagini vengono scaricate(e la stessa cosa accade se forzo il ricaricamento di una pagina facendo clic sul pulsante Ricarica pagina del browser).Questo ha senso!

  • Quando navigo nel sito e torno alla stessa paginale immagini non vengono affatto scaricate e il fileil browser NON chiede nemmeno al serverper una qualsiasi delle immagini.Questo ha senso, (e vorrei vedere questo comportamento anche quando il browser è chiuso)!

  • Quando chiudo il browser e lo riapro sulla stessa pagina, il browser sciocco fa comunque una richiesta HTTP al server una volta per immagine: NON downalod l'immagine, ma fa comunque una richiesta HTTP, è come se il browser chiedesse il server sull'immagine(il server risponde con 200 OK).Questo è quello che mi irrita!

Allego anche i grafici sottostanti se siete interessati:

enter image description here

enter image description here

EDIT: appena testato ora anche con FireFox 11.0 solo per assicurarmi che non fosse un problema del mio FireFox 3.6 troppo vecchio. Succede la stessa cosa !!!Ho anche testato il sito Google e il sito Stackoverflow, entrambi inviano il fileCache-Control: max-age=...mail browser effettua ancora una richiesta HTTP al server per ciascuna immagine una volta che il browser viene chiuso e aperto nuovamente sulla stessa pagina, dopo la risposta del server il browser NON scarica l'immagine (come ho spiegato sopra) ma fa comunque quella dannata richiesta che aumenta il tempo per vedere la pagina.

EDIT2: e rimuovendo il fileLast-Modifiedintestazione come suggeritoQui, non risolve il problema, non fa alcuna differenza.

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

Tutte le risposte

Translate

Stavi usando lo strumento sbagliato per analizzare le richieste.

Consiglierei l'addon Firefox davvero utileIntestazioni HTTP livecosì puoi vedere cosa sta realmente succedendo sulla rete.

E per sicurezza, puoi eseguire ssh / putty sul tuo server e fare qualcosa di simile

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

Il comportamento che stai vedendo è quello previsto (vediRFC7234per maggiori dettagli), comportamento specificato:

Tutti i browser moderni invieranno richieste HTTP al server per ogni elemento della pagina visualizzato, indipendentemente dallo stato della cache. Questa è stata una decisione di progettazione presa su richiesta dei servizi Web (in particolare le reti pubblicitarie) per garantire che i server HTTP fossero in grado di mantenere i record di ogni visualizzazione di ogni elemento.

Se i browser non avessero effettuato queste richieste, il server non sarebbe mai stato informato della visualizzazione di un'immagine all'utente. Per le reti pubblicitarie, questo sarebbe catastrofico. All'inizio, le reti pubblicitarie hanno "hackerato" il problema offrendo la stessa immagine dell'annuncio utilizzando nomi generati casualmente (es: "coke_ad_1_98719283719283.gif"). Tuttavia, per gli ISP questa pratica ha causato un enorme aumento dei trasferimenti di dati, perché ognuno dei loro utenti scaricava nuovamente queste identiche immagini pubblicitarie, aggirando qualsiasi server di cache / proxy che il loro ISP stava operando.

Quindi è stata raggiunta una tregua: i browser inviavano sempre richieste HTTP, anche per elementi memorizzati nella cache non scaduti. I server risponderebbero con codici di stato HTTP 304 ("non modificati"). Ciò consente ai server di registrare il fatto che l'immagine è stata visualizzata al client. Di conseguenza, le reti pubblicitariein generesmesso di usare nomi di immagini casuali per bypassare i server di cache di rete.

Ciò ha fornito alle reti pubblicitarie ciò che volevano - un record di ogni immagine visualizzata - e ha fornito agli ISP ciò che volevano: immagini memorizzabili nella cache e contenuto statico.

Questo è il motivo per cui non puoi fare molto per impedire ai browser di inviare richieste HTTP per gli elementi della pagina memorizzati nella cache.

Ma se si guardano altre soluzioni lato client disponibili fornite con html5, esiste un ambito per impedire il caricamento delle risorse

  1. Manifest della cache(nonostante i suoi trucchi)
  2. IndexedDB(belle funzionalità asincrone, consente l'archiviazione BLOB)
  3. Memoria locale(non asincrono)
fonte
Translate

C'è una differenza tra "ricaricare" e "rinfrescare". La semplice navigazione in una pagina con i pulsanti Indietro e Avanti di solito non avvia nuove richieste HTTP, ma premendo specificamente F5 per "aggiornare" la pagina, il browser controllerà la sua cache. Questo dipende dal browser ma sembra essere la norma per FF e Chrome (cioè i browser che hanno la capacità di guardare facilmente il loro traffico di rete.) Premendo F6, entrare dovrebbe focalizzare la barra degli indirizzi URL e poi "andare" ad essa, che dovrebbe ricarica la pagina ma non ricontrolla le risorse nella pagina.

Aggiornare: chiarimento del comportamento di navigazione avanti e indietro. Si chiama "Back Forward Cache" oBFCachenei browser. Quando navighi con i pulsanti Indietro / Avanti, l'intento è di mostrarti esattamente com'era la pagina quando l'hai vista nella tua timeline. Non vengono effettuate richieste al server quando si utilizza avanti e indietro, anche se un'intestazione della cache del server dice che un particolare elemento è scaduto.

Se vedi (200 OK BFCache) nel pannello della rete dello sviluppatore, il server non è mai stato colpito, nemmeno per chiedere se è stato modificato da allora.

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

fonte
Translate

Se forzo un aggiornamento usando F5 o F5 + Ctrl, viene inviata una richiesta. Tuttavia, se chiudo il browser e inserisco nuovamente l'URL, NON viene inviato NESSUNA richiesta. Il modo in cui ho testato se una richiesta viene inviata o meno è stato utilizzando i punti di interruzione sulla richiesta di inizio sul server anche quando una richiesta non viene inviata, viene comunque visualizzato in Firebug come un'attesa di 7 ms, quindi attenzione.

fonte
Translate

Quello che stai descrivendo qui non riflette la mia esperienza. Se il contenuto viene servito con una direttiva no-store o esegui un aggiornamento esplicito, allora sì, mi aspetto che torni al server di origine altrimenti dovrebbe essere memorizzato nella cache durante i riavvii del browser (supponendo che sia consentito e possa scrivere un file di cache).

Guardando le tue cascate un po 'più in dettaglio (il che è complicato perché sono un po' piccole e sfocate) il browser sembra fare esattamente quello che dovrebbe:havoci per le immagini, ma si stanno solo caricandodalla cache localenon dal server di origine - controlla l'intestazione "Date" nella risposta (perché pensi che stia impiegando millisecondi invece di secondi?). Ecco perché sono colorati in modo diverso.

fonte
Translate

Dopo aver passato molto tempo a cercare una risposta ragionevole, ho trovato il link sottostante più utile e risponde alla domanda posta qui.

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

fonte
Translate

Se è una questione di vita o di morte (se vuoi ottimizzare il caricamento della pagina in questo modo o se vuoi ridurre il carico sul server il più possibile, non importa cosa), allora c'è una soluzione alternativa.

Usa HTML5memoria localeper memorizzare nella cache le immagini dopo che sono state richieste per la prima volta.

  • [+]Puoi impedire al browser di inviare richieste HTTP, che nel 99% restituirebbero 304 (non modificato), indipendentemente da quanto l'utente ci provi (F5, ctrl + F5, semplicemente rivisitare la pagina, ecc.)

  • [-]Devi fare alcuni sforzi extra nel supporto javascript per questo.

  • [-]Le immagini sono memorizzate in base64 (non possiamo memorizzare dati binari), ecco perché vengono decodificate ogni volta sul lato client. Che ègeneralmenteabbastanza veloce e non è un grosso problema, ma è ancora un po 'di utilizzo extra della CPU sul lato client e dovrebbe essere tenuto a mente.

  • [-]L'archiviazione locale è limitata. Puoi mirare a utilizzare ~ 5 MB di dati per dominio (Nota: base64 aggiunge ~ 30% alla dimensione originale dell'immagine).

  • [?]Supportato damaggioranzadei browser.http://caniuse.com/#search=localstorage

Esempio

Test

fonte
Translate

Quello che vedi in Chrome non è un record delle effettive richieste HTTP, è un record di richieste di risorse. Chrome lo fa per mostrarti che una risorsa viene effettivamente richiesta dalla pagina. Tuttavia, questo punto di vista non indica realmente se la richiesta è stata effettuata. Se una risorsa viene memorizzata nella cache, Chrome non creerà mai effettivamente la richiesta HTTP sottostante.

Puoi anche confermarlo passando con il mouse sui segmenti viola nella sequenza temporale. Le risorse memorizzate nella cache avranno l'estensione(from cache)nella descrizione comando.

Per vedere le effettive richieste HTTP, è necessario guardare a un livello inferiore. In alcuni browser questo può essere fatto con un plugin (come Live HTTP Headers).

In realtà, però, per verificare che le richieste non vengano effettivamente effettuate, è necessario controllare i log del server o utilizzare un proxy di debug come Charles o Fiddler. Funzionerà a livello HTTP per assicurarsi che le richieste non vengano effettivamente eseguite.

fonte
Translate

Convalida della cache e risposta 304

Esistono numerose situazioni in cui Internet Explorer deve verificare se una voce memorizzata nella cache è valida:

  • La voce memorizzata nella cache non ha una data di scadenza e si accede al contenuto per la prima volta in una sessione del browser

  • La voce memorizzata nella cache ha una data di scadenza ma è scaduta

  • L'utente ha richiesto un aggiornamento della pagina facendo clic sul pulsante Aggiorna o premendo F5

Se la voce memorizzata nella cache ha una data dell'ultima modifica, IE la invia nell'intestazione If-Modified-Since di un messaggio di richiesta GET:

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

Il server controlla l'intestazione If-Modified-Since e risponde di conseguenza. Se il contenuto non è stato modificato dalla data / ora specificata, risponde con un codice di stato 304 e un messaggio di risposta che contiene solo intestazioni:

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

La risposta può essere scaricata rapidamente perché non contiene contenuto e fa sì che IE legga i dati richiesti dalla cache. In effetti, è come un reindirizzamento alla cache del browser locale.

Se l'oggetto richiesto è effettivamente cambiato dalla data / ora nell'intestazione If-Modified-Since, il server risponde con un codice di stato 200 e fornisce la versione modificata della risorsa.

fonte
Translate

Questa domanda ha una risposta miglioreQuisul sito di scambio di stack dei webmaster.

Ulteriori informazioni, che sono anche citate nel link sopra, sono disponibilihttpwatch

Secondo l'articolo:

Esistono numerose situazioni in cui Internet Explorer deve verificare se una voce memorizzata nella cache è valida:

  • La voce memorizzata nella cache non ha una data di scadenza e si accede al contenuto per la prima volta in una sessione del browser
  • La voce memorizzata nella cache ha una data di scadenza ma è scaduta
  • L'utente ha richiesto un aggiornamento della pagina facendo clic sul pulsante Aggiorna o premendo F5

    inserire il codice qui

fonte
Leave a Reply
You must be logged in to post a answer.
Circa l'autore