Demander aux navigateurs de mettre en cache de la manière la plus agressive possible

Question

Il s'agit d'une application Web qui sert des images. Puisque la même requête retournera toujours la même image, je veux que les navigateurs accédant mettent en cache les images aussi agressivement que possible. Je veux à peu près dire au navigateur

Voici votre image. Allez-y et gardez-le. ça ne va vraiment pas changer pour les deux prochains jours. Pas besoin de revenir. Vraiment. Je promets.

que je fais, à ce jour, mis

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

et bien sûr retourner un 304 not modified si la demande a l'en-tête If-Modified-Since appropriée.

Y at-il autre chose que je puisse faire (ou quoi que ce soit que je devrais faire différemment) pour faire passer mon message dans les navigateurs?

L'application est hébergée sur Google App Engine, au cas où cela serait important.

Answer 1

Vous pouvez être intéressé à vérifier l'article Google Code suivant:

• Optimize caching: Leverage browser caching

En un mot, tous les navigateurs modernes devraient être en mesure de mettre en cache vos images de façon appropriée conformément aux instructions, avec les En-têtes HTTP.

Answer 2

.htaccess Essayez comme

<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

Vous pouvez faire mieux. Les 304 sont toujours une requête/réponse HTTP. Bien que l'image ne soit pas téléchargée à nouveau, la latence peut être fatale.

Si vous pouvez inclure un identificateur de version dans vos noms d'image, vous pouvez définir l'âge maximal sur 2 ans. De cette façon, vous empêchez 304s. Si l'image change, vous mettez à jour l'identifiant de la version, ce qui change le nom du fichier. Cela garantit que le navigateur émettra une nouvelle demande.

Il nécessite des modifications à la structure de votre projet. L'identificateur de version peut être le numéro de révision SVN lors de la dernière mise à jour de l'image et peut être généré automatiquement lors de la génération. Vous aurez également besoin de mettre à jour le code HTML, donc si vous avez un mappage logique entre le nom de l'image et le chemin de l'image, votre travail sera plus facile.

Les images étant rarement mises à jour, vous pouvez également suivre une approche manuelle si vous ne pouvez pas automatiser ce que j'ai décrit ci-dessus. L'astuce consiste à ajouter uniquement de nouvelles images, ne jamais les modifier.

Answer 4

Il est une valeur très importante en-tête de cache que vous ne l'avez pas mentionné ici:

"post-check = 900, pré-check = 3600"

Lire cet article à ce sujet (et chercher plus):

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

Answer 5

Je ne sais pas e Cela aidera au-delà des solutions proposées par d'autres, mais vous pouvez utiliser les fonctionnalités HTML5 offline web apps pour demander plus explicitement au navigateur de stocker une copie locale.

Answer 6

Vous pourrait ajouter une représentation ETag pour chaque image, puis le comparer à l'en-tête If-None-Match sur les demandes entrantes (voir « Why isn’t my custom delivered image caching in the browser? »). Ceci est redondant lorsque vous utilisez l'en-tête préféré Last-Modified et c'est juste une autre façon de dire 304 de toute façon. (Je pense que GAE le fait automatiquement pour les fichiers statiques, pas sûr cependant.)

Gravatar définit très vieux Last-Modified dates - la valeur par défaut semble être "Mer, 11 Jan 1984 08:00:00 GMT". L'expiration de 5 minutes amène les navigateurs à rechercher fréquemment des images mises à jour. En d'autres termes, je pense qu'ils invitent les 304, sans essayer de convaincre les navigateurs d'utiliser simplement le cache local. Leurs têtes ressemblent à ceci:

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 différence est la date d'expiration - vous voulez deux jours, ils veulent cinq minutes. Donc, si vous voulez que les navigateurs utilisent simplement l'image mise en cache pendant 48 heures, faites ce que vous faites, seulement Cache-Control: max-age=172800 (86400 est de 24 heures).

Answer 7

L'ancienneté de l'antémémoire de quelques jours est très faible. Vous devriez le définir à un an ou même plus. Bien sûr, cela peut poser des problèmes lorsque l'image change, mais vous pouvez résoudre ce problème en ajoutant un numéro de version à l'image et en changeant la page qui référence l'image pour inclure le chemin vers la nouvelle image.

j'ai écrit plus sur la mise en cache des applications web ici: http://patchlog.com/web/7-methods-to-cache-web-applications/