oui en l'occurence sur local/ ce serait utile, mais c'est à apache de le gerer dans ce cas.
sur IMG/ on ne pourra pas tant que les logo ont un nom invariant lors de leur modification.
Cédric
C'est un élément qui me surprends toujours et que je ne comprends pas :
pourquoi SPIP ne retourne-t-il pas d'attribut "Expires" ?
il y en a eu sur Spip 1.9, tout le monde été perdu dans le developpement de
son site a cause des cahces navigateurs etc ...
Et il fallait faire une gymnastique spéciale pour les pages
"dynamiques" ; on a préféré dire que toutes les pages sont
potentiellement dynamiques (web 2.0, sessions...), laissant la
gymnastiques à ceux qui savent que leur site est fortement statique.
C'est une option de #CACHE{} : cache-client je crois
oui en l'occurence sur local/ ce serait utile, mais c'est à apache de le
gerer dans ce cas.
Avant ça passait par spip.php?page=jquery.js
et là on pouvait tout faire.
Quel intérêt y a-t-il à préférer un cache dans local/cache_js, par
rapport au cache standard avec "Expires" ?
Pour que le "expires" fonctionne correctement il faut que le nom du
fichier change à chaque modification de contenu.
Ca explique pourquoi il pouvait y avoir quelques pb avec les caches
des pages standards.
Pour la partie jquery+plugins, on pourrait rajouter un hash des noms
des plugins, non ?
Si le problème est de passer par spip.php qui est lourd pour du simple
script qui ne changera jamais, une option est peut-être que le fichier
de cache dans local/cache_js soit un fichier php simple qui ne fait
qu'ajouter les bonnes entetes
Je suis tout à fait d'accord sauf que ça me chagrine de recharger tout
le temps un fichier dans /local/ qui pèse lourd.
YSlow indique bien que le cache de jquery+plugins n'est pas mis en
cache définitivement.
Pour ce cas précis (le reste je suis d'accord), je trouve que c'est lourd.
Je suis tout à fait d'accord sauf que ça me chagrine de recharger tout
le temps un fichier dans /local/ qui pèse lourd.
YSlow indique bien que le cache de jquery+plugins n'est pas mis en
cache définitivement.
Pour ce cas précis (le reste je suis d'accord), je trouve que c'est lourd.
Dans ce cas il faut régler ton apache. Un .htaccess permet peut-être
de faire ça... le bénéfice sera sur l'ensemble des fichiers de local/
(les images typo etc).
Je peux le faire, mais je ne suis absolument pas convaincu que
l'utilisateur habituel de Spip sache le faire.
Je suis personnellement contre ce type de hack de geek car il y a
certainement des solutions qui les évitent.
Si on compare la home de spip.net/fr et celle de spip-contrib.net, on
s'aperçoit que la stratégie est différente :
- dans le premier cas c'est une version compactée de jquery + plugins
qui est appelée : 69Ko sans "expires" (donc valable que pour la
session du navigateur)
- dans le second cas, c'est les éléments détaillés : 137Ko (quand
même) avec "Expires".
YSlow indique que seul le second cas peut être pleinement intégrée
dans le cache du navigateur.
Ici la différence qu'il y a c'est uniquement un réglage Apache, en effet.
Mais on doit bien pouvoir trouver un moyen de pondre un Etag +
"Expires" en passant par du php, non ?
Bon, il reste un moyen pour retourner une page en 304 (donc avec un
contenu vide, juste l'entete) :
c'est dans assembler vers la ligne 268
Par contre dans mes tests le navigateur (Safari ou Firefox) n'envoie
JAMAIS de "if-modified-since" dans sa requête bien qu'il ait reçu
auparavant la même page avec un "Last-modified".
C'est curieux, ce morceau de code semble ne servir à rien : est-ce que
c'est spécifique au Mac ?
Je peux le faire, mais je ne suis absolument pas convaincu que
l'utilisateur habituel de Spip sache le faire.
Ben c'est à son hébergeur de le faire. Il y a un vrai coût à tout
faire passer par inc_version, c'est un constat
Si on compare la home de spip.net/fr et celle de spip-contrib.net, on
s'aperçoit que la stratégie est différente :
- dans le premier cas c'est une version compactée de jquery + plugins
qui est appelée : 69Ko sans "expires" (donc valable que pour la
session du navigateur)
sur sip.net/fr Firebug m'indique des 304 quasiment partout
Mais on doit bien pouvoir trouver un moyen de pondre un Etag +
"Expires" en passant par du php, non ?
j'imagine que dans local tu peux ajouter un .htaccess + un wrapper php
; ça n'a pas à être un "truc de geek" dans la mesure où tu peux
imaginer un plugin qui pose ces éléments pour "l'utilisateur de base".
Mais je répète, avec cette méthode, si ton serveur est correctement
paramétré, tu vas faire baisser les perfs.
Du point de vue de l'écologie générale du serveur, il est plus avantageux d'avoir un simple fichier js statique sans expire qu'un PHP avec un expire.
Les hits PHP ont un coût bien supérieur à ceux d'un fichier statique en terme de charge serveur, et la majeurs partie des visiteurs ne voyant qu'une ou deux pages de ton site, le ratio de hits économisés n'est pas suffisant pour justifier un wrapper php.
C'était la démarche mise en place pour le ?page=jquery.js, je suis revenu dessus.
Il est certain que la meilleure solution est d'avoir un expire, mais cela ne peut être réalisé avantageusement que par apache.
Cédric
Je peux le faire, mais je ne suis absolument pas convaincu que
l'utilisateur habituel de Spip sache le faire.
Ben c'est à son hébergeur de le faire. Il y a un vrai coût à tout
faire passer par inc_version, c'est un constat
Si on compare la home de spip.net/fr et celle de spip-contrib.net, on
s'aperçoit que la stratégie est différente :
- dans le premier cas c'est une version compactée de jquery + plugins
qui est appelée : 69Ko sans "expires" (donc valable que pour la
session du navigateur)
sur sip.net/fr Firebug m'indique des 304 quasiment partout
Au temps pour moi :
sur ma config', Firebug n'indiquait que des 200 (et les entetes ne
contenaient pas de "if-modified-since" ou "if-none-match").
Par contre l'extension "livehttpheaders" m'indique bien les 304 pour
tous les fichiers sauf le principal, et je vois bien passer une entete
plus complete.
Curieux comme comportement,
mais je me suis fais avoir par mon outils.