13 Mai

Optimiser WordPress avec NGINX et W3 Total Cache – Suite

Ce post continue le précédent sur l’optimisation de WordPress avec Nginx et W3 Total Cache (W3TC). Après avoir passé une configuration standard et vérifié le bon paramétrage de la compression Gzip, il est temps de passer à la configuration de W3TC. Est-il besoin de rappeler que c’est le bon moment pour réaliser un back-up de la de données? A priori les opérations suivantes sont sans danger, mais on ne sait jamais.

Paramètres de W3TC

Plutôt qu’une longue explication, j’ai préféré présenter des captures d’écran.

Le page cache est le plus important. Avec l’option « disk enhanced » W3TC va créer une version html statique des pages dans l’arborescence du site à l’emplacement /wp-content/cache/page_enhanced/

Page Cache dans W3TC
Méfiance avec le minify, il peut potentiellement casser un thème mal codé, bien vérifier le résultat avant d’adopter les réglages. Si tout se passe bien, w3TC place les fichiers « minifiés » à l’emplacement /wp-content/cache/minify/. Deux paramètres importants:

  • disk : place les fichiers « minifiés » dans le répertoire /wp-content/cache/minify/ et les rend accessible à Nginx
  • auto : agressif et pousse le minify à regrouper les css et js sous quelques fichiers uniques au nom barbare (ZY7RDYQwDEMXggYEEzACug…a8zLa-7PeD4r-gI.css)

Ce dernier point a permis de réduire de 65 à 25 le nombre d’éléments à charger pour afficher la page de mon blog. Un navigateur typique ne charge que 2 fichiers à la fois, cette manipulation économise donc sur les temps de connect/send/wait. Si vous rencontrez l’erreur suivante, il faut aller activer l’option « Disable minify automatic file name length test » sur la page « minify » de W3TC:

w3tC_minify_error
J’utilise pour mon site le YUI Compressor, il est recommandé par Google et semble être plus efficace que les autres. Un simple apt-get install yui-compressor suffit sous debian pour l’installer, par contre, il faudra aller préciser le « path to java executable : /usr/bin/java » et le « path to jar file : /usr/share/yui-compressor/yui-compressor.jar » dans l’onglet Minify de W3TC.

W3TC Minify
Il ne reste plus que le « object cache » et « DB cache ». Memcache ou APC fonctionnent a priori sans soucis pour les deux et n’interagissent pas avec Nginx.

W3TC Cache ObjetW3TC DB Cache
Une fois les changements enregistrés, W3TC va créer un fichier nginx.conf à la racine du site web. Le mien ressemble à ça.

Intégrer la config Nginx de W3TC

La première méthode la plus simple consiste à rajouter dans le fichier de configuration nginx du serveur web un simple include $document_rootnginx.conf; juste au dessus du premier bloc « location ». Et ça marche, il suffit de faire un tour dans le répertoire /wp-content/cache/page_enhanced/phil.writesthisblog.com/ pour s’en convaincre. Chaque fois qu’un visiteur (non enregistré) visite une page du WordPress, son contenu apparaît dans le cache. Aux visites suivante, le cache est alors disponible.
Le problème est que la config proposée par W3TC est très mal rédigée. Rewrite dans tous les sens, plein de IFs, et elle ne fonctionne pas si bien que ça…

Améliorer la propre config Nginx à partir de celle de W3TC

L’idée principale est de reprendre les tests IFs proposés dans le nginx.conf de W3TC, et de remplacer tous les rewrites par des try_files dans des blocs location, ce qui permet de supprimer quelques IFs au passage.
J’ai mis en commentaires dans la configuration les explications sur ce que fait chaque bloc. Les IFs restants décident si le contenu caché doit être servi. Tout se joue alors dans le bloc « location / { … } ». Nginx teste d’abord si le contenu existe, si ce dernier ne doit pas être servi, le ‘cache null’ assure que rien ne sera trouvé dans le cache. Ensuite, nginx teste normalement pour le contenu avec $uri et $uri/ et sinon renvoie sur php5-fpm avec /index.php. W3TC ne crée la version statique d’une page que lorsqu’elle est accédée via /index.php.

Je rajoute aussi, dans les différents blocs « location » les paramètres de cache pour les navigateurs. En utilisant le net panel de Firebug et son propre navigateur, on voit qu’après une visite sur la première page, les contenus .css, .js et la plupart des images ne sont plus rechargés. N’hésitez pas à adapter ces paramètres en fonction de vos propres besoin.

On peut maintenant tester

Si tout s’est bien passé, on peut constater que chaque passage d’un visiteur (c.a.d non enregistré) sur une page du site, va faire générer par W3TC le contenu statique dans le répertoire /wp-phil-writesthisblog/wp-content/cache/page_enhanced/phil.writesthisblog.com/. Chaque visiteur suivant se verra servir le contenu directement depuis le cache. L’intérêt est immédiat en testant son blog sur PingDom, l’ordre de grandeur des « Wait times » pour les fichiers sont les suivants:

  • non caché donc généré par WordPress : 100 à 600ms voir pire
  • caché mais W3TC mais en mémoire : ~70ms
  • caché sur disque et servi par Nginx : ~20ms

On peut aussi remarquer que W3TC invalide bien le cache en rajoutant le suffixe .old aux fichiers. Naturellement, ils ne seront pas servis.
Mais plus intéressant encore ! Supposons que le moteur PHP ou MySQL de votre serveur se plante. Ça arrive malheureusement. Ça se teste avec un service php5-fpm stop, tout le contenu déjà en cache continue à être servi. Bien sûr, la partie dynamique du site est indisponible, plus possible de se loguer sur le serveur etc. mais en attendant les visiteurs continuent à surfer comme si de rien n’était.

Pour Conclure

A ce stade, on dispose maintenant d’un serveur relativement bien optimisé et résiliant.

    Gestion du cache navigateur par nginx
    Contenu statique délivré par le cache
    Résistant à un crash PHP/MySQL

Le blanc dans les waterfall est du au chargement du DOM par le navigateur. Là, il n’y a pas grand chose à faire côté serveur, cela dépend essentiellement du thème utilisé et du CPU de l’utilisateur.
Malgré tout, il reste encore quelques optimisations possibles, dont la principale consiste à précharger le cache au lieu d’attendre les requêtes clients. La suite au prochain post.

Une pensée sur “Optimiser WordPress avec NGINX et W3 Total Cache – Suite

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.