Le cache est le gain de vitesse le plus important disponible pour un site WordPress : la mise en cache full-page sert du HTML terminé sans exécuter PHP du tout, et le cache d'objets conserve les résultats de base de données en mémoire. Ce guide couvre les deux, ce qui contourne automatiquement le cache, et comment le purger et le préchauffer.
Où se trouve le cache dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Sites web dans la barre latérale gauche, puis cliquez sur le site.
- Dans le menu de gauche du site, ouvrez WordPress, puis Mise en cache.
L'adresse directe est /websites/<site-id>/cache.
Le groupe WordPress n'apparaît que pour les sites WordPress et WooCommerce. Le cache ici est un droit lié au plan : la mise en cache full-page et le cache d'objets sont inclus avec Managed WordPress. Sur les autres plans, la page affiche un panneau de mise à niveau décrivant ce qui est disponible plutôt que les contrôles.
Cache full-page
La mise en cache full-page stocke le HTML terminé d'une page et le sert directement au visiteur suivant. Pour un visiteur anonyme, cela signifie aucune exécution PHP et aucune requête de base de données du tout : la requête est traitée avant même que WordPress ne soit chargé.
La carte affiche une pastille Activé ou Désactivé, et lorsqu'elle est activée, la date d'activation, si le routage a été confirmé, et la durée de vie du cache.
Pour l'activer, cliquez sur Activer le cache full-page. Pour le désactiver à nouveau, cliquez sur Disable.
Le cache est vidé automatiquement lorsque vous publiez ou mettez à jour un article, de sorte que vos modifications apparaissent immédiatement plutôt que d'attendre l'expiration de la durée de vie.
Si votre site est principalement lu par des visiteurs anonymes, c'est l'interrupteur le plus précieux de la page. Il est fréquent que la différence soit d'un ordre de grandeur sur le temps jusqu'au premier octet, car la partie lente d'une requête WordPress est précisément celle qui ne se produit plus.
Purge et préchauffage
Deux actions apparaissent une fois la mise en cache full-page activée.
Purger le cache vide le cache immédiatement. Utilisez cette option après une modification que WordPress ne traite pas comme une mise à jour d'article : modification d'un fichier de thème, changement d'un widget, mise à jour d'un menu, ou modification d'un réglage de plugin affectant l'affichage. Le visiteur suivant sur chaque page obtient une copie fraîche.
Cache chaud précharge vos pages afin qu'elles soient déjà en cache avant qu'un visiteur ne les demande. Après le préchauffage, une bannière indique combien de pages sur le total ont été préchargées et liste les premières URL.
La séquence naturelle après une modification de design est : purger, puis préchauffer. Ainsi, personne n'a à être le visiteur malchanceux qui paie le prix du premier rendu non mis en cache.
Pour le cache en périphérie devant votre site, qui est une couche distincte, consultez Purger le cache CDN.
Ce qui n'est jamais mis en cache
Certaines URL doivent toujours exécuter PHP, car leur sortie diffère selon le visiteur ou produit des effets de bord. Ces chemins sont contournés automatiquement et vous n'avez rien à configurer :
| Chemin | Pourquoi |
|---|---|
/wp-admin/ | L'administration WordPress est toujours dynamique |
/wp-login.php | La page de connexion n'est jamais mise en cache |
/cart/ | Le panier WooCommerce est propre à chaque visiteur |
/checkout/ | Le paiement WooCommerce est propre à chaque visiteur |
/my-account/ | Les pages de compte WooCommerce sont propres à chaque visiteur |
/wp-cron.php | Les tâches planifiées doivent réellement s'exécuter |
/?wc-ajax=* | Points de terminaison AJAX WooCommerce |
Au-delà des règles de chemin, les cookies comptent. Un utilisateur WordPress connecté, ou un visiteur avec un cookie de session WooCommerce actif, reçoit toujours une réponse dynamique, même sur une page mise en cache pour tous les autres. C'est pourquoi un propriétaire de boutique parcourant son propre site ne voit souvent aucun des bénéfices alors que les visiteurs anonymes en profitent.
Comme vous êtes généralement connecté, tester le comportement du cache dans votre navigateur habituel vous induira en erreur. Testez dans une fenêtre privée, ou dans un navigateur où vous n'êtes pas connecté.
Cache d'objets
Le cache d'objets est une couche différente. Plutôt que de stocker des pages terminées, il conserve en mémoire les résultats des requêtes de base de données et les transients WordPress, afin que le travail répété ne soit pas refait.
La carte affiche une pastille Activé ou Désactivé, et lorsqu'elle est activée, la date d'activation. Utilisez Activer et Désactiver pour la modifier.
Le cache d'objets aide précisément là où la mise en cache full-page ne peut rien faire : utilisateurs connectés, écrans d'administration, et pages propres à chaque visiteur comme le panier et le paiement. Cela le rend particulièrement précieux pour les boutiques très fréquentées et les sites d'adhésion, où une grande partie du trafic est authentifiée et donc jamais mise en cache de page.
Faire fonctionner les deux ensemble est la configuration normale. La mise en cache full-page gère le trafic anonyme, et le cache d'objets accélère tout ce qui doit de toute façon exécuter PHP.
Choisir ce qu'il faut activer
- Site de contenu, lecteurs majoritairement anonymes. La mise en cache full-page est la priorité. Le cache d'objets ajoute une amélioration plus modeste par-dessus.
- Boutique WooCommerce. Activez les deux. La mise en cache full-page couvre quand même vos pages de produits et de catégories pour les visiteurs en navigation, tandis que le cache d'objets prend en charge le panier, le paiement et les pages de compte qui ne peuvent jamais être mises en cache.
- Site d'adhésion ou communautaire où presque tout le monde est connecté. Le cache d'objets fait l'essentiel du travail, car la plupart des requêtes contourneront le cache de page par conception.
Dépannage
J'ai mis à jour le site mais les visiteurs voient encore l'ancienne version. Purgez le cache, puis préchauffez-le. S'il reste obsolète, n'oubliez pas qu'il peut aussi y avoir un cache en périphérie : consultez Purger le cache CDN.
Le cache ne fait rien pour moi. Vous êtes presque certainement connecté. Vérifiez dans une fenêtre privée.
Le panier ou un formulaire se comporte bizarrement pour les visiteurs anonymes. Les chemins commerce standards sont contournés automatiquement, mais une page dynamique personnalisée ou fournie par un plugin sur une URL non standard ne l'est pas. Si une page ne doit jamais être mise en cache et ne figure pas sur la liste de contournement, il vaut la peine de le signaler au support afin que nous puissions examiner la règle.
La carte indique que le cache est inclus avec Managed WordPress. Votre plan actuel ne l'inclut pas. La bannière renvoie vers la page des plans.
Vérification du routage en attente. Le cache est activé et la confirmation du routage n'est pas encore terminée. Patientez un instant et actualisez.
Une page affiche le mauvais contenu personnalisé. Tout contenu personnalisé doit être exclu du cache de page ou rendu côté client. Si un plugin personnalise l'affichage sur une URL par ailleurs cachable sans définir de cookie de session, le cache de page ne peut pas le savoir. Testez dans une fenêtre privée et signalez-le au support si vous en trouvez un.
Pages associées
- Performance du site et APM pour mesurer si le cache a réellement aidé.
- Analytique du trafic du site pour le taux de succès du cache en périphérie.
- Activer le CDN pour ajouter un cache en périphérie devant tout cela.
- Effectuer une sauvegarde avant d'apporter des modifications plus importantes à un site en production.