Le cache d’un site
La mise sous cache de votre blog WordPress est un moyen efficace de :
- alléger la bande passante
- réduire le nombre de calculs nécessaires pour faire apparaître vos pages web
- accélérer votre site.
J’ai depuis longtemps fait divers essais avec Des Geeks et des lettres, j’ai adopté un temps le plugin SuperCache mais je l’ai vite trouvé limité et j’ai essayé de lui adjoindre d’autres bouts de code afin de l’améliorer comme expliqué dans cet article. Au bout du compte tout cela apparaissait un peu comme du bricolage. Les mises à jour de WordPress nuisaient un peu à chaque fois à mes rafistolages, et le résultat m’est apparu moyennement bon.
Jusqu’à ce que je découvre la solution que j’ai adoptée et que je vous livre aujourd’hui.
La plate-forme pour blogs WordPress
Par défaut, WordPress affiche les pages de votre blog dans un format non compressé. Le problème c’est que ce n’est pas forcément une bonne solution pour vous que de livrer à votre navigateur internet une page web non compressée…
Utiliser un cache résout ce problème, sans compter qu’au passage on rajoute quelques optimisations qui accélèrent encore un peu plus le site. Si vous voulez une définition non académique du cache, il s’agit d’un endroit dans lequel vos fichiers sont stockés temporairement, de manière à afficher la page web plus rapidement sans passer par l’utilisation de votre bande passante.
Le cache de WordPress avec le plugin W3 Total Cache
J’ai donc adopté le plugin W3 Total Cache (téléchargement ici, forum de discussion pour apprendre comment installer la bête ici).
Il s’agit du moyen le plus efficace à l’heure actuelle pour faire ça. Si vous avez du mal à l’installer sur votre hébergement, le mieux est de faire appel à votre hébergeur pour qu’il vous aide à configurer toutes les options conformément à votre site. Pour ma part, je l’ai fait tout seul comme un grand en m’aidant principalement des excellents guides suivants :
- How to Install and Setup W3 Total Cache for Beginners
- W3 Total Cache -Plugin: The Complete Settings Guide
- Speed up WordPress with the W3 Total Cache Plugin
Les services Amazon S3
Vous remarquerez que dans les options de ce plugin, il est possible d’héberger ce cache sous Amazon S3 ou CloudFront. Ce dernier service est un CDN, autrement dit vos fichiers sont hébergés dans plusieurs centres de données à travers le monde de manière à ce que ce soit le plus proche de l’internaute qui soit activé. Vous pouvez héberger votre cache ailleurs, mais c’est personnellement la solution que j’ai choisie, pas pour le blog Des Geeks et des lettres mais un autre blog qui tourne sous la même configuration.
Comme il est expliqué sur le site officiel de CloudFront :
Amazon S3 est un espace de stockage durable d’objets pour Internet. Amazon CloudFront utilise Amazon S3 en tant que serveur d’origine pour stocker les versions originales de vos objets.
Amazon CloudFront est conçu pour distribuer les objets fréquemment consultés ; les objets “populaires”. Avec Amazon CloudFront, les copies de vos objets populaires sont mises en cache dans un réseau d’emplacements périphériques autour du monde. Parce que ces emplacements périphériques sont proches de vos utilisateurs finaux, vos objets peuvent être distribués plus rapidement que s’ils l’étaient depuis l’un des emplacements centraux d’Amazon S3.
Ceci améliore les expériences de vos utilisateurs finaux pour les contenus fréquemment consultés : latence plus faible et vitesses de transfert de données plus rapides.
Amazon S3 et CloudFront sont payants mais au final pas énormément puisque vous payez en fonction de ce que vous consommez. J’héberge le cache et mes images sous CloudFront, et très rapidement j’ai gagné 2 secondes pour le chargement de mon blog.
A noter : W3 Total Cache utilise également l’option « minify » du javascript et du CSS.
Bonjour
les 2 fichiers htaccess existent: l’un à la racine et l’autre dans wp-content/w3tc/pgcache/, je viens de vérifier et le message subsiste encore. Merci et bonne journée.
Bonjour
mon site n’est pas encore ouvert et je viens d’installer W3 Total Cache, mais à chaque fois, j’ai ce message : « It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration. » qui apparaît et je n’arrive pas à savoir quoi faire pour l’enlever. Merci d’avance.
Je me demande si vous avez bien un fichier .htaccess à la racine de votre blog. Ça doit être demandé je pense.
Un tutoriel de la mise en cache pour les auteurs Web et les webmestres
Je ne pense qu’il y ait vraiment de solution à un gif de 6meg (c’est absolument énorme !!)
Pourquoi ne pas passer par du flash ?
…ça risque de ne pas faire grand-chose, je le crains.
…Tu vas rigoler : à reprendre le projet, j’arrive à un .flv de 13 megs.
A priori, en plus, il semblerait que du flash dans un header wp ne soit guère possible…
Bon, je vais revoir le concept. Dommage, il était beau ce gif. Je vais essayer de le retravailler…
( des vagues venant du large qui se brisent sur une plage, c’est dur à faire looper, mais c’est facile à louper. Arf.)
En revanche, sais-tu comment je pourrais exploiter ce fameux cache ? je dois être bête, je n’arrive pas à formuler correctement mes recherches sur google (ou je suis le seul abruti à vouloir faire un truc inique 🙂
En tout cas, merci beaucoup de ton aide. Je repasse.
@+
Yves
…ou bien passer en « tout statique » ; au final, ça ne serait pas plus mal, et j’ai le sentiment que ça pourrait faciliter les choses…
Il fait quel poids ton gif ??
Bonjour Gregoire, merci de me répondre !
il fait dans les 6 megs… (j’ai honte 🙂
Bon, je peux le retravailler, diminuer la fréquence, mais la qualité s’en ressent…
Bonjour,
Soyez indulgents avec moi, s’il vous plaît : j’ai un peu peur que ma vision « d’autodidacte profane » vous lasse un peu ; cependant mes recherches ne m’ont pas permis d’aboutir ; les questions se font nombreuses, et – sans démagogie aucune – j’ai vraiment apprécié votre travail ici, ainsi que l’esprit qui y règne.
J’ai décidé de mettre un gif animé dans le header de mon WordPress. Certes, cela n’est pas une bonne idée, mais comme je suis une tête de mule, je suis passé outre les Golden Rules, rassuré par la vitesse actuelle des débits qui sont maintenant proposés, et par l’existence du cache d’un browser.
Mon WordPress est sur ma Debian Squeeze avec 1Go RAM, le serveur : c’est Cherokee (pour le streaming).
Je savais que le poids du Gif serait tôt ou tard un handicap, mais comme personne ne vient voir ce que je fais, je me disais que c’était pas trop grave. De plus, je pensais que le cache du browser pallierait ce fameux poids pour les visites ultérieures, (j’ai réglé header-expire jusqu’à l’an 2038 sur Cherokee, et j’ai même mis un .htaccess « pas d’expiration » dans le dossier des images – à priori, cela semble fonctionner).
Mais il semble que wp recharge l’image dans son intégralité en certaines occasions (login admin, rafraîchissement de la page, etc…), et en plus, j’ai eu de la visite. Un vrai manque de bol !
Du coup, j’ai découvert Firebug, Yslow, W3 Total Cache… et j’ai pas mal potassé.
je ne saisis pas le processus de gestion des images par 1) le browser et wordpress : car après tout, elle est bien en cache, cette image ! pourquoi se recharge-t-elle intégralement ? comment éviter cette contrainte, si ce n’est la faire enregistrer en local par chaque visiteur ce qui est aberrant.
Je n’arrive pas à trancher, car je n’ai aucune expérience dans ce domaine : un proxy, gateway ? un script qui afficherait le gif dans une div une fois chargé ? (mais bof) ; certes je peux mettre les images en externe, ce sera toujours plus rapide que depuis la vallée perdue où je suis (en plus, pour corser l’affaire). Sincèrement, j’y tiens à ce gif.
…je pensais bien avertir les gens que la première fois serait assez longue. au pire, une fois, attendre…
Pourriez-vous me conseiller, s’il vous plaît ?
Merci mille fois,
@ bientôt,
Yves
@Mimie > L’idée de base, c’est que le code (php, ruby, python ,etc.) utilisé pour afficher les sites, génère quelque chose. Le cache côté serveur c’est mettre en cache ce qui est généré. L’avantage du cache côté serveur est qu’il est partagé avec tous les clients, contrairement à un cache client qui ne concerne que chaque client individuellement.
Par exemple, parmi les solutions de cache serveur connues, on peut citer : apc (cache d’OP codes), memcache (mettre en cache dans la ram du serveur directement). J’ai rédigé un tuto pour memcache, accessible ici : http://gregoire-penverne.fr/492-memcache-boostez-votre-php (un tuto pour php, donc).
Mais bien entendu, jamais le cache serveur ne pourra faire gagner de temps de manière significative en download d’image…
@gpenverne : Bonjour Grégoire, qu’entends-tu par cache serveur ?
Merci de ton passage, gpenverne, et de tes compléments d’information utiles 🙂
Merci pour cet article 🙂 Personnellement, je pense qu’il faut envisager le cache sous deux angles : serveur et client. Le cache serveur est essentiel, le cache client est, à mon avis, moins important dans la mesure où les images, si elles sont optimisées, ne sont pas vraiment lourdes à télécharger.
En cas de besoins costauds pour des visuels, effectivement, le cache client et la répartition de la charge (upload) sont importants.
En tous les cas, j’ai téléchargé w3-total-cache 🙂 Merci 🙂
D’un autre côté, héberger ses images sous amazon s3 ou cloudfront en lieu et place de son hébergement habituel, ça aide à la rapidité sans passer par le cache.
Merci de ces précisions utiles en effet
Attention optimiser le cache c’est bien mais il faut penser que le cache n’est activé qu’après une première visite (donc sans objets en cache encore).
A noter aussi que Google (et les autres vont y venir) prend en considération la rapidité d’affichage des sites Web sans cache pour son classement dans les résultats de recherche.
Ceci étant le cache est important dans un second temps et pour cela ton plugin a l’air tout à fait satisfaisant.