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.
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 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.
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
équivaut à
Expiration des feuilles de style un mois après leur modification
Expiration des scripts javascript 10 jours après accès
Expiration des contenus flash 1 mois après accès
Plus plus d'informations, consultez la documentation sur ExpiresDefault et ExpiresByType.
Voici un extrait de fichier .htaccess que j'utilise sur mes sites :
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 :
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
- Il n'a pas expiré
- L'élément n'existe pas en cache
il le télécharge
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
Le changement de nom de fichier n a aucun effet sous safari avec un Mac!
RépondreSupprimer1fois sur 4 safari recharge kan même le cache....
RépondreSupprimerTrè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.... !!!
un début de réponse sur safari et le cache (en anglais): http://www.phpied.com/iphone-caching
RépondreSupprimerMerci pour ces conseils
RépondreSupprimerSi je comprends bien, une page doit avoir un header 304 ? et non 200 ?
RépondreSupprimer