C’est désormais un secret de Polichinelle, WordPress est un script gourmand. La ressource, c’est son pêché mignon. C’est le prix à payer pour un « siteware » grand public capable de répondre à des demandes qui soient les plus larges possible. Nous n’allons pas disserter ici de la qualité ou non du code source de WordPress. J’inviterais simplement celles et ceux qui balancent des pavés dans la marre à se mettre au boulot et à fournir un script comme WordPress, mais plus performant. Ça, c’est dit.
Revenons en à notre problème de ressources. Pour pallier à cette problématique il existe des solutions plus ou moins simples à mettre en oeuvre, selon le dégré de connaissance de chacun et le serveur qui héberge votre installation WordPress. Ces derniers jours, j’ai donc pris le partis de tester l’optimisation de WordPress côté serveur. Et là, pas de pitié, on sort l’artillerie lourde !
Serveur Apache, le cheval qui s’essouffle
Pour faire tourner un site, il faut quelques logiciel sur votre serveur. SI vous êtes sur un serveur mutualisé, cette question ne se pose puisque c’est votre hébergeur qui gère cet aspect. Le petit soucis, c’est qu’il vous est quasi impossible d’optimiser votre logiciel.
Le serveur web est le point central d’une installation. C’est lui qui coordonne les diverses demandes des internautes et affiche les pages sur les navigateurs. Pour bien faire, il est donc primordial d’avoir la main sur ce serveur si vous souhaitez l’optimiser.
Jusqu’à présent, c’est le serveur web Apache qui domine le marché. Cette domination commence à être mise à mal par un nouveau venu : Nginx. Un serveur russe, ultra léger, robuste et performant. En effet, Apache, s’il est solide, est très gourmand en ressources, et a tendance à ralentir l’affichage de vos pages. Il est toujours possible d’accélérer Apache par le biais du fichier htaccess par exemple. Pour autant, les résultats ne sont pas forcément au rendez-vous.
Nginx au banc de test
Dans les tests que je viens de mener, j’ai utilisé l’architecture suivante :
Hébergement : Serveur chez Gandi – 1 part de processeur avec 256 Mo de RAM ( 12 euros par mois)
Serveur Web : Ubuntu Server 10.10, Nginx, avec APC et Varnish comme système de cache.
Les tests sont fait avec la commande ab de Apache, qui permet de simuler une montée en charge de votre serveur. J’avour ne pas avoir déçu ! Les résultats sont tout simplement bluffant. L’architecture testée est capable d’encaisser cent fois plus de requêtes que celle actuellement utilisée par 4h18.com. A titre informatif, 4h18.com dispose d’un serveur dédié datant de 2009, avec un intel Core 2 Duo à 2,6 Ghz et 2gigas de Ram. Ce n’est pas la grosse machine, mais tout de même, c’est censé tenir la route.
A la vue de ces résultats, il est évident que 4h18.com va migrer dans les jours à venir vers son nouveau serveur, et sera donc propulsé par Nginx. Il faut garder à l’esprit que l’ami Google a décidé que le temps de chargement des pages était désormais un des éléments pris en compte dans le référencement de vos sites.
Comment interpreter ces résultats
La conclusion de cet article serait donc de penser optimisation avant même la création de votre site. Tout comme il faut penser son référencement en amont, la question de l’hébernement doit donc désormais se poser également avant même d’avoir commencer votre site.
Nginx ne sait pas lire les fichiers htaccess, donc, sa mise en œuvre doit être pensée, réfléchie, et ne doit pas se faire à la va vite. Par ailleurs, je ne saurais trop vous conseiller la mise en place de Varnish, un système de cache qui apporte un énorme plus.
Désormais, l’optimisation fait partie du référencement, et le référencement commence avant la création de votre site. Ne l’oubliez pas.