Quelles sont les règles strictes et rapides pour le contrôle du cache?

Confession : les sites que je maintiens ont des règles différentes pour le contrôle du cache, principalement basées sur la configuration par défaut du serveur, suivies de recommandations des plug-ins Page Speed et Y-Slow Firefox et de la vue Network Resources dans Speed ​​Tracer de Google . Cache-Control est défini sur privé / public en fonction de ce qu'ils disent de faire, les en-têtes ETag / Last-Modified ne sont bricolés que si Y-Slow suggère qu'il y a quelque chose de mal et Vary-Accept-Encoding semble nécessaire lors de la fermeture manuelle des fichiers pour Amazon CloudFront.

En lisant le matériel sur les différentes options et ce qu'elles font, il semble y avoir des informations contradictoires, des règles pour les procurations brisées et les configurations culte du fret . Toutes les informations officielles fournies par les outils d'analyse mentionnés ci-dessus sont assez inaccessibles car elles traitent chaque sujet individuellement au lieu d'une stratégie unifiée (il n'y a donc pas de référence croisée des techniques).

Par exemple, il ne semble pas logique que les outils d'analyse de vitesse évaluent un site avec ETag comme un site sans eux s'ils sont destinés à aider à la mise en cache.

Quelles sont les règles strictes et rapides pour une stratégie de contrôle de cache agnostique de plateforme?

ÉDITER:

Un lien à travers l'article de Jeff Atwood explique Caching dans une superbe profondeur.

Pour mémoire, voici les règles strictes et rapides:

Si le fichier est compressé à l'aide de GZIP, etc. - utiliser "cache-control: private" comme proxy peut renvoyer la version compressée à un client qui ne la prend pas en charge (le cache du navigateur contiendra cependant les fichiers marqués de cette façon). N'oubliez pas non plus d'inclure un "Vary: Accept-Encoding" pour dire qu'il est compressible.

Utiliser Last-Modified en conjonction avec ETag - l'utilisation de la ceinture et des bretelles fournit les deux valideurs, tandis que ETag est basé sur le contenu du fichier au lieu du temps de modification seul, en utilisant les deux couvre toutes les bases. REMARQUE: PageTest d'AOL a une approche carte blanche contre 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é d'ETags en l'excluant de la directive FileETag (c'est-à-dire "FileETag MTime Size"), sauf si vous utilisez véritablement le même système de fichiers en direct.

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 vous débarrassez pas de l'ETag comme Yahoo le dit, sauf si vous utilisez une batterie de serveurs / cluster. Tant que le même fichier renvoie toujours le même ETag lorsqu'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 futur en- Expirestête pour les fichiers statiques, à utiliser Cache-Controlpour le contenu dynamique. Cependant, Cache-controlc'est parfaitement bien pour le contenu statique (à peu près aucune différence entre eux).

Lorsque vous modifiez des fichiers statiques mis en cache, vous devrez modifier le nom de fichier ou ajouter un paramètre unique à la fin, par exemple example.com/styles.css?v=2. Il est préférable de changer le nom de fichier réel, comme indiqué dans les commentaires ci-dessous.

Soit dit en passant, vous pouvez modifier les règles YSlow à votre convenance, 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 demande 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 aller au 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 de nombreuses 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 en savoir plus avant de le modifier.

Le code ci-dessous indique aux navigateurs ce qu'il faut mettre en cache et combien de temps pour "s'en souvenir". Il doit ê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.

Source:
https://varvy.com/pagespeed/leverage-browser-caching.html