10 Mai

Optimiser WordPress avec NGINX et W3 Total Cache – Intro

WordPress est un outil de blog très populaire, mais il faut le reconnaître tel quel, il est très consommateur de ressource. L’affichage des pages est abominablement lent même sur un site à faible trafic sur un serveur robuste. Ce post va donc présenter des optimisations très efficaces qui permettront à la fois de descendre à un affichage de pages sous la demi-seconde et de permettre à votre serveur d’encaisser un trafic plus important. Je me sers ici de W3 Total Cache (W3TC) qui est assez bon, on peut lui préférer WP Super Cache, pourquoi pas, mais la configuration de Nginx sera différente.

Environnement

OS : Debian 7.5 stable (Wheezy) (64bits)
Nginx : nginx/1.6.0
PHP : 5.5.12-1 avec Zend Engine v2.4.0 et Zend OPcache v7.0.4
W3 Total Cache : Version 0.9.4 avec les paramètres suivants

  • Page Cache – Disk Enhanced
  • Minify – Disk ou Désactivé (le Minify peut massacrer des thèmes mal codés)
  • Database Cache – Memcache ou Alternative PHP Cache (APC)
  • Object Cache – Memcache ou Alternative PHP Cache (APC)
  • Browser Cache – Désactivé (on laisse Nginx le gérer)


Il est contre-intuitif d’utiliser un cache disque plutôt que mémoire. Mais tout l’intérêt est de faire apparaître les contenus cachés dans l’arborescence pour permettre à Nginx de les servir directement. Quant aux accès disques, Nginx dispose des ses propres mécanismes de cache et le noyau derrière aussi, pour peu que le contenu soit très sollicité, il finira rapidement en mémoire. Au pire, si cela peut vous rassurer, vous pouvez toujours faire pointer les répertoires de caches sur une partition tmpfs.
Cette méthode est en fait largement supérieure :

  • Nginx sert du contenu html sans solliciter la mécanique php de wordpress
  • Nginx est imbattable pour servir du contenu statique même sous forte charge
  • Le contenu reste disponible même en cas de crash du moteur PHP ou MySQL

Tout le tutoriel a été testé sur ce propre blog. Ceci dit, à part peut-être quelques adaptations en fonction des évolutions de W3TC, tout devrait fonctionner tel quel sur tout linux.

Pré-Requis

Le minimum est de déjà disposer d’un WordPress fonctionnel, même sous apache! A partir de là, il vous suffit de passer un apt-get install nginx memcached php5-memcached php5-memcache php5-fpm php5-apc et d’installer le plugin W3TC sous WordPress bien sûr. Pensez à désactiver avant apache quand même, si nécessaire, avec un service apache2 stop.

Benchmark

Essayer d’optimiser quoique ce soit sans disposer d’un référentiel est contre-productif. J’ai utilisé PingDom pour mon propre blog, il a l’avantage d’être rapide, de permettre de vérifier chaque élément servi, et de suggérer des axes d’amélioration.
Les temps indiqués dans le « waterfall » sont par contre à relativiser, même Google s’affiche en plus d’une seconde! Cela vient plus de l’outil qui se compose d’une batterie de scripts pilotant un navigateur.
En attendant, PingDom ou autres permettent de comprendre rapidement quels sont les goulots d’étranglement de votre serveur web et comment y remédier.

En partant d’une Configuration basique

Pour ceux qui passeraient directement d’Apache à Nginx, voici une configuration basique qui fera tourner WordPress. Attention à adapter les répertoires en fonction de votre propre environnent. Si vous n’avez pas lu le tutoriel sur PHP et Nginx, n’oubliez pas de rajouter le fichier /etc/nginx/php_params disponible ici.

Il ne vous reste plus qu’à tester la configuration et la démarrer nginx -t && service nginx restart.

Activer la Compression Gzip

Ça ne coûte pas grand chose en CPU et permet d’optimiser la bande passante mais surtout le temps de chargement par le navigateur du contenu du site. Voici quelques réglages à activer dans la configuration principale de Nginx dans le /etc/nginx/nginx.conf

La documentation nginx explique plus en détails les différents paramètres. Quelques idées importantes :

  • gzip_vary : permet d’éviter les blagues au niveau d’un éventuel proxy en lui faisant conservant les versions compressées et non compressées
  • gzip_comp_level : le niveau 6 me parait un bon compromis. A baisser en cas de charge CPU
  • gzip_static : Utilise une version pré-compressée du fichier à servir si elle existe. Bien sûr, si vous modifiez le fichier source, il faudra recompresser, mais ça se scripte. A utiliser si le CPU sature vraiment et c’est un module qui doit être compilé dans nginx.
  • gzip_types : spécifie quels fichiers compresser. Allez voir le fichier /etc/nginx/mime.types et adaptez en fonction de votre site. Cela ne sert à rien de compresser les images par exemples, mieux vaut se limiter aux fichiers textes.
  • gzip_disable « msie6 » : au cas où un malheureux utilise encore internet explorer 6.

Après un nginx -t && service nginx reload on peut constater la différence. La page de garde de mon blog passe de 580ko à 248ko grâce à la seule compression. Sur une ligne ADSL à 10Mbps, ce seul réglage représente 265ms !!

La suite dans le prochain tutoriel

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.