18041 sujets

Questions générales et questions de débutants

Gestion du cache

Bonjour à tous

Un des sites que je gère a des centaines de pages qui font référence à quelques fichiers .css et .js qui assurent la présentation et l'automatisation des actions
Lorsque je suis amené à modifier l'un ou l'autre de ces fichiers, il est souvent nécessaire de vider manuellement le cache du navigateur pour que les nouvelles versions soient prises en compte.
En ce qui me concerne, ce n'est pas un problème mais, une fois que j'ai mis au point les modifications et que je les mets sur le site de production, je ne suis jamais sûr que les utilisateurs vont bien disposer de la nouvelle version.

Il y avait jadis une norme HTTP qui disait que le client et le serveur doivent établir un dialogue pour savoir si un fichier devait ou non être rechargé. Je constate que ce dialogue n'est pas systématique.

Si on recherche sur Internet des infos à ce sujet on trouve des flopées de pages expliquant comment faire pour que les fichiers NE SOIENT PAS rechargés, quelques unes expliquant (de façon très peu claire) comment dire qu'une page n'est valable que pendant un certain temps, mais je n'ai rien trouvé pour le moment expliquant comment assurer que les navigateurs disposent effectivement de la version la plus récente du fichier.

Auriez vous de l'information à partager à ce sujet?
Merci de votre aide
Tu peux utiliser les hash de webpack. Par exemple app.js deviendra en production app.(un code long).js ce qui fera que vu que le nom du fichier est modifié, le navigateur est forcé de prendre CE fichier vu qu'il y en a pas d'autres ...
Oui, c'est la solution que j'utilise dans d'autres sites qui sont dynamiquement générés par php: je suffixe les adresses de fichiers par ?date-de-modification, ce qui fait que si le fichier a changé depuis la dernière fois il n'a plus les mêmes références dans le cache.
Ici, c'est différent
Il y a plusieurs centaines de pages qui ont dans leur <head> 

<link href="/common.css" rel="stylesheet" type="text/css">
<script type="text/javascript" src="/common.js"></script>

Quand je fais une modification dans l'un de ces fichiers, je ne vais pas modifier le code pour remplacer ces noms de fichier pour assurer que le navigateur fera ce qu'il est sensé faire: charger la version courante des fichiers.
Modifié par PapyJP (01 Sep 2018 - 11:55)
PapyJP a écrit :
Oui, c'est la solution que j'utilise dans d'autres sites qui sont dynamiquement générés par php: je suffixe les adresses de fichiers par ?date-de-modification, ce qui fait que si le fichier a changé depuis la dernière fois il n'a plus les mêmes références dans le cache.
Ici, c'est différent
Il y a plusieurs centaines de pages qui ont dans leur &lt;head&gt; 

&lt;link href="/common.css" rel="stylesheet" type="text/css"&gt;
&lt;script type="text/javascript" src="/common.js"&gt;&lt;/script&gt;

Quand je fais une modification dans l'un de ces fichiers, je ne vais pas modifier le code pour remplacer ces noms de fichier pour assurer que le navigateur fera ce qu'il est sensé faire: charger la version courante des fichiers.

A priori l'entête HTTP cache-control avec valeur nocache devrait couvrir le besoin.
sepecat a écrit :

A priori l'entête HTTP cache-control avec valeur nocache devrait couvrir le besoin.

Je ne crois pas
Cette en-tête dit qu'il ne faut jamais mettre les fichiers en cache.
Ce n'est pas ce que je désire: je désire qu'ils soient mis en cache mais que, conformément aux spécifications, le navigateur vérifie si le fichier a une nouvelle version avant de choisir d'utiliser ou non celle qu'il a en cache.
Le comportement des navigateurs à cet effet est bizarre:
1 J'ai fait une modification dans un fichier .js
2 Le navigateur a bien pris la nouvelle version
3 Comme il y avait quelque chose qui n'allait pas, j'ai à nouveau modifié le fichier
4 Le navigateur ne prend pas la nouvelle version en compte tant que je ne vide pas manuellement le cache
Tout se passe comme si, après avoir mis un fichier en cache, il ne faisait plus la vérification de mise à jour pendant un certain temps.
Quand tu es en plein développement, voici 3 solutions pour s'affranchir du cache du navigateur :
* Si tu utilises Chrome, ouvre l'inspecteur de code (Touche F12) il désactive le cache du navigateur. Si ce n'est pas le cas, il y a une option quelque part dans l'inspecteur.
* Pour Firefox, il y un plugin qui va bien : "Clear Cache" https://github.com/TenSoja/clear-cache. Il rajoute un bouton au tableau de bord
* solution ultime : rajoute un query à la fin du href ou du src du lien, qui varie en fonction du contenu du dossier. Par exemple la date de modif du fichier. Cela que la page HTML soit générée dynamiquement (PHP, Python, Perl, NodeJS, ...)
<script src="mon-fichier.js?n=<?php echo filemtime(__DIR__ .'/mon-petit-chemin/mon-fichier.js'); ?>></script>

Modifié par bazooka07 (01 Sep 2018 - 23:30)
PapyJP a écrit :

Je ne crois pas
Cette en-tête dit qu'il ne faut jamais mettre les fichiers en cache.
Ce n'est pas ce que je désire: je désire qu'ils soient mis en cache mais que, conformément aux spécifications, le navigateur vérifie si le fichier a une nouvelle version avant de choisir d'utiliser ou non celle qu'il a en cache.
Le comportement des navigateurs à cet effet est bizarre:
1 J'ai fait une modification dans un fichier .js
2 Le navigateur a bien pris la nouvelle version
3 Comme il y avait quelque chose qui n'allait pas, j'ai à nouveau modifié le fichier
4 Le navigateur ne prend pas la nouvelle version en compte tant que je ne vide pas manuellement le cache
Tout se passe comme si, après avoir mis un fichier en cache, il ne faisait plus la vérification de mise à jour pendant un certain temps.

Les headers HTTP offrent tout ce qu'il faut pour gérer l'envoi / renvoi du contenu HTML.
Tu devrais regarder du côté de if-modified-since par exemple...
Cet entête retourne la ressource avec un code 200 si modifiée par rapport à une date et un code 304 sinon.
D'autres options existent pour la gestion du cache.
Merci de ta réponse
Le problème c'est que maitriser l'envoi des headers HTTP il faut que l'affichage de la page passe par php de façon à générer les headers.
Si c'est du pure HTML, exempt de tout PHP, tu peux utiliser la 3ème astuce que j'ai donné.
Dans ce cas, il faudra rentrer la valeur de n à la main.
Il n'est pas nécessaire que cela soit une date. Tu peux très bien utiliser un compteur ou un numéro de version.
PapyJP a écrit :
Merci de ta réponse
Le problème c'est que maitriser l'envoi des headers HTTP il faut que l'affichage de la page passe par php de façon à générer les headers.

Tu peux également définir les headers dans le fichiers .htaccess pour certains types de ressources.
bazooka07 a écrit :
Si c'est du pure HTML, exempt de tout PHP, tu peux utiliser la 3ème astuce que j'ai donné.
Dans ce cas, il faudra rentrer la valeur de n à la main.
Il n'est pas nécessaire que cela soit une date. Tu peux très bien utiliser un compteur ou un numéro de version.

Comme je l’ai dit plus haut il y a plusieurs centaines de pages qui font référence à ces fichiers. Il n’est pas imaginable de les entrer à la main. On peut bien sûr imaginer un outil qui le fasse...
Pour revenir au fond du problème, la vraie question est "comment faire en sorte que les navigateurs fassent leur boulot correctement"?
Je suppose que solution doit être dans des commandes à mettre dans .htaccess comme le propose sepecat je vais regarder de ce côté
PapyJP a écrit :
Comme je l’ai dit plus haut il y a plusieurs centaines de pages qui font référence à ces fichiers. Il n’est pas imaginable de les entrer à la main. On peut bien sûr imaginer un outil qui le fasse...

Et c'est bien pour cela que l'on utilise des gestionnaires de taches pour les sites statiques la plupart du temps (en Node.js ou autre). Ces derniers gérant la compilation des pages html et des js, minification à la volée des ressources publiques, vérification des erreurs de scripts, etc... et bien sûr le versionning éventuel apposé sur un fichier statique.

C'est à mon sens la seule solution envisageable. En effet, laisser le travail aux navigateurs est illusoire : si le navigateur est obligé d'établir un comparatif pour vérifier qu'un fichier statique n'a pas été modifié depuis sa dernière visite on perd l'intérêt du cache.
Modifié par Olivier C (04 Sep 2018 - 11:22)
Olivier C a écrit :

En effet, laisser le travail aux navigateurs est illusoire : si le navigateur est obligé d'établir un comparatif pour vérifier qu'un fichier statique n'a pas été modifié depuis sa dernière visite on perd l'intérêt du cache.

Je ne crois pas qu'on "perde l'intérêt du cache" en faisant cette vérification, mais il certain que c'est plus rapide de ne pas la faire. C'est ce qui se passait dans les années 1995-2005.
Je ne suis tombé sur le problème que dans les années 2010, lorsque des personnes ne retrouvaient pas leur photo mise à jour dans le trombinoscope de l'association.
Depuis cette époque, les autres sites que je gère sont générés par du code PHP, je peux donc jouer sur l'adresse des fichiers référencés par <link>, src= ou href= en les suffixant par leur date de modification: si elles n'ont pas été modifiées, le navigateur les retrouve en cache, si elles l'ont été il ne les retrouve pas.
Mais ce n'est pas le cas de ce site, et jusqu'à présent nous avons faire l'impasse sur ce problème.
Si nous avons des remarques de utilisateurs, nous leur dirons de rafraichir leur cache, mais jusqu'à présent nous n'avons reçu aucune remarque.
Il est vrai que le point majeur de ce site est sa newsletter mensuelle, les gens se connectent peu entre deux parutions, et les fichiers ne doivent donc plus être dans le cache, ce qui "cache" le problème, je suppose.
Sujet clos
Aller à