WordPress: Utiliser un système de cache

Dans un précédent article, j’ai abordé l’optimisation de WordPress. L’une des méthodes fait appel à la notion de cache, que je vais expliquer maintenant.

Généralités

D’un point de vue global, un système de cache permet de mémoriser des objets, pour les restituer ensuite plus rapidement. Il évite, par exemple, de requêter plusieurs fois la base de données pour récupérer la même information.

Sur une plateforme de type CMS (Content Management System) ou moteur de blog, il existe globalement deux niveaux de cache:

  • Le cache objet mémorise des éléments ou objets nécessaires à la génération des pages,
  • Le cache avancé mémorise les pages elles-mêmes.

En général, les seconds sont plus performants que les premiers, puisqu’ils permettent de ne plus s’adresser ni à la base, ni au moteur PHP. Ils ont cependant quelques contraintes, comme la nécessité de modifier la configuration du serveur Web lui-même (Apache par exemple).

Le cache objet est moins performant, mais il est souvent plus souple à installer et à configurer, parce qu’il n’intervient qu’au niveau du moteur de blog.

Un cache peut fonctionner selon deux modes:

  • Avec un cache non persistant, la durée de vie du cache n’excède pas le temps nécessaire à la génération d’une page. Les informations mémorisées ne sont donc pas utilisables d’une page à une autre,
  • Avec un cache persistant, la durée de rétention est plus longue: les objets subsistent au-delà de la génération des pages, peuvent donc être réutilisés d’une page à une autre.

Les caches non persistants stockent les objets en mémoire. Les caches persistants peuvent stockent les objets sur disque (fichiers), ou en mémoire, s’ils disposent d’une configuration adaptées (au niveau PHP par exemple).

Le cas de WordPress

WordPress autorise et favorise l’utilisation de cache:

  • Le code de l’application est truffé de hooks et de filtres lui permettant d’être facilement interfacé avec des systèmes de cache interne ou externe. Ces interfaces autorisent les deux niveaux de cache objet et avancé,
  • L’application propose une API de gestion de cache, utilisable facilement par des plugins ou des thèmes.

Cette notion de cache a évolué au fil des versions:

  • avant la version 2.0, l’application ne disposait pas de système de cache,
  • de la version 2.0 à la version 2.3.3, WordPress possède un système de cache objet interne, de type persistant, sur disque,
  • A partir de la version 2.5, le cache interne est devenu non persistant (cache objet en mémoire), et devient actif par défaut. Mais les interfaces du code avec le cache sont beaucoup plus nombreuses.

Vous trouverez sur le site de NeoSmart Technologies des explications et un historique détaillé.

Pour les versions 2.0 à 2.3.3
  • Le cache s’active en initialisant la variable ENABLE_CACHE dans le fichier wp-config.php
  • La durée de vie des objets en cache est définie, soit par la constante CACHE_EXPIRATION_TIME, soit par un paramètre transmis aux fonctions de gestion du cache,

Cette méthode a un inconvénient: Par défaut, la durée du cache est fixé à 15 minutes. Si les extensions, les thèmes ou les widgets ne modifient pas cette valeur, tous les objets du cache seront donc renouvelés en même temps. Donc pendant les 15 minutes fixées, le blog ne demandera que très peu de requêtes, mais les relancera pratiquement toutes en même temps, passé ce délai (voir l’article sur WordPress-fr.net).

A partir de la version 2.5

Le cache devient non persistant et change de rôle. Sans configuration particulière, les objets étant stockés en mémoire, leur durée de vie n’excède pas la durée de génération de la page. Le cache sert donc, avant tout, à gérer les requêtes répétitives pendant la génération d’une page. Par exemple, WordPress utilise le cache pour mémoriser un grand nombre d’options, évitant ainsi de requêter la base de données à chaque appel à la fonction get_option.

Les plugins

Les gestionnaires de cache pour WordPress sont tous persistants, et reprennent les catégories énoncées précédemment: On trouve en effet des caches objet et avancés, utilisant un stockage en mémoire ou sur disque.

Le tableau ci-dessous dresse une liste des extensions les plus connues, en donnant leurs principales caractéristiques:

Extension Niveau Stockage Configuration
nécessaire
XCache object mémoire PHP: xcache
Memcached object mémoire PHP: Memcached
BatCache object mémoire PHP: Memcached
APC Object Cache objet mémoire PHP: apc
Hyper Cache avancé disque
File Object Cache objet disque
WP Cache 2 objet disque
WP SuperCache Avancé disque Apache: mod_rewrite

Vous trouverez des détails et les modes d’installation de ces plugins chez PapyGeek.

Pour résumer

  • WP-Cache 2 n’est plus mis à jour depuis Mars 2007. Compte-tenu des évolutions de WordPress depuis cette date, il ne faut donc pas trop lui en demander,
  • XCache, MemCached, BatCache, Apc demandent tous un module particulier au niveau de PHP,
  • L’installation de WP-Super-Cache requiert un certain niveau d’accès au niveau de Apache,
  • Seuls Hyper Cache et File Object Cache peuvent être installés et utilisés sans configuration particulière de l’environnement (PHP ou Apache).

Quelle efficacité?
J’ai effectué quelques tests sur mon poste de développement. Ces essais étant locaux, les résultats ne sont pas forcement significatifs.

Je confirme que WP-Cache 2 ne fonctionne plus très bien avec une version 2.7 de WordPress.
File Object Cache donne des résultats « visibles » puisqu’il se comporte comme le cache interne des versions 2.3 de WordPress: il diminue le nombre de requêtes envoyées à la base de données.
Tous les caches objets utilisant des extensions PHP (XCache, MemCached, BatCache, Apc) nous donnent pratiquement tous les mêmes résultats.
Les meilleurs résultats sont obtenus avec WP Super Cache.

Quelles approches adopter?

  • Il faut d’abord vérifier que les défauts de performances ne viennent pas d’une mauvaise configuration, ou d’une extension trop gourmande,
  • Il faut ensuite évaluer les possibilités que vous offre votre hébergement. Quelle est la configuration de votre installation (Apache et PHP)? Etes-vous libre de modifier cette configuration? Avez-vous la possibilité de modifier le fichier .htaccess?
  • En fonction de vos possibilités, faire une première sélection des plugins, puis les tester individuellement.

En fait, je pense que la décision est relativement facile à prendre, et dépend principalement d’une seul critère: le taux de visite du blog:

  • Un blog peu visité (quelques pages vues par jour), tourne rarement sur un hébergement haut de gamme. Les possibilités de configuration sont peu nombreuses, mais les besoins en performance ne sont pas très poussés: HyperCache ou FileObjectCache suffiront amplement,
  • Un blog plus visité nécessite forcement un bon hébergement, donc des possibilités accrues au niveau de la configuration des outils. Dans ce cas WP SuperCache ou XCache s’imposent.

Conclusion

Les gestionnaires de cache constituent une excellente solution pour améliorer les performances d’une platforme WordPress. Malheureusement, leur installation n’est pas sans contrainte. Si vous n’avez pas de réels moyens d’accéder aux paramètres de votre hébergement, Hyper Cache, ou  File Object Cache offriront un premier niveau de cache assez performant. Pour aller plus loin, des solutions comme XCache, ou WP Super Cache s’imposeront, avec un hébergement adapté.

Partager cet article