Accéder au contenu principal

Optimiser son site en maitrisant sa mise en cache

Précédemment dans notre quête de la performance, nous avions vu qu'à l'aide de quelques consignes données à notre serveur, nous pouvons alléger la quantité de données reçues par nos visiteurs sans les altérer.

Poursuivons le raisonnement. Plutôt que d'alléger les données, posons-nous la question : mon visiteur a t-il vraiment besoin de recevoir cette donnée ?
Le principe du cache navigateur est de stocker sur le disque dur du visiteur les composants de pages (images, scripts, page HTML), pour ne pas avoir à les recharger plus tard.



Le cache n'a généralement pas une très bonne réputation : il est plus connu pour ses méfaits que pour ses avantages ("ça ne s'affiche pas chez toi ? c'est un problème de cache !"), et n'est pas le meilleur ami de la vie privée.
En revanche, pour le webmaster, maitriser la cachabilité de ses éléments de page est essentielle dans l'optique d'améliorer les performances de son site.
Bien géré, il ne doit pas causer de problème et doit profiter à vos visiteurs en toute transparence.

Le test qui parle

Prenons l'exemple d'un portail assez chargé, yahoo.fr.

Chargement de yahoo.fr cache vide : 58 requêtes HTTP, 531 Ko
Chargement de yahoo.fr avec cache rempli :17 requêtes HTTP, 46 Ko

Une économie de 90% de données transmises !

Les statuts HTTP sont nos amis

Lorsque le navigateur de l'internaute détecte un élément de page dans le code HTML renvoyé, voici comment il le traite dans le cas le plus général :
  • L'élément existe en cache :


    • Il n'a pas expiré
      il lit directement le fichier sur le disque sans aucun échange avec le serveur

    •  Il a expiré...

      ... et n'a pas été modifié depuis le dernier accès
        il n'a pas besoin de le télécharger à nouveau donc lit le fichier sur disque

      ... et a été modifié depuis le dernier accès
      il doit le télécharger à nouveau

  • L'élément n'existe pas en cache
    il le télécharge
Lorsque l'élément en cache n'a pas été modifié, le serveur retourne un statut HTTP 304 Not Modified. Quand il doit être téléchargé ou re-téléchargé, il renvoie un statut 200 OK.
Les 3 situations sont décrites dans le schéma ci-dessous, mettant en évidence les gains de performance.


Remarque : résolution DNS, établissement de la connexion TCP/IP et temps CPU client/serveur ne sont pas représentés.

Mise en œuvre du cache

Pour gagner du temps, il faut donc éviter à ses visiteurs d'avoir à retélécharger des éléments qu'ils possédent déjà. Images, scripts, CSS, sont tant d'éléments statiques que vous ne modifiez pas tous les jours. Favorisez leur mise en cache et vous serez doublement gagnant : en bande passante côté serveur, en performance de page côté client.

Sous Apache, le mod_expires (http://httpd.apache.org/docs/2.0/mod/mod_expires.html) nous permet de paramétrer la cachabilité des éléments de page.

Les directives ExpiresDefault et ExpiresByType offrent une grande souplesse dans la mise en oeuvre du cache, tant dans leur forme que dans leur fonction.

Quelques exemples:

Expiration après 5 jours en cache pour toutes les images
ExpiresDefault A432000 # A pour accès - 432000 sec = 5 jours

équivaut à
ExpiresDefault  "access plus 5 days"

Expiration des feuilles de style un mois après leur modification
ExpiresDefault M2592000 # M pour modification

Expiration des scripts javascript 10 jours après accès
ExpiresByType  text/javascript "access plus 10 days"

Expiration des contenus flash 1 mois après accès
ExpiresByType  application/x-shockwave-flash "access plus 1 month"

Plus plus d'informations, consultez la documentation sur ExpiresDefault et ExpiresByType.

Voici un extrait de fichier .htaccess que j'utilise sur mes sites :

<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault A3600
ExpiresByType image/png A864000
ExpiresByType image/gif A864000
ExpiresByType image/jpeg A864000
ExpiresByType image/jpeg A864000
ExpiresByType text/css A259200
ExpiresByType image/x-icon A4320000
ExpiresByType text/javascript A864000
ExpiresByType application/x-javascript A864000
</ifmodule>

Maitriser la mise à jour de ses éléments


A ce stade, il serait dommage que le cache se transforme en source de problème. Car, il vous a rendu bien des services pendant des mois, mais aujourd'hui vous publiez un joli logo spécial Noël et vous aimeriez bien qu'il s'affiche dès maintenant pour tous les visiteurs.

Côté cache, un élément de page est identifié par son URL. Votre logo actuel est donc reconnu par son adresse complète : http://www.monsite.com/logo.jpg.
Si votre nouveau logo a la même adresse que l'actuel, vous pouvez parier que tous vos visiteurs ne verront pas tous le même logo. Pas génial.

Pour contourner ce problème, donnez à votre nouveau logo une URL qui lui est propre, par exemple : http://www.monsite.com/logo-noel2010.jpg.

Aucun de vos visiteurs n'ayant déjà téléchargé cette ressource, vous serez certain que tous la verront dès sa mise en ligne.

Bien sûr, cet exemple est simple et s'opère chirurgicalement. Pour un site de taille conséquente, l'opération peut s'avérer plus délicate (dans quelle pages et fonctions ce contenu est-il appelé ?). Voici quelques conseils à suivre :
  • Structurez votre code en ayant la mise en cache à l'esprit dès le départ
  • Evitez les inclusions dispersées de scripts CSS ou JS, mais centralisez-les, voire mettez-les en fonction
  • Pour le nommage des fichiers cachables, rajouter un versionnement (compte, date) identifiant de manière unique une ressource. Exemple : style.20100611.css
Un peu d'ordre dans votre code, quelques ligne dans un .htaccess et vous aurez une maitrise parfaite de votre cache.

Commentaires

  1. Le changement de nom de fichier n a aucun effet sous safari avec un Mac!

    RépondreSupprimer
  2. 1fois sur 4 safari recharge kan même le cache....
    Très énervant ? Une idée ? Est ce qu un flux rss sur le serveur
    Pourrait forcer le navigateur a recharger la page?
    Ne me parler pas de balise Meta
    Et autre expires... Ça ne fonctionne pas avec safari !
    Merci pour le coup de main.... !!!

    RépondreSupprimer
  3. un début de réponse sur safari et le cache (en anglais): http://www.phpied.com/iphone-caching

    RépondreSupprimer
  4. Si je comprends bien, une page doit avoir un header 304 ? et non 200 ?

    RépondreSupprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

Les outils d'analyse de requêtes HTTP

L'analyse des échanges HTTP entre navigateur et serveur web est un bon moyen de détection des opérations les plus consommatrices en temps, soit celles qui impactent le plus le temps de chargement global d'une page.
Tour d'horizon des outils gratuits existants :
Outils en ligneD'une utilisation simple et rapide, ces outils proposent une vision synthétique des échanges à travers une chronologie précise des opérations, ainsi que le détail des requêtes et réponses HTTP. Toutefois, ils ne proposent généralement pas les mêmes options qu'un navigateur, notamment en terme de gestion de cache.
site-perf.comPingdom tools
L'analyse de ce blog par Pingdom tools
Plugins navigateurs
Ces outils s'intègrent à votre navigateur, ce qui vous permet de simuler exactement les situations de configurations de vos visiteurs.
FirefoxLe compagnon idéal est l'extension livehttpheaders, outil de capture des requêtes et réponses HTTP
Firebug propose également une analyse complète, avec une…

La compression HTTP pour accélérer vos sites

Avec les récents changements et déclarations de Google autour de la prise en compte de la performance des sites comme un éventuel futur critère de pertinence des sites, les problématiques d'optimisation vont (re)devenir d'actualité.

Un des moyens très rapide pour optimiser sensiblement les performances de son site web consiste à compresser le flux de données qui transite entre votre serveur et le navigateur Internet de vos visiteurs.