Optimiser les performances de WordPress

Nous sommes toujours tentés d’ajouter de nombreuses fonctions à notre blog, avec de nouvelles extensions, ou de nouveaux widgets. Au bout d’un moment ces installations dégradent les performances. Il faut donc surveiller régulièrement les temps de réponses, et suivre certains indicateurs, notamment le nombre de requêtes envoyées à la base de données.
C’est en appliquant cette démarche à une extension que je développais, que je me suis intéressé à la notion de cache.

Cet article est une mise à jour de la publication du 6 novembre. Suite à différentes lectures sur la gestion du cache par WordPress, j’ai décidé de revoir le contenu de l’article, notamment pour apporter plus de détail sur cette notion que j’avais manifestement mal comprise.

Performances

La performance d’un blog ou d’un site internet correspond globalement à la vitesse d’affichage des pages dans le navigateur des internautes.

Cette performance dépend d’un grand nombre de paramètres:

  1. Puissance du matériel hébergeur,
  2. Type et paramètrage du système d’exploitation (Windows, Linux, Unix, …),
  3. Type et paramètres du serveur Web (IIs, Apache …),
  4. Configuration de la base de données MySQL,
  5. Le type d’installation, et les paramètres de PHP,
  6. Performances intrinsèques du moteur de blog,
  7. Les extensions et les plugins,
  8. Le thème,
  9. Les performances du réseau (bande passante, mais également latence):
    • au niveau serveur, et/ou de l’hébergeur
    • du fournisseur d’accès,
    • au niveau de l’internaute (type de ligne, ADSL, RTC, et performance de la ligne)
  10. Le navigateur.

Optimiser l’un de ces paramètres, sans tenir compte des performances des autres, ne sert globalement à rien:

  • la plus optimisée des installations WordPress, restera lente si le serveur Apache ou MySQL est déficient,
  • réciproquement, la plateforme la plus puissante, ne donnera rien, si le blog est mal géré.

Il faut également veiller à ne pas pousser trop loin la logique d’optimisation: le temps passer à optimiser n’est valable que si les gains de performance sont significatifs pour les visiteurs. N’oublions pas que les échelles de temps ne sont pas tout à fait les mêmes entre les machines et les hommes. 1/1Oième de seconde n’est quasiment pas perceptible pour un internaute, alors que cela représente plusieurs millions d’instructions pour une machine.

Surveiller les performances

J’ai identifié trois familles d’outils:

  • Les outils en ligne,
  • Les outils à installer sur son poste de travail,
  • Les outils à bricoler soit même sur son poste de travail.

Dans la première catégorie, la première chose à faire est de regarder ce que fournit son hébergeur. Ensuite, certains sites proposent des services de surveillance, souvent payants, mais dont certaines formules sont gratuites. C’est le cas de Watch Mouse, par exemple. Vous trouverez une liste de ce type de services sur Abricocotier.

Pour le poste de travail, j’utilise des extensions du navigateur Firefox. L’incontournable plugin Firebug propose déjà quelques informations intéressantes, que l’ont peut encore détailler si l’on ajoute le module YShow.

Une dernière méthode consiste à utiliser l’outil wget. Pour résumer wget est un navigateur en ligne de commande. Via un script, il est possible de lancer la consultation d’une ou plusieurs pages du blog, puis de récupérer les temps de chargement. La méthode est artisanale, mais elle fonctionne.

Attention: ces mesures vont générer du trafic sur le site. Si votre site est déjà chargé, l’opération n’est peut-être pas conseillée. Il faudra également tenir compte du trafic « artificiel » dans vos outils de mesure d’audience …

Les points d’optimisation

Comme préciser dans le premier paragraphe les facteurs de performance sont relativement nombreux. Essayons de voir rapidement ce que nous pouvons faire à chaque niveau:

# Facteur de performance Solutions possibles pour
Hébergement classique Serveur dédié Auto Hébergement
1 Matériel hébergeur Passer à l’abonnement supérieur Passer à l’abonnement supérieur ??? Changer le matériel
2 Système d’exploitation, Rien à faire, les hébergeurs n’offrent pas la possibilité d’agir à ce niveau Opter plutôt pour Linux, moins cher, moins sensible aux attaques,
3 Base de données MySQL, Peu ou pas de possibilités Choisir le bon mode pour la base de données, activer le cache
4 Serveur Web Peu ou pas de possibilités Modifier les paramètres de configuration et activer les solution de cache
5 PHP Choisir plutôt la version 5 de PHP (ou un version rescente)
Peu ou pas de possibilités Activer les modules de cache mémoire, ou de compression,
6 Moteur de blog, Installer un gestionnaire de cache
7 Extensions et plugins Comparer les extensions ou les plugins, en regardant particulièrement le nombre de requêtes passées, la lourdeur des scripts chargés … Parfois les extensions gèrent le cache.
8 Thème, Même remarque que pour les extensions ou les plugins.
9 Réseau Pas ou peu de possibilités Changer de type d’abonnement?
10 Navigateur Impuissance totale. Nous ne pouvons pas imposer de navigateur à nos visiteurs

Pour l’optimisation d’une plateforme d’hébergement complète, vous pouvez consulter l’article de Elliott C. Back

Pour résumer le tableau précédent, des solutions d’optimisation existent pratiquement à tous les niveaux. Mais la plupart d’entre nous ne pouvons agir que sur WordPress et ses extensions (plugins, widgets et thème). Attardons-nous donc sur les points 7 et 8.

Les plugins, widgets et thèmes, influencent les performances de diverses façons:

  • Nombre et complexité des requêtes passées à la base de données: le nombre de requêtes seul n’explique pas certaines lenteurs. Tout le monde n’étant pas capable de produire des requêtes optimisées, il est donc conseillé d’utiliser autant que possible les fonctions de l’API WordPress plutôt que de s’adresser directement la base,
  • Complexité du code PHP ou des traitements effectués sur les données récupérées,
  • Taille et nombre des fichiers nécessaires au fonctionnement du thème ou de l’extension (include/require dans le code PHP),
  • Taille de la page HTML générée et des fichiers associés: images, scripts javascript …
  • Complexité du code généré (HTML / CSS)

Les trois premiers critères ont un impact direct sur la plateforme d’hébergement (points 1 à 5). Les derniers critères concerne plus la gestion de la bande passante et le navigateur (point 9 et 10).

Analyser le comportement de WordPress

Comment analyser les différentes extensions de WordPress, en fonction des critères que je viens de donner. La méthode que j’utilise s’appuie sur deux outils: Firebug/YShow d’une part, et l’affichage du nombre de requêtes passées dans WordPress d’autre part.

Le plugin de Firefox, Firebug, accompagné de YShow me permet de voir, objet par objet, la taille et les temps de chargements de mes pages. Je vois donc immédiatement les objets les plus lourds, ou les objets qui prennent le plus de temps à charger.

Pour afficher le nombre de requêtes nécessaires à l’affichage d’une page, il suffit d’ajouter le code suivant dans le fichier footer.php du thème:

 requetes.  secondes.


Une autre méthode consiste à utiliser le hook wp_footer.

Avec ces deux outils, la surveillance s’organise de la façon suivante:

  • Avant toute modification de WordPress (changement de thème, ajout d’un plugin ou d’un widget), je regarde les temps de chargement des pages, et le nombre de requêtes générées. L’idéal est de faire l’exercice plusieurs fois, sur différents type de page (page article, page catégorie, tag, …),
  • J’exécute la modification souhaitée (installation d’une extension par exemple),
  • Je consulte à nouveau le site en regardant les temps de chargement, et le nombre de requêtes générées.

Les points à surveiller particulièrement sont:

  • Le poids des javascript chargés dans l’entête,
  • Le poids du code HTML généré,
  • Le poids des images,
  • Le nombre de requêtes supplémentaires.

Typiquement, un plugin de galerie photo, ajoutera certainement le chargement de script Javascript en début de page. La lourdeur de ces scripts peut être un critère de choix de ce plugin.

Il en va de même pour les requêtes: une extension générant un trop grand nombre de requêtes peut détériorer considérablement les performances d’un site.

Utiliser un gestionnaire de cache

La méthode précédente permet

  • de constater ce que « coûte » un thème, une extension, un widget en terme de performance, et éventuellement de choisir l’élément le moins consommateur,
  • d’optimiser ses propres développements.

Une fois la méthode appliquée, si les performances restent décevantes, l’étape suivante consiste à utiliser un gestionnaire de cache.

Le principe du cache est simple: au lieu de recalculer les pages ou les objets à chaque demande, l’outil mémorise ces objets ou ces pages lors de leur premier affichage, puis les renvoie directement lors des requêtes suivantes.
Cette méthode limite donc le nombre de requêtes passées à la base de données, ainsi que les traitements PHP effectués sur les informations récupérées.

Chaque objet conservé dans le cache à une durée de vie limitée. Au bout de ce délai, l’objet est « régénéré », c’est-à-dire que le système fait de nouveau appel à la base de données, et aux traitements PHP.

WordPress gère cette notion 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,
  • L’application propose une API de gestion de cache, utilisable facilement par des plugins ou des thèmes.

Je reviendrai plus en détail sur le sujet dans l’article suivant.

Conclusion

Avant d’entamer toute activité d’optimisation, il me semble important

  • de bien connaître son blog, d’un point de vue performances, mais également d’un point de vue fonctionnement interne,
  • et de se fixer des objectifs clairs et réalistes.

L’optimisation est en effet une activité qui se transforme vite en sujet sans fin. Des objectifs réalistes signifient notamment, que les valeurs cibles doivent être en rapport avec les moyens d’hébergement (ou financiers) dont nous disposons.
Il faut en effet être conscient que se focaliser sur WordPress et ses extensions ne résoudra qu’une partie du problème, les performances dépendant également de l’infrastructure (matériel, système, base, …).

WordPress propose des solutions de cache qui semble très efficaces, et qui permettent déjà d’encaisser un assez large trafic, sans recourir à des solutions encore plus radicales.

3 thoughts on “Optimiser les performances de WordPress”

  1. En fait, je me suis posé la question.
    Depuis la 2.5, la classe WP_Object_Cache est vide (ou presque). Il n’y a plus de cache actif.
    Du coup effectivement, ENABLE_CACHE devient inutile. Mais si l’on veut développer un cache, doit-on utiliser ou ignorer cette constante?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.