Chiedere ai browser di eseguire il cache nel modo più aggressivo possibile

Question

Si tratta di un'app Web che serve le immagini. Poiché la stessa richiesta restituirà sempre la stessa immagine, desidero che i browser che accedono memorizzino le immagini nel modo più aggressivo possibile. Voglio quasi dirlo al browser

Ecco la tua immagine. Vai avanti e tienilo; non cambierà davvero per i prossimi due giorni. Non c'è bisogno di tornare indietro. Veramente. Lo prometto.

faccio io, finora, impostare

Cache-Control: public, max-age=86400 
Last-Modified: (some time ago) 
Expires: (two days from now)

e, naturalmente, restituire un 304 not modified se la richiesta ha il If-Modified-Since intestazione appropriata.

C'è altro che posso fare (o qualcosa che dovrei fare in modo diverso) per trasmettere il mio messaggio ai browser?

L'app è ospitata su Google App Engine, nel caso ciò sia importante.

Answer 1

Potreste essere interessati a verificare il seguente articolo di Google Code:

• Optimize caching: Leverage browser caching

In poche parole, tutti i browser moderni dovrebbero essere in grado di memorizzare nella cache le immagini in modo appropriato secondo le istruzioni, con quelli Intestazioni HTTP

Answer 2

Prova .htaccess come

<ifmodule mod_gzip.c> 
    mod_gzip_on Yes 
    mod_gzip_dechunk Yes 
    mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$ 
    mod_gzip_item_include handler ^cgi-script$ 
    mod_gzip_item_include mime ^text/.* 
    mod_gzip_item_include mime ^application/x-javascript.* 
    mod_gzip_item_exclude mime ^image/.* 
    mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* 
</ifmodule> 

<ifmodule mod_deflate.c> 
AddType application/x-compress .Z 
AddType application/x-gzip .gz .tgz 
AddType application/x-httpd-php .php 
AddType application/x-httpd-php .php3 
AddOutputFilterByType DEFLATE text/html 
AddOutputFilterByType DEFLATE text/plain 
AddOutputFilterByType DEFLATE text/xml 
AddOutputFilterByType DEFLATE application/x-httpd-php 
AddOutputFilterByType DEFLATE application/x-javascript 
</ifmodule> 

<ifmodule mod_expires.c> 
    ExpiresActive On 
    ExpiresDefault "access plus 1 seconds" 
    ExpiresByType text/html "access plus 1 seconds" 
    ExpiresByType image/gif "access plus 2592000 seconds" 
    ExpiresByType image/jpeg "access plus 2592000 seconds" 
    ExpiresByType image/png "access plus 2592000 seconds" 
    ExpiresByType text/css "access plus 604800 seconds" 
    ExpiresByType text/javascript "access plus 216000 seconds" 
    ExpiresByType application/x-javascript "access plus 216000 seconds" 
</ifmodule> 

<ifmodule mod_headers.c> 
    <filesMatch "\\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$"> 
    Header set Cache-Control "max-age=2592000, public" 
    </filesmatch> 
    <filesMatch "\\.(css)$"> 
    Header set Cache-Control "max-age=604800, public" 
    </filesmatch> 
    <filesMatch "\\.(js)$"> 
    Header set Cache-Control "max-age=216000, private" 
    </filesmatch> 
    <filesMatch "\\.(xml|txt)$"> 
    Header set Cache-Control "max-age=216000, public, must-revalidate" 
    </filesmatch> 
    <filesMatch "\\.(html|htm|php)$"> 
    Header set Cache-Control "max-age=1, private, must-revalidate" 
    </filesmatch> 
</ifmodule> 

Answer 3

Si può fare di meglio. 304 sono ancora una richiesta/risposta HTTP. Sebbene l'immagine non venga scaricata di nuovo, la latenza può essere letale.

Se è possibile includere un identificativo della versione nei nomi delle immagini, è possibile impostare il max-age a 2 anni. In questo modo, prevedi 304s. Se l'immagine cambia, aggiorna l'identificativo della versione cambiando il nome del file. Ciò garantisce che il browser invierà una nuova richiesta.

Ha bisogno di alcune modifiche alla struttura del progetto. L'identificativo della versione può essere il numero di revisione SVN al momento dell'ultimo aggiornamento dell'immagine e può essere generato automaticamente al momento della compilazione. Dovresti anche aggiornare l'html, quindi se hai una mappatura logica tra il nome dell'immagine e il percorso dell'immagine, il tuo lavoro sarebbe più semplice.

immagini sono raramente aggiornati, così si potrebbe anche seguire un approccio manuale, se non è possibile automatizzare quello che ho descritto sopra. Il trucco è aggiungere solo nuove immagini, mai modificarle.

Answer 4

V'è un valore molto importante sul colpo di testa di cache che non ho menzionato qui:

"post-check = 900, pre-check = 3600"

Leggi questo articolo su questo argomento (e la ricerca di più):

http://www.rdlt.com/cache-control-post-check-pre-check.html

Answer 5

non so ° Aiuterà oltre le soluzioni offerte da altri, ma è possibile utilizzare le strutture HTML5 offline web apps per chiedere esplicitamente al browser di memorizzare una copia locale.

Answer 6

È potrebbe aggiungere un ETag rappresentazione per ogni immagine e poi confrontarlo con il If-None-Match intestazione richieste in entrata (vedi "Why isn’t my custom delivered image caching in the browser?"). Questo è ridondante quando si utilizza l'intestazione Last-Modified preferita ed è comunque un altro modo di dire 304. (Penso che GAE lo faccia automaticamente per i file statici, non è sicuro.)

Gravatar imposta date molto vecchie Last-Modified - il valore predefinito sembra essere "Mer, 11 gennaio 1984 08:00:00 GMT". La scadenza di 5 minuti induce i browser a controllare frequentemente le immagini aggiornate. In altre parole, penso che stiano invitando 304, non tentando di convincere i browser ad usare solo la cache locale. Intestazioni simile a questa:

Date: Sat, 20 Mar 2010 07:52:43 GMT 
Last-Modified: Wed, 11 Jan 1984 08:00:00 GMT 
Expires: Sat, 20 Mar 2010 07:57:43 GMT 
Cache-Control: max-age=300 

La grande differenza è il tempo di scadenza - si desidera che due giorni, vogliono cinque minuti. Quindi, se vuoi che i browser utilizzino l'immagine memorizzata nella cache per 48 ore, fai ciò che stai facendo, imposta solo Cache-Control: max-age=172800 (86400 in 24 ore).

Answer 7

Alcuni giorni età cache è molto bassa. Dovresti impostarlo su un anno o anche più. Naturalmente questo potrebbe sollevare problemi quando l'immagine cambia in realtà, ma si può risolvere che con l'aggiunta di un numero di versione per l'immagine e cambiare la pagina che fa riferimento l'immagine per includere il percorso per la nuova immagine.

ho scritto più su applicazioni Web caching qui: http://patchlog.com/web/7-methods-to-cache-web-applications/