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.