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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | server { server_name phil.writesthisblog.com; access_log /var/log/nginx/wp_philwritesthisblog_access.log; error_log /var/log/nginx/wp_philwritesthisblog_error.log; root /var/www/wp-phil-writesthisblog; index index.php; # La liste du contenu a ne pas servir # les fichiers commencant par . location ~ /\. { access_log off; log_not_found off; deny all;} # ici les back-up de la BDD location = /wp-content/backup-db { access_log off; log_not_found off; deny all;} # le fichier wp-config.php location = /wp-config.php { access_log off; log_not_found off; deny all;} # on ne vas pas executer du php dans le repertoire upload wtf!? location ~ ^/[^/]+/uploads/.*\.php.? { access_log off; log_not_found off; deny all;} # pas besoin garder dans les logs les accès au favicon et au robots.txt location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { log_not_found off; access_log off; } # Traite les requetes generales. Verifie si le contenu existe bien sinon renvoie sur /index.php location / { try_files $uri $uri/ /index.php; } fastcgi_intercept_errors off; # Cache les contenus statiques tels que css, js, jpg, etc. # "expires" indique au navigateur le temps de conservations en cache des elements location ~* \.(js|css|gif|jpg|jpeg|png|txt|xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|ico|zip|tgz|gz|rar|bz2|doc|xls|ppt|tar|mid|midi|wav|bmp|rtf)$ { expires max; add_header Pragma public; add_header Cache-Control "public, must-revalidate, proxy-revalidate"; } # passe le php a php5-fpm location ~ \.php$ { try_files $uri /index.php; include php_params; } } |
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
1 2 3 4 5 6 7 8 | root@server:/etc/nginx/sites-available# cat /etc/nginx/nginx.conf | grep gzip gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; gzip_static on; |
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.typeset 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…