Note : Ce billet a été rédigé par Aurelie. Elle est notamment à l'origine de cette 2eme version d'ilonet, basée sur un Wordpress décortiqué et optimisé.

Julien vous en avait parlé dans ce billet, je me suis proposée pour écrire un petit article sur l’optimisation de Wordpress. Article qui a été rédigée en Guest Blogging donc, vu que je ne suis pas chez moi ici. J’ai essayé de suivre les conseils que j’ai pu gratter à droite et à gauche, mais rédiger un article sur un blog n’est pas une opération courante pour moi. J’espère que vous saurez être indulgents.

Première chose, la longueur de l’article. Je me suis rendu compte que j’avais beaucoup de choses à dire, énormément de choses à dire, et que rédiger un pâté de deux cents pages n’était pas forcément une bonne idée. Et comme toutes les optimisations ne se font pas au même niveau, je vais plutôt diviser cet article en une série de plusieurs petits. Ca me donnera l’occasion de m’entrainer un peu, pour essayer peut être de devenir un jour une vrai blogueuse ?

Entrons dans le vif du sujet, parlons Wordpress, parlons optimisation. Comme je l’ai dit, c’est le premier article d’une longue série. Il se concentre donc uniquement sur les premières mises en garde, les premières choses à toucher sur Wordpress pour l’optimiser. Les autres articles devraient suivre rapidement.

Benchmark : les performances finales

Pour évaluer ces optimisations, j’ai naturellement fait une série de tests. J’aurais pu terminer par cette partie, mais je trouve ça plus sympa de la mettre au tout début. Au moins, ça montre où on va. Voici donc comment j’ai réalisé ces tests de performance :

• J’ai installé une distribution Debian 5 vierge, avec Apache, PHP5 et MySQL (configuration de base) ainsi que la dernière version de Wordpress 2.9.2. J’ai ajouté quelques articles bidons, et les 10 plugins les plus populaires de Wordpress.
  

• Puis j’ai fait mes premiers tests. En moyenne, sur ma machine virtuelle, en simulant 1000 utilisateurs en ligne simultanément, qui appellent aléatoirement la page d’accueil, l’accueil d’une catégorie, la page d’une recherche ou la page d’un article, la page se charge en 3622,1 millisecondes. Ca peut paraitre beaucoup, mais c’était une machine virtuelle, et il y avait quand même 1000 personnes en parallèle.
  

• J’ai fait mes optimisations sur Wordpress, configuré un Squid en profondeur, configuré correctement MySQL et Apache.
  

• J’ai relancé mes tests. Toujours sur ma machine virtuelle, et toujours en simulant toujours 1000 utilisateurs en ligne simultanés, qui appellent aléatoirement la page d’accueil, l’accueil d’une catégorie, la page d’une recherche ou la page d’un article, la page se charge en moyenne en 129,4 millisecondes.
  

Soit un chargement moyen 27 fois plus rapide !

Attention aux plugins, attention aux thèmes

Même si cela ne rentre pas directement en compte dans mes tests, c'est le premier conseil que je peux vous donner : il faut faire attention à certains plugins. Certains d’entre eux sont très mal codés, et consomment beaucoup de ressources.

C’est dommage, car un tout petit plugin peut parfois écrouler les performances globales de votre blog. Si vous n’avez pas le niveau pour analyser la source de ces plugins, essayez quand même de regarder les appréciations globales sur Wordpress Plugins, dans les commentaires.

C’est aussi valable pour les thèmes. C’est même encore plus traitre, car on ne s’attend pas à ce qu’un thème puisse être une « usine à gaz ». Pourtant, certains proposent tellement d’options qu’ils sont super lourds. Je pense par exemple au thème Mystique.

Pour les thèmes, pensez aussi à regarder la taille des images et des fichiers Javascript. Ces fichiers doivent en effet être chargés par vos lecteurs : s’ils sont lourds, le chargement des pages sera forcement plus longs. C’est désagréable pour les lecteurs.

Désactiver la révision des articles

Depuis la version 2.6, Wordpress inclut un système de « révisions ». En gros, lorsque vous modifiez ou enregistrez un article, un nouvel enregistrement est ajouté dans la base de données. C’est pratique lorsque vous écrivez à plusieurs et que vous souhaitez garder une trace de toutes les modifications réalisées (avec la possibilité de revenir en arrière), mais c’est très consommateur en ressources.

En effet, un article peut ainsi se retrouver en 15 ou 20 exemplaires dans votre base de données. La taille de votre base de données sera donc décuplée, ce qui l’alourdira. Du coup, en plus de consommer plus d’espace disque, elle sera légèrement plus lente.

Si vous n’avez pas besoin de cette fonctionnalité, autant la désactiver directement. Pour cela, modifiez le fichier wp-config qui se trouve à la racine de votre Wordpress, puis ajoutez la ligne suivante :

define('WP_POST_REVISIONS', false);

Vous pouvez également purger votre base de données, en effaçant l’ensemble des “revisions”. Rassurez-vous, cela n’aura aucun impact sur l’affichage de votre blog ; seuls l’historiques des modifications sera supprimés. Pour cela, connectez-vous à votre base de données MySQL (via phpMyAdmin, par exemple), et lancez la requête SQL suivante :

DELETE FROM wp_posts WHERE post_type = 'revision';

Ajouter un cache Gravatar

Wordpress intègre le service Gravatar, qui permet d’associé automatiquement un avatar selon l’adresse email de l’auteur d’un commentaire. C’est notamment ce service qui permet d’ajouter automatiquement ma petite photo, à coté de tous mes commentaires.

Cependant, les serveurs Gravatar ne sont pas toujours très véloces. Surtout qu'ils ne demandent pas au navigateur de les mettre en cache. Une image, une requête HTTP. Avec 50 commentaires, 50 requêtes HTTP supplémentaires. Ca peut vite devenir lent pour le visiteur !

Heureusement, un plugin vous permet de mettre en cache ces avatars. Vous avez ainsi le contrôle sur l’expiration du cache navigateur, et limitez les requêtes vers les serveurs Gravatar.

Héberger vos images sur des IPs différentes

Quand un navigateur charge une page, il charge également l’ensemble de ses images, et l’ensemble de ses fichiers Javascript. Pour cela, il fait une requête HTTP par objet. Seulement, pour ne pas surcharger le pauvre serveur, il se limite généralement à 2 ou 3 requêtes simultanées sur la même IP… ce qui prend au final encore plus de temps !

Pour contourner cela, une idée est d’avoir plusieurs IP. Si vous avez un serveur dédié, vous pouvez facilement créer un sous-domaine, pointant sur votre serveur avec une autre IP, pour héberger toutes vos images. Si vous êtes en mutualisé, c’est déjà plus dur. La solution est alors d’avoir plusieurs hébergeurs, avec des IP différentes.

Et ensuite ?

La suite sera détaillée dans les prochains billets. Par contre, pour la suite, il sera nécessaire d’avoir la main sur la configuration du serveur. Au programme : mise en place d’un cache léger en mémoire vive, configuration d’Apache et MySQL, mise en place d’un cache lourd (via l’installation et la configuration d’un proxy).

En espérant que ce premier article puisse vous servir, même s'il concerne pour le moment que les bases de l'optimisation. J'attends vos conseils et remarques, pour rédiger au mieux la suite de cet article.