Utiliser le cache Wordpress
Je vous propose ici un cache super puissant. Oubliez les extensions qui vous promettent la lune, sans jamais tenir leurs promesses. Intelligent, ce système de cache place en effet les objets les plus utilisés en mémoire vive. C'est-à-dire qu’ils seront accessibles en une fraction de millisecondes, difficile de faire plus rapide !
Pour cela, vous devez au préalable installer Memcached sur votre serveur Web. Sous Linux Debian, utilisez simplement la commande suivante :
{{< highlight php >}}aptitude install memcached php5-memcache{{< /highlight >}}Puis redémarrez votre serveur Apache :
{{< highlight bash >}}/etc/init.d/apache2 restart{{< /highlight >}}Si vous désirez vérifier que tout s’est bien déroulé, créez une page phpinfo.php contenant le code suivant :
test Si vous désirez vérifier q avec retour{{< highlight php >}} }}
a la ligne
En l’appelant depuis votre navigateur Internet (comme Google Chrome ou Firefox), une rubrique memcache doit être affichée dans la page.
Pour activer le cache Wordpress, vous devez ensuite définir la constante WP_CACHE dans votre fichier wp-config.php, en y insérant la ligne suivante :
{{< highlight bash >}}define('WP_CACHE', true);{{< /highlight >}}Enfin, récupérez le contenu de ce fichier, puis enregistrez-le sous le nom object-cache.php dans le dossier wp-content/.
A partir de maintenant, l’ensemble du cache Wordpress est persistant, et sauvegardé en mémoire vive. Vous devrez obtenir une nette amélioration.
Utiliser le cache navigateur
Chaque navigateur possède un cache qui leur est propre. Cela lui permet d’éviter de recharger continuellement des images ou fichiers statiques, sans raison. Encore faut-il le prévenir que ce sont des fichiers statiques !
C’est notamment le cas pour l’ensemble de vos images ou feuilles de style CSS. Nous allons donc installer et utiliser le très bon module Apache expires, et le configurer pour mettre un cache de 10 jours sur toutes les images et fichiers CSS.
Pour cela, sous Linux Debian, commencez par créer un fichier nommé expires.conf, dans le dossier /etc/init.d/apache2/mods-available/, contenant les lignes suivantes :
{{< highlight bash >}}ExpiresActive On ExpiresByType text/css "access plus 10 days" ExpiresByType text/javascript "access plus 10 days" ExpiresByType application/x-javascript "access plus 10 days" ExpiresByType application/javascript "access plus 10 days" ExpiresByType image/x-icon "access plus 10 days" ExpiresByType image/png "access plus 10 days" ExpiresByType image/gif "access plus 10 days" ExpiresByType image/jpeg "access plus 10 days" ExpiresByType image/jpg "access plus 10 days" ExpiresByType application/x-shockwave-flash "access plus 10 days"{{< /highlight >}}Ensuite, pour activer ce module, tapez la commande suivante :
{{< highlight bash >}}ap2enmod expires{{< /highlight >}}Puis redémarrez Apache :
{{< highlight bash >}}/etc/init.d/apache2 restart{{< /highlight >}}Et ensuite ?
Comme dit dans le précédent article, pour ne pas rendre ces manipulations totalement imbuvables, j’ai décidé de les répartir sur plusieurs petits articles.
Le programme des prochains articles est donc : configuration complète d’Apache, configuration du serveur de base de données MySQL et mise en place d’un cache lourd (via l’installation et la configuration d’un proxy).
L’ordre de ces articles n’est pas anodin : les premiers vous présentent les solutions les plus rapides à mettre en place, tandis que le dernier (sur le cache lourd par proxy) vous détaillera la solution ultime que j’ai pu trouver (à elle seule, elle vous permet de diviser le temps de chargement par 20 au moins).
Vos réflexions
Par contre, il y a d'autres choses à faire au niveau du cache, pour optimiser Wordpress : utiliser le cache MySQL notamment, ou ajouter un cache PHP. Le cache MySQL fournit un très bon résultat : il faut savoir que sur une application dynamique, c'est bien souvent le serveur de base de données qui rame le plus. L'optimiser est donc une bonne idée.
Parce que les plugins sont codés un peu n'importe comment et il me semble aussi que le moteur de WP a fait son temps. Au lieu de recoder un noyau solide et performant, l'équipe de développement préfère en mettre plein la vue avec des nouvelles fonctionnalités.
Cela dit, l'article est bien. :) C'est bien de montrer aussi les défauts de WP, les bloggeurs ont tendance à voir que les cotés positifs de son interface et de ses fonctionnalités.
Nous utilisons le couple Nginx / Apache avec Nginx en frontal qui renvoie directement les pages statiques générées par le plugin.
Je suis d'accord, MySQL n'est pas la source du problème à proprement parler. C'est l'utilisation que Wordpress en fait qui peut poser problème. Cependant, MySQL reste le goulot d'étranglement en général, c'est là que ça coince. Du coup, je pense que ça peut être utile, aussi, de profiter du cache que MySQL propose de base. Non ?
@421stores : Tu as raison. Il est nécessaire de configurer correctement MySQL, notamment pour activer le cache, mais aussi pour s'adapter au mieux aux besoins de Wordpress. Ces étapes seront abordés en partie dans le prochain article (en fait, l'idéal est de recompiler une partie de MySQL, mais je doute que j'entrerai dans ces "détails" ici ;))
@Camille : Les plugins sont en tord, mais la base de Wordpress aussi, en effet. En fait, le code a clairement plusieurs années dans les pattes, et ces concepteurs refusent clairement de le revoir. Car le revoir totalement, c'est aussi condamner certains plugins, qui ne pourront alors plus fonctionner.
@High-Tech : Excellent, je ne suis pas si certaine. Il reste relativement lourd et fait travailler le disque dur à outrance. En fait, c'est mieux que rien, mais j'obtiens des performances bien plus élevées avec le système de proxy, que je détaillerai dans mon dernier article.
Sur un hébergeur mutualisé, tu peux déjà appliquer toutes les modifications évoquées dans mon précédent billet : elles ne touchent que l'application.
Par contre, pour utiliser le système de cache Wordpress, tu as besoin d'avoir Memcache installé sur la machine. Je ne connais aucun serveur mutualisé qui propose une telle option.
En revanche, pour le cache par navigateur, c'est peut être possible. Pas de manière aussi élégante que décrite dans le billet, mais en utilisant le fichier .htaccess. Attention cependant, ce n'est pas facilement réalisable chez tous les hébergeurs ! Mais certains permettent d'ajouter les règles données ci-dessus dans un .htaccess, pour contrôler directement la date d'expiration des fichiers statiques.
Ce que je veux dire, c'est que les offres mutualisées sont généralement limitées par leur bande passante. Une fois le quotas dépassé, c'est fini, le site est coupé. Or, si le cache est activé sur le navigateur, les images et autre "gros fichiers" statiques ne seront pas téléchargés à chaque fois. Donc il y a beaucoup d'économies de bande passante. Donc le site n'est pas coupé (ou du moins, il est coupé moins vite).
Je ne sais pas exactement où tu veux en venir avec le Squid, j'attends de voir avec impatience. Pour les fichiers statiques (dont images) que tu as déjà envoyées sur un sous-domaine différent, tu peux utiliser des Nginx (ou un lighttpd, mais je préfère le premier) qui consomme beaucoup moins de RAM que ce bon vieil Apache. Enfin, j'attends de voir ta solution, on comparera si nécessaire...
En tout cas, bravo pour ces premiers articles et à bientôt pour la suite !