As tu un cas en ligne ?

le : header(« Cache-Control: no-cache »); ne suffit pas pour firefox

quels sont les bons paramètres ?

Tu veux bien retirer ton ifModule voir s’il te sort une erreur ? éventuellement tenter un IfModule mod_expires.c

Sinon une expiration par défaut à 24 heures ça fait finalement beaucoup. Ca veut dire que si on répond à un de tes billets, on ne verra pas son propre commentaire (ni les suivants) avant 24 heures, et que toi tu ne peux pas faire de corrections quelques minutes après la publication (et si tu es comme moi tu en as besoin à chaque fois).

Plus probablement, pour un blog :
– accueil et catégories : 10 minutes (juste histoire que ça tienne une session de navigation)
– billets récents : quelques minutes au plus, on peut se contenter de gérer les requêtes conditionnelles
– images de décoration génériques, css, javascripts : une semaine si ce n’est pas versionné dans l’url, quelques années sinon
– images de contenu dans les billets : entre 10 minutes et quelques heures (sachant que les requêtes conditionnelles prendront le relai au delà et qu’en général il n’y a pas 150 images de contenu par billet de toutes façons)
–

Je viens de découvrir que si je mets dans mon .htaccess les lignes suivantes, ça ne marche pas chez moi. Une idée ?

<IfModule mod_expires>
ExpiresActive On
ExpiresDefault « access plus 24 hours »
ExpiresByType text/javascript « access plus 30 days »
ExpiresByType text/css « access plus 30 days »
ExpiresByType image/* « access plus 30 days »

</IfModule>

Pascal

Voici mon protocole de test:

Apache 1.3.41 (compilé à la main) + PHP 4.4.9 + eZ Publish

1/ désactivation de mod_expires

2/ vidage du cache de Firefox 3.0.7

3/ Visualisation des pages de luxpopuli.fr + d’autres sites

Quand je reviens au bout d’un moment sur mon site, je visualise les en-têtes avec livehttpheaders 0.14 ou Firebug (module Réseau -> Tout)

Tu peux tester sur tout mon site, je remettrai mod_expires quand tu auras fini.

Comment faites-vous chez Yahoo! pour déterminer la proportion de visiteurs qui ont un cache vide ou pré-rempli ? Vous avez développé un logiciel ou bien est-ce en recoupant d’autres informations (taux de rebond, nombre de page par visiteur, nombre de visites inférieures à 10s, etc…) que vous faites une estimation ?

A propos des ETags, sous Apache sous 1.3 il est impossible de les désactiver. La doc offcielle dit pour l’option None que «If a document is file-based, no ETag field will be included in the response». Comme tu pourras le constater, seul mon document HTML n’est pas associé à un ETag. Tout les autres éléments si. Peut-être que j’interpète mal l’expression «file-based» ?

Cordialement,

Pascal

Par défaut le navigateur devrait utiliser la revalidation. C’est d’autant plus vrai si la directive Cache-Control contient un « must-revalidate ».

Maintenant techniquement le navigateur est habilité à mettre en cache les informations comme il le souhaite. Il a un algorithme propre pour ça, ainsi que des préférences dans le navigateur. IE 6 est connu pour parfois mettre un peu trop de choses en cache.

Parfois il y aura revalidation par requête conditionnelle, souvent, mais parfois pas. Généralement ces éléments qui sont mis en cache spontanément par le navigateur ne le sont que pendant une durée courte, ou pendant la session (en fermant/rouvrant le navigateur, il y a revalidation).

Tu as un exemple d’url à me proposer qu’on puisse regarder sur la même base ?

Sinon pour la date, c’est mis en cache à vie … sous réserve que l’utilisateur ne vide pas son cache et que jamais ce cache ne devient plein. Une fois plein, le navigateur est obligé de retirer des éléments anciens, il choisit tout seul lesquels, les tiens peuvent en faire partie.

Bref, en pratique tu donnes des instructions mais tu ne contrôles rien. Le client peut en tenir compte, ou pas.

En pratique entre ceux qui vident leurs cache, les proxys filtrant, ceux qui viennent pour la première fois et ceux qui ont un cache qui a été renouvelé, tu auras toujours une part non négligeable d’utilisateurs qui n’ont pas les éléments en cache.
Yahoo! a publié un graphique intéressant à ce sujet. Regardes la figure 3 sur http://yuiblog.com/blog/2007/01/04/performance-research-part-2/

Tout d’abord, un grand merci pour toutes les connaissances que tu prends le temps de partager.

Voilà donc ma question:

Qu’est ce que mod_expires apporte de plus que le fonctionnement par défaut du système de cache d’un navigateur ?

En effet, dans le livre de Steve Souders, on peut lire page 23 (Règle3: le champ d’en-tête Expires):
«Lors de sa première visite sur votre page, l’utilisateur exécute via son navigateur un certain nombre de requêtes HTTP. Toutefois, l’utilisation du champ d’en-tête Expires offre à vos composants la possibilité d’être mis en cache.»

Or j’ai fait des tests en m’aidant de l’extension LiveHTTPHeaders (sous Firefox 3.0.7) et ce que je n’ai pu que constater c’est que, alors que mod_expires est désactivé, tous les éléments de mes pages sont cachés par le navigateur et réutilisés à chaque nouvelle visite.
J’ai pu donc vérifier que le simple usage du système de cache du navigateur dispense ce dernier de faire d’innombrables requêtes GET conditionnelles. C’est sur la base de cette observation que je te pose ma question.

Cependant, ce comportement du navigateur soulève une autre question:
Puisqu’aucun élément caché n’est associé à une date d’expiration, comment se fait-il que le navigateur n’envoie pas de requêtes GET conditionnelles pour s’assurer qu’il n’existe pas de versions plus récentes sur le serveur ?

Dernière toute petite question:
Dans ta présentation (celle de la vidéo) tu expliques que le grand avantage de mod_expires est que les éléments statiques sont cachés «à vie» (en tout cas pour une très longue période).
Faut-il comprendre qu’un élément associé à une date d’expiration, disons en 2020, ne sera pas retiré du cache avant cette date même pour faire de la place à d’autres éléments ? Pour moi la réponse est bien sûr non, mais….

Cordialement

Pascal

Cordialement,

Pascal

Pour le protocole la plupart des clients et des serveurs utilisent la version 1.1. Certains client sont en 1.0, c’est rare mais ça arrive. Il y a une auto-négociation assez simple l le client déclare s’il veut du 1.0 ou du 1.1, le serveur répond au mieux (1.1 si le client le supporte et le serveur aussi, 1.0 sinon).

Le 1.1 c’est juste une mise à jour, avec des fonctionnalités en plus. C’est globalement compatible avec le 1.0, mais ça a quelques impacts quand même.

Encore félicitations pour ce blog, il est dans mes favoris !

Il y manquerait peut-être encore un petit billet sur les livres et les références que vous recommandez pour aller plus loin. 😉

A quand un « optimisation web – avancé » ? ^^

Bon weekend,
Sébastien

max-stale et min-fresh sont des informations envoyées par le client pour gérer les caches intermédiaires (les proxys) et éventuellement le cache applicatif.

Un serveur ou un proxy qui reçoit min-fresh=30 est informé de renvoyer une information qui date de 30 secondes au maximum et de la recalculer si besoin.

Un serveur ou un proxy qui reçoit max-stale=30 est informé qu’il a le droit de renvoyer une information qui a déjà expirée mais dont l’expiration date d’au plus 30 secondes.

Plus de détails sur la RFC HTTP : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

Excellent blog ! Bravo, très instructif ! 😉

J’aurais juste une petite question technique si vous permettez : quelles différences entre les directives « max-age » et « max-stale » de Cache-Control ?

Merci !
Sébastien

« Pour changer l’adresse à chaque version vous pouvez ajouter le numéro de version dans le nom du fichier, ou ajouter un paramètre à l’url qui contient la date de dernière modification. Je ferai un billet plus complet sur le sujet plus tard. »

est-ce que ce billet exixte? je ne l’ai pas trouvé.

Merci