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 degré 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.
Pour aller plus loin
Booster WordPress avec Varnish
Ayez la partigitude, la cool attidude, c'est ça la bloguitude !




RT @diije @4h18: Optimisation de WordPress avec Nginx et Varnish, ça donne quoi ? // intéressant !
RT @brunohug: RT @diije @4h18: Optimisation de WordPress avec Nginx et Varnish, ça donne quoi ? // intéressant !
Bon article, mais il manque juste le détail des résultats de tes tests, perso j’aurai aimé les voir…
En plus, si je me trompe pas, nginx ne supporte pas le htaccess pour des raisons de performances. Mais on peut utiliser le fichier de configuration du site pour y placer les instructions que l’on souhaite que l’on placait avant dans le .htaccess.
voici le résultat de ab test :
Requests per second: 3950.08 [#/sec] (mean)
Time per request: 2.532 [ms] (mean)
Time per request: 0.253 [ms] (mean, across all concurrent requests)
En ce qui concerne le htaccess, tu as raison, j’en parle en fin d’article.
Pingback: links for 2011-05-02 | Olivier Galluchot
Un très excellent article merci bcp
WordPress est un excellent CMS ce n’est plus discutable. Mais nativement, il consomme beacoup de ressources. Il faut donc absolument penser à l’optimiser pour le rendre plus sûre et surtout plus rapide. Depuis que Google prend en compte le temps de chargement, il faut faire attention à cet ascpect. Pour certaines, cela prend du temps. Pour d’autres ça demandes quelques minutes.
L’optimisation, tout comme le référencement doit désormais se penser en amont de la création du site, après, c’est trop tard, et c’est une vraie galère.
Je travail depuis des mois sur la haute performance des infrastructures web. Et cet article est assez interessant dans la mesure où il est plus situé à un niveau Dev, Expert SEO que SysAdmin.
Un petit correction : « accélérer Apache par le biais du fichier htaccess ». C’est faux. Bien au contraire. Il faut toujours éviter les .htaccess qui sont interpretés à chaque lecture au profit d’un configuration au niveau Virtualhost qui est « compilée » au lancement du démon Apache.
Pour ajouter mon grain de sel : il existe cherokee webserver. Un web server TRES puissant et léger mais aussi très facil à administrer grace à son interface web activable à la demande, il est donc plus accessible à tout le monde.
Merci pour cette article !
[Archive]: Optimisation de WordPress – C’est désormais un secret de Polichinelle, WordPress est un… #wordpress