Quand les navigateurs effacent-ils le cache et comment puis-je utiliser davantage les 304 réponses?
J'ai un site Web avec du contenu qui change fréquemment.
J'aimerais bénéficier d'une bonne mise en cache lorsque cela ne change pas (utiliser idéalement un en-tête Cache-Control plus long), mais également m'assurer que les informations les plus récentes sont utilisées (afin que l'idéal soit d'utiliser un en-tête Cache-Control plus court). . Ceux-ci sont évidemment en conflit.
La mise en cache des données présente deux avantages:
Réduisez tous les appels et utilisez la version directement à partir du cache (si la ressource est utilisée dans le laps de temps de l'en-tête de contrôle du cache).
Use 304 - Not Modified en réponse à une demande de contenu expiré dont il s'avère qu'il s'agit toujours de la dernière version et qui se trouve toujours dans la mémoire cache du navigateur (en fonction de l'en-tête ETag ou Last-Modified de la demande). Cela signifie tout de même que vous devez demander les données et recevoir une réponse 304, ce qui signifie un aller-retour et des problèmes de latence (il ne faut pas sous-estimer la performance!), Donc pas aussi bon que la première option, mais économisez au moins sur la téléchargement complet et vous assure d'avoir la dernière version.
Donc mes questions sont:
Lorsqu'une page ou un contenu HTML (CSS, JavaScript, images, polices, etc.) est expiré après le temps de son en-tête de contrôle du cache, combien de temps les navigateurs conservent-ils le contenu pour utiliser 304 réponses?
Est-ce que je peux faire quelque chose au niveau du serveur ou de l'application pour garantir que les données sont disponibles pour 304 réponses plus longtemps? C'est à dire. Est-il possible de garder les données en cache dans le navigateur pendant une longue période (par exemple 30 jours) mais de les redemander dans un délai beaucoup plus court (par exemple après 3 heures) pour bénéficier de 304 réponses supplémentaires? Je ne pense pas qu'il existe des en-têtes HTTP "conserver en cache", autres que l'en-tête Cache-Control que je ne peux utiliser que pendant une courte période, alors devinez-vous que cela est uniquement dû à la mise en oeuvre du navigateur? Je suppose que les navigateurs vident périodiquement leur cache de données périmées pour limiter l'utilisation du disque et me demandent si j'ai une influence sur les ressources de mon site Web que je suis heureux de nettoyer de manière plus agressive et que je préférerais conseiller au navigateur. rester plus longtemps dans l’espoir qu’un 304 puisse être utilisé plus tard.
P.S. Je suis conscient que vous pouvez ajouter un horodatage ou un autre code unique au nom de fichier, ainsi qu’un long en-tête de contrôle du cache, et mettre à jour cette partie unique lors du changement de fichier pour obtenir ce que je veux. Cela signifie que, pour le navigateur, cela ressemble à une nouvelle ressource et est donc récupéré. Cependant, pour diverses raisons, ce n’est pas toujours le plus simple à implémenter (et ne peut pas être effectué sur la page par défaut "index.html" sans redirection côté serveur).
Lorsqu'une page ou un contenu HTML (CSS, JavaScript, images, polices, etc.) est expiré après le temps de son en-tête de contrôle du cache, combien de temps les navigateurs conservent-ils le contenu pour utiliser 304 réponses?
Bien que les navigateurs puissent conserver le contenu stocké sur le disque dans un répertoire temporaire ou cache au-delà de la date/heure d'expiration, le navigateur le considérera comme obsolète (non "frais"), y référera toujours et le revalidera avant de tenter de le re-télécharger le fichier. Malheureusement, la spécification ne couvre pas la manière dont les navigateurs doivent traiter les fichiers arrivés à expiration, et le nettoyage réel des fichiers sur le disque dépendra du navigateur et des préférences de l'utilisateur (comme une limite d'espace disque des fichiers mis en cache) et peut varier le navigateur est fermé.
Mark Amery a écrit une excellente réponse ( cache du navigateur - demande qui retourne 304 ) qui, tout en répondant à une question différente, explique clairement et avec précision la relation entre les réponses HTTP 304 et le comportement de mise en cache du navigateur.
Est-ce que je peux faire quelque chose au niveau du serveur ou de l'application pour garantir que les données sont disponibles pour 304 réponses plus longtemps? C'est à dire. Est-il possible de garder les données en cache dans le navigateur pendant une longue période (par exemple 30 jours) mais de les redemander dans un délai beaucoup plus court (par exemple après 3 heures) pour bénéficier de 304 réponses supplémentaires? Je ne pense pas qu'il existe des en-têtes HTTP "conserver en cache", autres que l'en-tête Cache-Control que je ne peux utiliser que pendant une courte période, alors devinez-vous que cela est uniquement dû à la mise en oeuvre du navigateur?
Je suggérerais simplement de spécifier un Cache-Control: public, max-age=1080, must-revalidate (18 minutes de votre commentaire) et le navigateur revalidera certainement le contenu après cette heure, mais pourra également, à sa discrétion, revalider pendant ce temps ou lorsqu'un utilisateur clique sur rafraîchir pour recharger une feuille.
Si vous le souhaitez vraiment, vous pouvez également essayer d'utiliser la correspondance ETag avec un hachage MD5 plutôt que de vérifier la date/l'heure de la dernière modification pour vous assurer que les fichiers ne sont pas téléchargés à nouveau, sauf si le contenu du fichier a été modifié. Il peut y avoir un léger problème de performances en calculant des ETag pour chaque requête si vous obtenez beaucoup de trafic, et de nombreuses personnes s’opposent à cette méthode, que ce soit pour une légère dégradation des performances ou parce que de nombreuses personnes ne le configurent pas pour utiliser MD5 (vous aurez d'utiliser un script côté serveur pour cela), il ne présenterait aucun avantage réel par rapport à la dernière vérification de la date/heure modifiée et pourrait se comporter de manière erratique lorsque les fichiers sont distribués à partir de plusieurs serveurs. Ceci dit, une comparaison ETag combinée à des délais d’expiration longs peut aider à réduire le nombre de téléchargements de fichiers requis. Avant de configurer des ETags, assurez-vous que la configuration de votre serveur Web est configurée pour utiliser des connexions persistantes afin que les demandes puissent être reliées très rapidement en une seule connexion plutôt que de nécessiter plusieurs connexions, car tous les navigateurs modernes utilisent ce type de connexion. ceci si votre serveur est configuré pour cela.
Je suppose que les navigateurs vident périodiquement leur cache de données périmées pour limiter l'utilisation du disque et me demandent si j'ai une influence sur les ressources de mon site Web que je suis heureux de nettoyer de manière plus agressive et que je préférerais conseiller au navigateur. rester plus longtemps dans l’espoir qu’un 304 puisse être utilisé plus tard.
Vous pouvez en effet spécifier un temps de cache différent pour différentes ressources de votre site Web. Par exemple, si vous avez un sous-dossier (par exemple, lib ) dans lequel vous stockez des bibliothèques/codes tiers tels que jQuery, requireJS ou FontAwesome pour Par exemple, vous pouvez alors inclure la version dans le nom du dossier (par exemple, http://www.example.com/lib/fontawesome-4.3.0/), puis définir le temps de cache maximal ou au moins très long pour tout ce qui se trouve dans ce lib car vous ne ferez pas de modifications directement dans les fichiers/codes tiers, et les versions futures seraient introduites dans de nouveaux dossiers avec le nom de la version inclus. Ressources statiques (. Js, . Css, . Jpg, . Png etc) qui sont utilisés pour votre modèle de site Web et qui peuvent changer de temps en temps peuvent avoir un temps de cache plus court.
# Cache third party files for 1 year (31536000 seconds)
<Directory "/var/www/public_html/lib">
<IfModule mod_expires.c>
Header set Cache-control max-age=31536000
</IfModule>
</Directory>
# Cache template files for 1 day (86400 seconds)
<Directory "/var/www/public_html/tpl">
<IfModule mod_expires.c>
Header set Cache-control max-age=86400
</IfModule>
</Directory>
P.S. Je suis conscient que vous pouvez ajouter un horodatage ou un autre code unique au nom de fichier, ainsi qu’un long en-tête de contrôle du cache, et mettre à jour cette partie unique lors du changement de fichier pour obtenir ce que je veux. Cela signifie que, pour le navigateur, cela ressemble à une nouvelle ressource et est donc récupéré. Cependant, pour diverses raisons, ce n’est pas toujours le plus simple à implémenter (et ne peut pas être effectué sur la page par défaut "index.html" sans redirection côté serveur).
Vous avez tout à fait raison. Celles-ci ne sont pas faciles à mettre en œuvre de manière efficace et nécessitent beaucoup plus d'effort/de code que l'utilisation des en-têtes de protocole HTTP comme prévu. Le seul scénario que je connaisse dans lequel ce type de solution est parfois préféré concerne les logiciels multiplateformes, tels que les systèmes de gestion de contenu, dans lesquels ils souhaitent prendre en charge de manière cohérente tous les environnements de serveur Web. Par exemple, si leur logiciel a été écrit en PHP, ils pourraient implémenter une solution qui peut être entièrement réalisée en PHP plutôt que d'utiliser des règles .htaccess.
Ajouté le 4 juin 2015:
En ce qui concerne le comportement du navigateur des fichiers en cache expirés ("obsolètes"):
"Une réponse stockée est considérée comme" fraîche ", comme défini dans la section 4.2, si la réponse peut être réutilisée sans" validation "(vérification auprès du serveur d'origine pour savoir si la réponse mise en cache reste valide pour cette demande). réduisez à la fois la latence et la surcharge du réseau à chaque fois qu'elle est réutilisée. Lorsqu'une réponse en cache n'est pas fraîche, elle peut quand même être réutilisée si elle peut être rafraîchie par validation (chapitre 4.3) ou si l'origine n'est pas disponible (chapitre 4.2.4). "
Source: RFC 7234: Mise en cache HTTP , dernier paragraphe de l'introduction.
En ce qui concerne le comportement de la directive must-revalidate:
"La directive de réponse" must-revalidate "indique qu'une fois qu'il est devenu obsolète, un cache NE DOIT PAS utiliser la réponse pour satisfaire les demandes suivantes sans validation réussie sur le serveur Origin."
Source: RFC 7234: mise en cache HTTP , 5.2.2.1. doit-revalider.
Lorsque vous traitez avec des pages statiques (telles que des fichiers avec les extensions html), la configuration des en-têtes ne peut être appliquée qu'aux fichiers de configuration du serveur et, en fonction du serveur, les options de configuration peuvent être limitées.
Pour plus de flexibilité sans perturber le serveur, utilisez un langage de script côté serveur tel que PHP.
En outre, pour le contrôle du cache, vous souhaitez utiliser l'option "must-revalidate" afin que, lorsque le cache expire, le navigateur revérifie le serveur pour la ressource requise.
En ce qui concerne le 304, lorsque le navigateur demande à nouveau la ressource, il attribue une valeur à une variable d'environnement de serveur if-modified-since ou if-none-match selon que vous utilisez l'en-tête eTags ou modifié en dernier. Le serveur (ou le script exécuté par le serveur) émet ensuite un message 304 s'il estime que la variable contient les données requises. Recherchez si-modifié-depuis et si-aucun-correspondance sur google, et il y aura plus de détails sur la façon dont ceux-ci fonctionnent.