Quelles sont les règles strictes pour le contrôle du cache?
Confession : les sites que je maintiens appliquent des règles différentes pour Cache Control principalement basées sur la configuration par défaut du serveur, suivies des recommandations de la Page Speed & Y-Slow Plug-ins Firefox et la vue Ressources réseau de Google Speed Tracer . Cache-Control est défini sur privé/public en fonction de ce qu'ils disent, les en-têtes d'ETag/Last-Modified ne sont modifiés que si Y-Slow suggère qu'il y a quelque chose qui ne va pas et que Vary-Accept-Encoding semble nécessaire lorsque gziper manuellement des fichiers pour Amazon CloudFront.
Lors de la lecture du matériel sur les différentes options et de ce qu'elles font, il semble y avoir des informations contradictoires, des règles pour les mandataires rompus et les configurations cargo cult . Toute information officielle fournie par les outils d'analyse mentionnés ci-dessus est tout à fait inaccessible, car elle traite chaque sujet individuellement plutôt que comme une stratégie unifiée (il n'y a donc pas de référence croisée des techniques).
Par exemple, il semble insensé que les outils d'analyse de la vitesse attribuent la même note à un site avec ETag qu'à un site sans eux s'ils sont conçus pour faciliter la mise en cache.
Quelles sont les règles absolues pour une stratégie de contrôle du cache agnostique pour les plateformes?
EDIT:
Un lien à travers article de Jeff Atwood explique Caching en profondeur.
Pour mémoire, voici les règles strictes:
Si le fichier est compressé à l'aide de GZIP, etc. - utilisez "cache-control: private" en tant que proxy pouvant renvoyer la version compressée à un client ne le faisant pas. supporte-le (le cache du navigateur contiendra les fichiers marqués de cette façon). Pensez également à inclure un "Vary: Accept-Encoding" pour indiquer qu'il est compressible.
Utiliser Last-Modified en conjonction avec ETag - l'utilisation des courroies et des accolades fournit les deux validateurs, tandis que ETag est basé sur le contenu du fichier plutôt que sur le temps de modification. couvre toutes les bases. REMARQUE: PageTest d'AOL a une carte blanche contre les balises ETags pour une raison quelconque. Si vous utilisez Apache sur plusieurs serveurs pour héberger le même contenu, supprimez l'inode implicitement déclaré de ETags en l'excluant de la directive FileETag (c'est-à-dire "FileETag MTime Size"), sauf si vous utilisez réellement le même système de fichiers live.
Utilisez "cache-control: public" partout où vous le pouvez - cela signifie que les serveurs proxy (et le cache du navigateur) renverront votre contenu même si le reste de la page nécessite une authentification HTTP, etc.
Tout d’abord, ne supprimez pas l’ETag comme le dit Yahoo, à moins d’utiliser une batterie de serveurs/cluster. Tant que le même fichier renvoie toujours le même ETag quand il n'a pas changé, c'est une directive très utile.
Comme pour les autres en-têtes, les meilleures pratiques de Yahoo suggèrent de définir un en-tête futur pour les fichiers statiques Expires, utilisez Cache-Control pour le contenu dynamique. Toutefois, Cache-control convient parfaitement au contenu statique (pratiquement pas de différence entre eux).
Lorsque vous modifiez des fichiers statiques mis en cache, vous devez modifier le nom de fichier ou ajouter un paramètre unique à la fin, par exemple. example.com/styles.css?v=2. Il est toutefois préférable de modifier le nom de fichier réel, comme indiqué dans les commentaires ci-dessous.
Incidemment, vous pouvez modifier les règles YSlow comme bon vous semble, pour supprimer la règle Etag et ajouter votre propre domaine en tant que CDN. Cet article est également une bonne lecture: Les problèmes de Yahoo ne sont pas vos problèmes
Modifier les en-têtes de requête de vos ressources pour utiliser la mise en cache Pour la plupart des gens, la mise en cache ebable consiste à ajouter du code à un fichier appelé .htaccess sur votre hôte/serveur Web.
Cela signifie que vous devez aller sur le gestionnaire de fichiers (ou partout où vous allez pour ajouter ou télécharger des fichiers) sur votre hébergeur.
Le fichier .htaccess contrôle beaucoup de choses importantes pour votre site. Si vous n'êtes pas familier avec le fichier .htaccess, veuillez lire mon article sur l'utilisation de .htaccess pour savoir comment procéder avant de le modifier.
Le code ci-dessous indique aux navigateurs ce qu'il faut mettre en cache et combien de temps pour le "mémoriser". Il devrait être ajouté en haut de votre fichier .htaccess.
## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##
Enregistrez le fichier .htaccess, puis actualisez votre page Web.
La source:
https://varvy.com/pagespeed/leverage-browser-caching.html