Un restaurant de Saint-Julien-en-Genevois change ses horaires de fermeture un mardi soir. Le gérant modifie la page, vérifie depuis son ordinateur, tout est correct. Le lendemain, un client se présente devant la porte close en montrant son téléphone : la page affiche encore les anciens horaires. Personne n'a piraté le site, rien n'est cassé. Le cache a simplement servi une version enregistrée la semaine précédente, et aucune règle de purge n'avait été configurée.
Le cache est probablement le mécanisme le plus rentable et le plus mal compris d'un site WordPress. Bien réglé, il divise le temps de réponse du serveur et absorbe les pointes de trafic sans changer d'hébergement. Mal réglé, il affiche des informations périmées, vide des paniers et casse des formulaires. WP Rocket fait partie des outils que nous installons chez nos clients, mais il arrive à un moment précis de la chaîne, et jamais en premier.
Ce qu'un cache de pages fait réellement au niveau du serveur
Sans cache, chaque visite déclenche un travail complet. Le serveur web reçoit la demande, lance l'interpréteur PHP, charge WordPress, le thème et toutes les extensions actives, interroge la base de données plusieurs dizaines de fois, assemble le résultat, puis renvoie une page HTML. Ce cycle prend typiquement plusieurs centaines de millisecondes, parfois plus d'une seconde sur un hébergement mutualisé chargé. Ce délai porte un nom, le TTFB, pour Time To First Byte : c'est le temps que met le serveur à commencer à répondre, avant même que le navigateur ait vu la première image.
Un cache de pages enregistre le résultat final de ce travail dans un fichier. Le visiteur anonyme suivant reçoit directement ce fichier, sans exécution de PHP ni requête en base. Le gain est immédiat et il porte sur toutes les pages consultées par des personnes non connectées, ce qui représente l'essentiel du trafic d'un site vitrine. C'est aussi le levier qui améliore le plus visiblement le temps d'affichage du contenu principal, mesure que nous décrivons dans notre article sur les Core Web Vitals.
Il existe une seconde couche, le cache d'objets, qui conserve en mémoire les résultats de requêtes internes à WordPress. Elle apporte un vrai bénéfice sur une boutique ou un site à forte volumétrie, quand les pages ne peuvent pas toutes être mises en cache. Elle demande en revanche un service dédié côté hébergeur, ce qui n'est pas disponible partout et ne se justifie pas pour un site de vingt pages.
Ce que WP Rocket apporte, et ce qu'il ne remplacera jamais
L'intérêt de cet outil n'est pas d'être magique, il est d'être cohérent. Il pose un cache de pages qui fonctionne, il sait précharger les pages importantes pour que le premier visiteur ne subisse pas la reconstruction, il gère la durée de conservation par le navigateur, il retarde l'exécution des scripts non essentiels, il charge les images seulement quand elles approchent de l'écran, et il se branche sur un réseau de diffusion de contenu si vous en utilisez un. Tout cela se règle depuis une interface, sans écrire de directives serveur à la main, et fonctionne chez la plupart des hébergeurs que nous rencontrons, qu'il s'agisse d'Infomaniak, d'OVH ou d'un serveur que nous administrons.
Ce qu'il ne fera pas mérite d'être dit aussi clairement. Il ne réduira pas une photographie de bandeau de quatre mégaoctets, sujet que nous traitons dans notre article sur le poids des images et le format WebP. Il ne rattrapera pas une version de langage serveur abandonnée par son éditeur, question abordée dans PHP obsolète sur WordPress. Il ne compensera pas un hébergement saturé ni un thème qui charge quinze polices. Installer un cache sur un site en désordre revient à fermer une porte sur une pièce encombrée : la vue s'améliore, le désordre reste.
Les erreurs de configuration qui cassent un site en production
La quasi-totalité des incidents que nous reprenons sur ce sujet viennent de quatre réglages activés sans exclusion.
- Les pages de panier, de commande et de compte client ont été mises en cache. Le visiteur voit alors le panier d'un autre, ou un panier vide alors qu'il vient d'ajouter un article. Ces pages doivent être exclues sans discussion, ainsi que les cookies de session correspondants.
- La minification et la concaténation des fichiers JavaScript ont été activées globalement. Elles fusionnent des scripts qui ne supportent pas de l'être, et le résultat classique est un bouton de validation qui ne réagit plus. Nous les activons progressivement, en vérifiant chaque parcours après chaque étape.
- Le report de l'exécution des scripts a été appliqué au script de protection du formulaire ou au module de paiement. Le formulaire affiche alors un message de succès sans envoyer le message, ou le paiement échoue silencieusement. Nous rencontrons régulièrement le premier cas, décrit dans notre article sur le formulaire dont le mail n'arrive jamais.
- Deux plugins de cache cohabitent, souvent parce que l'hébergeur en fournit un et qu'un prestataire en a ajouté un second. Chacun invalide le travail de l'autre, et le résultat pratique est une absence de cache accompagnée de pages blanches intermittentes. Nous en retirons toujours un.
La purge, ce réglage que personne ne configure et que tout le monde subit
Le cas des horaires de restaurant cité en ouverture est une affaire de purge. WordPress vide normalement le cache d'une page lorsqu'elle est enregistrée, mais un constructeur de pages, un affichage de produits ou un bloc d'articles récents échappent souvent à ce mécanisme : la page modifiée est bien rafraîchie, la page d'accueil qui reprend son contenu ne l'est pas.
Nous configurons donc explicitement ce qui doit être vidé et quand, et nous vérifions ce comportement après chaque mise à jour du thème ou du constructeur. Nous validons également le déroulement complet sur un environnement de recette, plutôt que directement en production un vendredi après-midi, une pratique que nous détaillons dans notre article sur le staging WordPress. Enfin, nous laissons au gérant un moyen simple de vider le cache lui-même, avec la consigne de nous appeler si le problème persiste après cette manipulation.
Comment nous installons cette couche dans une mission
Nous commençons par un état des lieux : quels caches sont déjà actifs, y compris celui de l'hébergeur, quel est le temps de réponse du serveur à vide, quelle version de langage serveur est en service, et combien pèsent les pages les plus consultées. Nous corrigeons ce socle avant toute chose, car un cache installé sur des images non préparées masque le problème et rend la mesure suivante illisible.
Nous activons ensuite le cache de pages seul, nous mesurons, puis nous ajoutons les optimisations une par une en testant à chaque étape les trois parcours qui comptent : l'affichage de la page d'accueil, l'envoi du formulaire de contact, et le passage de commande complet si le site vend. Nous documentons les exclusions dans le dossier du client, afin que le réglage survive à un changement d'interlocuteur. La mesure de vitesse nous sert de jauge de contrôle à chaque étape, sans jamais devenir un objectif en soi.
Ce travail vit dans la maintenance WordPress à 500 HT / an, qui comprend les mises à jour, les sauvegardes hors du serveur d'hébergement, la supervision et le relevé de performance mensuel. Sur un site que nous créons dès 900 HT, la couche de cache est posée dès la mise en ligne, ce qui coûte toujours moins cher que de l'empiler six mois plus tard sur un site devenu lourd. Nous intervenons à distance dans toute la France et en Suisse, avec le même montant hors taxes en euros et en francs.
Si votre site est lent, ou si vous soupçonnez qu'il affiche des informations périmées, envoyez-nous son adresse. Nous vous dirons si un cache suffit, ou s'il faut d'abord alléger le thème et les images.