bonjour,
j'ai posté dans la liste user mais à la réflexion, c'est plus judicieux dans la liste développeur
En regardant les traces apache de spip 2.1.6 (également avec spip 1.9.2 et 2.0), je me rend compte qu'il envoie systématiquement tous les fichiers css/js/jpeg même si le navigateur les possède déjà. En fouillant un peu avec l'outil redbot (http://redbot.org/?uri=http%3A%2F%2Fnew.tmlvoile.com), on se rend compte que spip renvoie systématiquement un champ last-modified à la seconde actuelle ce qui fait croire au navigateur qu'il faut tout rapatrier à nouveau. C'est quand même bien dommage de ne pas se servir du cache du navigateur pour accélérer les choses tant du coté serveur que du coté client.
J'ai quand même l'impression qu'il s'agit d'une anomalie car ce champ Last-Modified devrait être mis à jour avec la date de dernière modification du fichier le plus récent plutôt que la date courante.
Ayant un certain nombre de sites SPIP sur mon serveur et insistant pour que le plus grand nombre d'utilisateurs utilisent cette plateforme, j'éviterai une belle charge serveur et en bande passante avec un champ Last-Modified plus judicieux.
Merci de vos retours,
Bonjour,
il est normal que SPIP envoie un Last-Modified futur sur la page html, car c'est un contenu dynamique.
Pour la petite histoire, la version 1.9.2 de SPIP envoyait un Last-modified et une durée de validité correspondant au cache de la page html, afin que les navigateurs ne rechargent pas la page avant expiration du cache de SPIP.
Mais nous avons du revenir en arrière car cela posait plein de problème aux utilisateurs qui ne voyaient pas la mise a jour de leur page suite à une modification de contenu et une mise à jour anticipé du cache.
Donc le meilleur compromis s'avère être l'actuel.
En revanche, et pour optimiser le temps de chargement des page et la navigation,
il convient qu'Apache envoie les bons entête sur tous les fichiers statisques css/js et images.
Cela relève de la configuration Apache, mais nécessite aussi que SPIP ajoute un timestamp sur toutes ces ressources statiques afin de permettre leur mise a jour chez les utilisateurs en cas de modification du fichier.
En pratique, cela se traduit par une url du type
IMG/monimage.jpg?1234
ou, si la reecriture d'url est possible par le htaccess, par :
IMG/monimage.ts1234.jpg
ce qui est plus joli.
Il est déjà possible de générer tous ces timestamp dans ton squelette, et de configurer Apache pour qu'il serve les fichiers statiques avec une mise en cache d'un mois par exemple.
Ainsi, lorsqu'un visiteur parcourt plusieurs pages sur ton site, seul le html est rechargé à chaque hit + les images propres à la page en cours. Toutes les ressources statiques partagées entre les pages ne sont chargées qu'une fois.
Je travaille à automatiser ce type fonctionnement pour qu'il ne nécessite pas de modification des squelettes, mais ce n'est pas encore implémenté.
Tu peux voir ce que cela donne sur mon site.
Cédric
à nouveau. C'est quand même bien dommage de ne pas se servir du cache du
navigateur pour accélérer les choses tant du coté serveur que du coté
client.
En fait pour signaler les contenus non dynamiques, il faut ajouter la
valeur "cache-client" dans #CACHE, comme indiqué dans le code :
#CACHE{24*3600, cache-client} autorise gestion du IF_MODIFIED_SINCE
il faut vérifier que c'est bien fait dans les ?page=xxx.css
-- Fil