Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear.

On peut regretter l’expiration très courte (une journée) accompagniée d’un must-revalidate, mais je me permet d’insister avec intérêt sur le Cache-Control: public très important dans le cas d’une application PHP. EzPublish utilise très probablement les sessions PHP, qui ajoutent par défaut un Cache-Control: private. il faut donc le corriger.

Dans un autre billet on voit le résultat sur le squid de la gestion du cache des images et de la compression HTTP :

Dans une seconde partie il nous parle de compression d’images. Là aussi les solutions sont connues mais c’est appréciable de voir quelqu’un le mettre en œuvre et en parler ensuite. Sur les PNG il identifie un gain moyen d’un tiers pour le poids des images. C’est plus que conséquent, et ça aura un effet visible et sur le client et sur votre infrastructure. Je me permet juste d’apporter un bémol sur l’utilisation du paramètre -brute de pngcrush, qui est loin d’être le meilleur compromis gain/temps.

Les absolus

Quoi que vous disiez, quoi que vous fassiez, si le serveur vous a répondu avec un code d’erreur 400, le navigateur devrait mettre en cache se résultat et ne pas refaire la même requête. C’est plutôt logique pour une requête que le serveur a considéré comme invalide.

Quoi que vous disiez, quoi que vous fassiez, si le code de retour était 303 ou 307, le navigateur ne devrait pas mettre en cache ce résultat. La redirection est temporaire, marquée comme telle, mettre en cache du temporaire c’est faire du permanent, donc contredire la réponse.

L’heuristique

S’il s’agit d’une requête de type GET avec un code de retour 200, 203, 206, 300, 301 ou 410, alors le navigateur ou le proxy sont encouragés à mettre en cache suivant leurs propres heuristiques. Le plus souvent la page HTML elle-même n’est pas mise en cache par défaut, mais les composants référencés par cette page sont mis en cache pour la durée de la session.

Il est à noter que la spécification HTTP 1.1 prévoit la fonctionnalité de retour arrière des navigateurs et incite le navigateur à réutiliser la page précédente sans la réactualiser, quand bien même elle aurait expiré. Le visiteur l’a déjà vu, il s’agit de lui représenter là où il était avant, pas de revenir sur la page actualisée.

L’invalidation

Quand le serveur répond à une requête POST, les versions en cache de cette URI ou de celle dans les entêtes Location ou Content-Location doivent être effacés. Ceci implique immédiatement que par défaut une requête POST ne sera pas mise en cache.

La spécification HTTP 1.1 va même un peu plus loin en prenant en compte l’usage des paramètres de requêtes dans les URI. Certains utilisent ainsi des paramètres en GET pour réaliser des actions qui devraient être faites en POST (puisque provocant un changement dans l’entité résultat). Pour y palier, HTTP 1.1 demande à ce que ces requêtes (contenant un point d’interrogation dans le chemin) ne soient pas mises en cache quand bien même elles seraient faites avec le verbe GET.

Petite note : Si vous renvoyez un document avec une entête Date inférieure à celle qu’avait eu le navigateur la dernière fois, cette réponse ne devrait être pas mise en cache.

La déclaration explicite

Maintenant, hors les premiers cas absolus, les entêtes explicites ont priorité. Une entête Cache-Control à public, private, ou no-cache change le comportement par défaut. Un max-age ou Expires impose un cache et un must-revalidate impose une revalidation, même si ces règles contredisent le comportement par défaut pour la ressource en question.

Enfin, les caches sont toujours dépendants de l’entête Vary, qui permet de restreindre le cache à un navigateur, ou des visteurs avec un certain cookie, etc.

Il s’agit d’informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n’a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d’autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément.

Les détails HTTP 1.0

En fait tout ça c’est assez simple. En HTTP 1.0, le serveur envoie avec le contenu une entête Expires avec une date au format de la RFC 1123.

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Le navigateur et les proxy stockent dans le cache la ressource avec cette date. Les prochaines fois c’est le contenu sauvegardé dans le cache qui est utilisé, sans aucun appel au serveur.

Une fois la date dépassée, le navigateur fait de nouveau appel au serveur pour obtenir un contenu mis à jour, et éventuellement une nouvelle date d’expiration explicite. C’est normalement une requête conditionnelle qui est faite à ce niveau là donc si le contenu n’a toujours pas changé il ne sera toujours pas retéléchargé inutilement.

Les détails HTTP 1.1

Le gros défaut HTTP 1.0 c’est qu’en général on ne souhaite pas une date d’expiration fixe, on cherche une expiration de type « maintenant + 10 jours ». Résultat, il faut générer la date à chaque fois.

HTTP 1.1 nous propose un mécanisme plus sympathique avec l’entête Cache-Control dont je vous avais détaillé un des paramètres il y a quelques temps. Le paramètre qui nous intéresse ici est le paramètre max-age. Il prend un nombre de secondes pendant lesquelles le contenu doit être considéré comme à jour.

Cache-Control: public;max-age=3600

Cette directive est valable autant pour les caches partagés (proxy) que les caches personnels (navigateur). Il existe toutefois un second paramètre s-maxage, qui ne cible que les caches partagés. Le fonctionnement est similaire.

J’utilise quoi ?

Autant que possible, utilisez les deux. Rien n’est parfait dans ce bas monde et vous n’avez pas de garantie que la directive Cache-Control sera interprétée correctement, même si le client utilise la version 1.1 du protocole.

En cas de conflit le client est censé utiliser la directive Cache-Control. Mais après tout, pourquoi voudriez-vous envoyer deux informations contradictoires ?

Comment ?

Le plus simple sous Apache c’est mod_expires. Vous pouvez régler le comportement par défaut et par type de fichier. À chaque fois vous pouvez définir une durée pendant laquelle le contenu est considéré comme à jour, et si cette durée est à prendre à partir de la dernière modification de votre contenu ou de la date de la requête.

ExpiresDefault "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3 minutes"

Pour Lighttpd le module a le même nom, et la syntaxe est assez similaire :

$HTTP["url"] =~ "^/images/" {
     expire.url = ( "" => "access 1 hours" )
}

Sur quoi ?

Ces entêtes sont pertinentes pour tout ce qui bouge peu, pas du tout, ou à une fréquence déterminée :

Prenez en compte au moins vos logos, vos icônes, vos images de fond, bref, ce qui ne change quasiment jamais, sans exception. Pour ces contenus vous pouvez mettre une expiration virtuellement infinie, de plusieurs années. Le jour où vous faites une modification il suffira de faire un nouveau fichier avec une nouvelle adresse publique.

Pour vos feuilles de style et vos javascript, même chose. Vos contenus changent plus souvent mais si vous arrivez à changer l’URL à chaque modification vous pouvez encore mettre une expiration quasi infinie. 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.

Enfin, les pages HTML. Là il faut être plus fin. Toutes les pages ne sont pas pertinentes pour une expiration. Plus classiquement si à deux minutes d’intervalle il est important que le contenu change, oubliez l’expiration explicite. Par contre une bonne partie des pages peuvent avoir une expiration de quelques minutes, voire d’une ou deux heures. C’est souvent le cas des pages d’accueil et des pages principales. L’utilisateur y revient souvent lors de sa navigation. Si ces pages peuvent être instantanées, c’est un réel gain pour l’utilisateur. Si vous avez un système d’authentification sur vos pages, n’oubliez pas de déclarer aussi le cache comme privé avec la directive Cache-Control.

Le bénéfice

Un contenu avec une expiration explicite c’est un contenu qu’on évite de retélécharger plusieurs fois inutilement. Pour l’utilisateur c’est la sensation que le téléchargement est instantané, que l’interface et que le site réagissent immédiatement — et n’oubliez pas, cela a une influence importante sur votre business. Pour vous c’est autant de charge en moins pour votre serveur, et autant de bande passante économisée. Rien que là dessus vous pouvez économiser des sommes importantes.

Pour exemple, la page de Yahoo! met environ deux secondes tout compris à charger avec plus de 40 requêtes HTTP, ce qui en soit est assez honorable face au reste du web. Par contre sur cette quarantaine de requêtes HTTP, plus des trois quarts ont une expiration explicite comme détaillé plus haut. Le résultat c’est que ma seconde visite ne télécharge plus que 7 composants externes. Ma bande passante est libre pour autre chose et ma page se charge bien plus rapidement. Suivant les publicités sur la page, c’est entre une demi seconde et une seconde que je gagne. Pour une page d’accueil qui ne doit surtout pas donner une impression de lenteur, c’est significatif et même important.

Visibilité et autorisation de cache

Pour faire court, cette directive contient quatre paramètres de visibilité : public, private, no-cache et no-store.

• La valeur no-cache est assez simple : Les navigateurs et proxys ne doivent pas réutiliser le document reçu sans faire une nouvelle validation sur le serveur.
• La valeur private impose aux cache partagés (les proxys) de ne pas mettre en cache la page, mais autorise les caches privés (navigateurs) à utiliser un cache sur le document.
• La valeur public autorise explicitement le cache quel que soit les autres paramètres et le comportement normal sur ce document.
• Enfin, la valeur no-store demande aux caches de ne stocker le message ni de manière permanente ni en mémoire volatile.

Les subtilités

On a l’impression d’une simple hiérarchie qui va de « pas de cache » à « cache partout » en passant par l’intermédiaire « cache privé ». Malheureusement les détails sont plus complexes que ça.

Le serveur proxy de votre entreprise pourra accélérer le téléchargement d’un document en no-cache. L’astuce c’est que contrairement à ce que le nom laisse entendre, le cache n’est pas interdit. On impose juste au serveur de revalider le document avec une requête conditionnelle if-modified-since ou if-none-match. Le document sera quand même dans le cache partagé, et si vous gérez mal les requêtes conditionnelles il pourra être partagé entre plusieurs utilisateurs différents. À l’inverse, un document marqué comme private ne pourra pas, lui, être accéléré par le proxy partagé car c’est directement la notion de cache qui y est prohibée. Troublant non ?

C’est no-store qui interdit le stockage, que ce soit sur disque ou en mémoire (et empêche donc les requêtes conditionnelles par la suite). Par contre ce no-store n’interdit pas formellement le cache. Si un proxy recevait une seconde requête similaire avant de recevoir la réponse à la première, il pourrait techniquement servir la même réponse aux deux clients tout en se conformant aux spécifications. Bref, on ne peut pas stocker mais on peut toujours partager les réponses sur un proxy commun. Je doute qu’un seul proxy sur le marché fasse de telles optimisations qui « sonnent faux », mais à défaut c’est un Cache-Control: no-cache, no-store qu’il faut utiliser (oui, on peut cumuler).

La valeur public pose moins de contre-sens mais cela ne veut pas dire qu’elle soit forcément bien comprise elle aussi. Elle n’implique pas uniquement que le document est public, donc potentiellement mis en cache partout. Cette valeur autorise aussi un cache là où il n’aurait pas été autorisé autrement. Ainsi une requête POST avec un résultat public pourra utiliser le cache. Votre formulaire de contact est public, vous avez réglé naïvement le Cache-Control à public (après tout, il n’est pas privé ce formulaire), et voilà que si deux personnes utilisent le formulaire à partir de la même entreprise le second aura le message de confirmation mais son message ne sera pas envoyé. Gênant non ? Même chose si vous mettez en place une authentification HTTP cumulée avec un Cache-Control: public, vous risquez d’avoir des utilisateurs non autorisés sur le site.

Bref, pas grand chose d’intuitif et il faut faire attention aux détails.

D’autres problèmes

Du coup, conséquence directe de ces subtilités, la valeur par défaut n’est ni public, ni private, ni no-cache et encore moins no-store. Par défaut il n’y a rien et on ne peut rien préciser pour forcer explicitement le comportement « sain » par défaut.

C’est d’autant plus gênant avec PHP. Ce dernier ajoute automatiquement un Cache-Control: no-cache à toutes les réponses si une session est utilisée sur la page. Les frameworks modernes en PHP ouvrent la session par défaut, la conséquence c’est que toutes les pages sont d’un coup interdites de partage, même les pages publiques. Il ne vous reste plus qu’à réécrire manuellement les entêtes Cache-Control, Pragma et Expires (oui, les trois, PHP ne fait pas dans la dentelle). PHP mérite un billet à part entière, donc je ne m’étendrai pas plus dessus pour l’instant.

Pour ne rien arranger Microsoft Internet Explorer a un problème avec le téléchargement de certains fichiers sur HTTPS quand le Cache-Control est à no-cache ou no-store (il interprête les deux de la même façon, traitant no-cache comme un no-store). Il refuse alors le stockage temporaire du fichier et ne permet donc pas son ouverture avec une application tierce (traitement de texte par exemple). Bref, même si c’est malheureux pour l’efficacité des proxy, il vaut souvent mieux cumuler un Cache-Control: private avec un paramètre tiers pour forcer la revalidation que d’utiliser no-cache. Et pour ceux qui suivent bien ça veut dire que télécharger une pièce jointe via https à partir d’une application PHP qui utilise les sessions, ça posera un problème si vous ne bidouillez pas session_cache_limiter().

Rapidement

Pour récapituler, la règle de base c’est donc : ne rien préciser sur les parties publiques du site et indiquer private sur les parties privées (et uniquement celles ci car ça désactive tous les proxys partagés).

La valeur public est à éviter ou utiliser avec précautions car elle risque de mettre en cache des requêtes qui ne le devraient pas ; la valeur no-cache permettra à vos documents privés de se retrouver sur des caches partagés tout en posant des problèmes pour les téléchargements de fichiers par HTTPS, et la valeur no-store ne garantit pas l’absence de cache commun tout en ayant les mêmes problèmes de téléchargement.

Plus loin

En allant un peu plus loin on peut même voir que le private et le no-cache peuvent avoir un paramètre. Il s’agit de définir précisément quel champ de la réponse ou de la requête doit être considéré comme privé ou ne doit pas être mis en cache. Je n’ai jamais vu ces paramètres utilisés et je ne vois pas comment ils pourraient l’être (pour revalider un des champs il faut de fait relancer toute la requête donc ça revient à appliquer le private ou le no-cache sur l’ensemble du message). Si quelqu’un voit comment ça pourrait être utilisé, qu’il n’hésite pas à commenter.