mise en cache côté client

Le
Olivier Masson
Bonjour,

J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.

Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et
comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et
la prise en compte par FF et IE a été curieuse : d'abord une qui change
(après un double refresh), puis l'autre après un clic de plus.

Si je mets un /far future Expires header/ sur js, css et images, que se
passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur
donner un numéro de version (dans le cadre d'un album photo, c'est ok
puisque les photos portent un nom, mais c'est autre chose pour le design) ?

Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises
que ça ralentissait pas mal le serveur et posait des problèmes (j'ai
oublié lesquels) par ailleurs.

Alors si vous avez connaissances et expériences en la matière, je prends
volontiers vos conseils :)
Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
SAM
Le #22047791
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,

J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.



Comme d'hab on rappelle :

Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et



Usuellement ça l'est.
Normalement, pour tout fichier à charger, le navigateur envoie un
questionnement à propos de la dernière modif du fichier et devrait
charger celui-là s'il est plus récent que celui en cache.

comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et



Et bien sûr ton ordi est exactement à la même heure que le serveur ?
Y a pas de cache côté serveur et des histoires de sessions ?

la prise en compte par FF et IE a été curieuse : d'abord une qui change
(après un double refresh), puis l'autre après un clic de plus.



À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en
re-validant l'url (clic dans barre adresse et touche retour) afin de
recharger la page.

Si je mets un /far future Expires header/ sur js, css et images, que se



Je sais pô c'que c'est.
Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en
cache dans le temps ?

passera-t-il si je modifie un de ces fichiers ? Il faut forcément leur
donner un numéro de version (dans le cadre d'un album photo, c'est ok
puisque les photos portent un nom, mais c'est autre chose pour le design) ?



Quoi le design ?
Les images incluses dans la feuille de style ?
à mon idée, il faut re-uploader le fichier css en plus d'avoir modifié
le design d'une image appelée par css et qui n'a pas changé de nom.

Il y a bien les E-Tag pour cela, mais j'ai lu a de multiples reprises
que ça ralentissait pas mal le serveur et posait des problèmes (j'ai
oublié lesquels) par ailleurs.



Ben alorsse si c'est pour rafraichir une image (genre pub) il y a
toujours le JS

<body onload="var i=document.getElementById('pub');
i.src = i.src+'?'+Math.random();">

<body onload="var i=document.getElementById('pub'),d = new Date();
i.src = i.src+'?'+d;">

Alors si vous avez connaissances et expériences en la matière, je prends
volontiers vos conseils :)



Comme on n'a pas essayé avec toi on a fait ce qu'on a pu ;-)

--
sm
yamo'
Le #22047781
Salut,

Olivier Masson a tapoté, le 22/10/2009 09:51:
Bonjour,

J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.

Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et




Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en
compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de
changer le nom du fichier.
Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de
fichiers, paramètre qui serait mis à jour lors de la modification d'un
fichier, j'ai l'impression que drupal6 fait ça.




--
Stéphane
On construit des maisons de fous pour faire croire à ceux
qui n'y sont pas enfermés qu'ils ont encore la raison.
-+- Michel de Montaigne -+-
SAM
Le #22047771
Le 10/22/09 11:09 AM, SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :

la prise en compte par FF et IE a été curieuse : d'abord une qui
change (après un double refresh), puis l'autre après un clic de plus.



À mon sens, au lieu d'un refresh il vaut mieux assurer le coup en
re-validant l'url (clic dans barre adresse et touche retour) afin de
recharger la page.



Ha! Ben bon ! c'est le contraire
(Firefox)

--
sm
Olivier Masson
Le #22047761
SAM a écrit :
Le 10/22/09 9:51 AM, Olivier Masson a écrit :
Bonjour,

J'ai du mal à cerner comment peut fonctionner une vraie bonne mise en
cache côté client.



Comme d'hab on rappelle :




Oui mais cette doc indique ce qui devrait se passer normalement. Et ce
que je constate ne colle pas.

Pourquoi le simple mécanisme Last-Modified n'est-il pas suffisant ? Et



Usuellement ça l'est.
Normalement, pour tout fichier à charger, le navigateur envoie un
questionnement à propos de la dernière modif du fichier et devrait
charger celui-là s'il est plus récent que celui en cache.

comment fonctionne-t-il ? Je viens de modifier 2 photos sur un site et



Et bien sûr ton ordi est exactement à la même heure que le serveur ?
Y a pas de cache côté serveur et des histoires de sessions ?




Du tout. Pas de mise en cache, pas de sessions et adresse tapée dans un
nav fraichement ouvert.
Oui, même heure (serveur ntp).
Et pourquoi il mettrait UNE photo à jour et pas l'autre ?
Même comportement sur un autre ordi (Safari Mac).

Si je mets un /far future Expires header/ sur js, css et images, que se



Je sais pô c'que c'est.
Bon ... est-ce vraiment une bonne idée de tenter de limiter la mise en
cache dans le temps ?




La doc de mnot en parle :
"If a resource (especially a downloadable file) changes, change its
name. That way, you can make it *expire far in the future*, and still
guarantee that the correct version is served; the page that links to it
is the only one that will need a short expiry time"

Et c'est la technique la plus commune (puisqu'elle fonctionne). Quand je
dis commune, je parle de sites "pro".
Je veux bien utiliser ça, mais je ne vois pas pourquoi je dois utiliser
ça plutôt qu'un Last-Modified.


Ben alorsse si c'est pour rafraichir une image (genre pub) il y a
toujours le JS



non merci :)
Olivier Masson
Le #22047741
yamo' a écrit :


Pourquoi, je ne sais pas mais, pour être sur que le navigateur prenne en
compte le nouveau fichier, le meilleur moyen que j'ai trouvé, c'est de
changer le nom du fichier.
Par exemple en ajoutant un paramètre bidon sur toutes les URL d'appel de
fichiers, paramètre qui serait mis à jour lors de la modification d'un
fichier, j'ai l'impression que drupal6 fait ça.







Oui, c'est la technique du /far future Expires header/ qui est la seule
que j'ai effectivement vu fonctionner à coup sûr.
Si Drupal le fait, c'est donc probablement que la solution classique ne
fonctionne pas ou peu (si ç'avait été joomla, je n'y aurais pas autant
cru :))
Publicité
Poster une réponse
Anonyme