WP Super Cache avec mod_rewrite : les performances d’un site statique alors que celui ci semble dynamique

Dans mon post précédent, je vous ai présenté pas mal de chiffres plutôt positifs concernant la performance de ce site, en terme de temps de chargement des pages, avec des chiffres sous pingdom souvent inférieurs à 0.2 secondes.

Je vous ai également surtout indiqué que je vous livrerai pas mal d’éléments de méthode pour obtenir vous aussi des meilleurs temps de chargement de page.

Aujourd’hui, je vous indique comment le plugin WP Super Cache peut aider à améliorer les performances d’un site WordPress (et à soulager le serveur), ainsi que les principes qui peuvent être reproduits si vous avez un site dynamique n’utilisant pas WordPress (que ce soit un CMS courant tel que Drupal, Joomla ou un système “fait maison”).

Introduction à WP Super Cache et configuration discutée dans ce post

WP Super Cache est essentiellement un plugin WordPress permettant d’utiliser un cache pour soulager le serveur et améliorer les performances.

Vous trouvez plus de renseignements au sujet de l’historique de ce plugin et des nombreuses fonctionnalités annexes sur la page officielle du plugin WP Super Cache (en anglais) que je vous invite vivement à consulter.

Dans cet article, je ferai preuve d’un minimum de concision, aussi ne vous attendez pas à tout savoir sur le plugin sans aller fouiller du côté des liens fournis…

La configuration discutée dans ce post est celle où il est choisi d’utiliser mod_rewrite. Dit autrement, dans la configuration, ça ressemble exactement à l’image en haut de ce post ;)

WP Super Cache avec mod_rewrite : le principe qui vous permet d’éviter non seulement des requêtes MySQL mais aussi l’exécution de code PHP…

Lorsqu’une page de votre site est demandée, si votre page est dans le “bon cache“, vous pouvez, si les conditions sont réunies :

• soulager votre serveur MySQL, qui n’est alors plus sollicité au chargement de la page en cache,
• soulager également aussi le serveur qui répond aux requêtes HTTP (souvent 1 serveur avec Apache+mod_php, mais après il est possible d’utiliser bien d’autres solutions…) : dans ce cas, il n’y a même plus d’exécution de code PHP lorsque la page du cache est servie…

Pourquoi le “bon cache” ? En fait, même avec le cache utilisant mod_rewrite activé, si les conditions ne sont pas réunies pour utiliser le cache permettant d’éviter l’exécution de code PHP, WP Super Cache peut chercher à utiliser les autres caches pour éviter pas mal de requêtes MySQL.

Par ailleurs, PHP et MySQL restent indispensable pour faire tourner le site… En effet, même s’ils ne sont pas forcément sollicités pour chaque page vue, ils restent sollicités lorsque WordPress génère la page qui sera ensuite stockée dans le cache… Le cache permet de générer une seule fois une page pouvant ensuite être visionnée plusieurs milliers de fois (autant que nécessaire tant que le cache n’est pas purgée d’une version expirée).

Par ailleurs, pour court-circuiter PHP, il faut que “les conditions” soient réunies… La suite sera l’occasion d’aborder ce point…

Le code de rewriting (mod_rewrite) inséré dans le fichier .htaccess, élément crucial du fonctionnement de WP Super Cache

Comment votre serveur fait il pour détecter qu’une version en cache peut vous être délivrée, et ce sans exécuter du PHP ? C’est peut-être une question que vous posez…

Le secret est dans le code à insérer manuellement ou automatiquement dans le fichier .htaccess. Cela utilise le module Apache mod_rewrite.

Voici le code qui peut être inséré :

# BEGIN WPSuperCache

RewriteEngine On
RewriteBase /
#If you serve pages from behind a proxy you may want to change 'RewriteCond %{HT
TPS} on' to something more sensible
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_
).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-h
ttps.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html
.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTPS} on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index-https.html" [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\\"]+ [NC]
RewriteCond %{HTTPS} !on
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html" [L]


# END WPSuperCache

Je ne vais pas rentrer dans le détail de l’explication de ce code. À vrai dire, l’explication détaillée en Français ne serait pas forcément plus courte que le code…

Voici quelques points que j’estime digne d’intérêt :

• Ce code est présent dans le fichier .htaccess avant le code que WordPress utilise pour donner la main au fichier index.php, il est donc prioritaire.
• Côté mécanisme : les lignes ressemblant à RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f constituent le cœur du mécanisme. Ce sont ces lignes qui vérifient l’existence d’un fichier (“-f”) en cache correspondant au contenu demandé. Si le fichier n’existe pas, le cache ne peut être utilisé. À noter que le “$1″ est associée à la chaîne capturée dans le RewriteRule (et non à un élément de la RewriteCond)
• Il y a plusieurs règles différentes parce qu’il y a énumération de cas, selon que HTTPS soit ou non utilisé, et selon que le logiciel client (comprendre le navigateur) supporte ou non le contenu compressé.
• Plusieurs conditions doivent être réunies pour utiliser ce type de cache : la requête n’est pas de type “POST” (en fait, la méthode risque d’être “GET“), il n’y a pas de paramètre passé via la “Query String” (ceux après un point d’interrogation dans l’URL), on n’a pas affaire à un mobile accédant à une page “Wap”, et j’en passe…
• Enfin, on vérifie que le navigateur n’envoie pas un cookie contenant “comment_author_”, “wordpress_logged_in” ou “wp-postpass_” (déjà pour que le mécanisme ne s’applique pas aux utilisateurs identifiés et aux page protégées par mot de passe…).

Si vous mettez en place un mécanisme similaire à celui de WP Super Cache avec mod_rewrite utilisé, surtout faites attention à la manière d’implémenter le dernière point. Il faut mieux éviter, si le logiciel n’est pas uniquement réservé à un usage interne sur infrastructure connue, que tout cookie puisse empêcher le cache d’être utilisé.

En effet, les cookies peuvent être issus du CMS, de ses fonctionnalités, et de sa configuration… Ils peuvent aussi être issus de l’infrastructure utilisée pour le serveur web. Un exemple parmi d’autres : chez OVH, avec le mutualisé, des cookies “90plan”, “240plan” ou avec un autre nom (suivant l’offre souscrite) sont envoyés systématiquement. Ils permettent notamment que le load balancer envoie un visiteur toujours sur le même serveur web parmi tout ceux du “cluster“, et c’est très utile pour que PHP gère correctement les sessions… Voir ce twitt de Tony d’OVH et son post sur le forum OVH notamment. Pour faire bref, quand on code une site ou une application web, mieux vaut éviter de supposer que l’on connait de façon exhaustive les cookies… Ici les directives mod_rewrite générés par WP Super Cache sont 100% compatible avec le mutualisé OVH.

Le remplissage du cache et sa purge

Dans ce qui précède, je vous ai indiqué par quel mécanisme la présence d’un élément dans le cache permet d’éviter d’avoir à exécuter PHP (puisque le code mod_rewrite permet de délivrer un contenu statique).

Pour savoir comment ses fichiers sont placés, c’est relativement simple :

• À chaque fois que le contenu n’est pas trouvé dans le cache, WordPress se charge de générer dynamiquement la page, le plugin en profite simplement pour en conserver une copie toute prête pour la prochaine fois.
• Il y a également une fonctionnalité permettant au plugin de générer à l’avance des pages à partir de l’ensemble des articles. J’avoue que je ne l’utilise pas.

Pour la purge, il y a simplement un système de tâches régulières de purge des versions trop anciennes, je ne détaillerais pas ici le mécanisme du cron de wordpress. En règle générale, il reste exécuté suffisamment souvent pour que tout marche bien.

Conclusion et suite de la série liée à la performance des sites web…

En conclusion sur cet article :

• J’espère que vous avez perçu l’intérêt réel de WP Super Cache pour soulager la charge d’un serveur utilisé par une installation de WordPress.
• J’espère que vous vous intéressez sérieusement à la problématique du cache si vous utilisez ou concevez d’autres CMS que WordPress. (Au passage WordPress peut vraiment être utilisé en tant que CMS et pas simplement pour des “blogs”.)
• Si vous devez créer vous même un système de cache (et non utiliser un plugin/module), j’espère que vous vous souviendrez où vous pouvez trouver un peu d’inspiration… (WP Super Cache étant open-source.)

Dans le cadre plus large de la performance des sites web et des articles que j’ai choisi d’écrire à ce sujet :

• WP Super Cache n’est qu’un moyen (certes très efficace) d’éviter qu’un site WordPress bien visité mette facilement le serveur à genoux.
• S’assurer que le serveur utilisé pour votre site ne soit pas trop surchargé est une nécessité pour les performances, mais ça ne suffit pas…

Cette série au sujet de la performance des sites web est donc loin d’être finie, et il y a beaucoup encore à écrire à ce sujet.

Si vous voulez être tenu au courant des nouveaux articles sur ce weblog, je vous invite à revenir de temps en temps, ou à vous abonner au flux.

N’hésitez pas à m’en dire un peu plus sur votre curiosité via les commentaires… Je ne sais pas encore dans quel ordre je vais écrire les articles suivants, et il se peut que je ne pense pas à tout…

WP Super Cache avec mod_rewrite : les performances d’un site statique alors que celui ci semble dynamique
(fr) Commenter cet article - Partager - Lire un autre article (Blog de David Dallet)
(en) Comment this post - Share It - Read another post on David Dallet's Weblog