Quand il s’agit de performance web, la mise en cache WordPress est juste une de ces choses que chaque propriétaire de site doit traiter à un moment ou à un autre. Nous aimons WordPress, mais ce n’est certainement pas la plateforme la plus rapide, surtout si vous la comparez à un site complètement statique. L’une des raisons est simplement parce qu’elle est construite sur PHP qui ne peut exécuter les choses aussi rapidement. Nous avons vu des améliorations massives avec PHP 8.0 et 8.1, mais si vous ne mettez pas correctement votre site en cache, il peut quand même se mettre à ramer.
Ne serait-ce pas bien si vous n’aviez pas à vous soucier de savoir quelle extension de mise en cache est la meilleure ? Et bien, chez Kinsta, nous nous occupons de la mise en cache pour vous, afin que vous puissiez vous concentrer sur la croissance de votre entreprise.
Qu’est-ce que le cache WordPress ?
La mise en cache est le processus de stockage des ressources d’une requête et de réutilisation de ces ressources pour des requêtes ultérieures. Fondamentalement, cela réduit la quantité de travail nécessaire pour générer une page.
Pourquoi devriez-vous utiliser le cache ? C’est simple, la mise en cache rend les sites Web WordPress plus rapides et réduit la charge sur le serveur Web. C’est la raison pour laquelle chaque site devrait s’efforcer d’utiliser autant de cache que possible. De plus, dans le cas de la mise en cache CDN, elle réduit également la quantité de bande passante requise pour générer une page en stockant des ressources statiques externes à celle de votre hébergeur WordPress.
Aucune extension de mise en cache WordPress nécessaire chez Kinsta
C’est exact ! Si vous hébergez votre site WordPress chez Kinsta, vous n’avez pas besoin de vous soucier des extensions de mise en cache compliquées et déroutantes. Cela est dû au fait que nous avons déjà mis en place différents types de mise en cache. Vous pouvez enfin arrêter de chercher sur Google les « meilleures extensions de cache de 2023 » et vous concentrer sur des tâches plus productives.
Chez Kinsta, nous utilisons les quatre types de cache suivants, qui se font tous automatiquement au niveau logiciel ou serveur :
Beaucoup de nos clients signalent d’énormes diminutions des temps de chargement simplement en migrant vers Kinsta. Voici un exemple d’un site qui a connu une augmentation de 212,5 % de sa performance. Et ceci sans aucun plugin de cache installé.
Il y a d’autres variables impliquées dans ces baisses de temps de chargement également, mais la mise en cache en est une grande partie de cela. Nous ne disons pas que toutes les extensions de mise en cache sont mauvaises, en fait, c’est souvent dû au fait que l’utilisateur ne configure pas correctement l’extension de cache, ce qui ralentit son site WordPress. Avez-vous déjà essayé de configurer W3 Total Cache ? Cela peut franchement devenir très vite déroutant.
Ne vous fiez pas à notre parole
Et en ce qui concerne la performance, ne nous croyez pas sur parole, jetez un coup d’œil à certains de ces témoignages de personnes qui ont migré chez Kinsta. Tous ceux qui n’utilisent plus d’extension de mise en cache.
An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀
— WPColt (@WPColt) January 3, 2018
Quite impressed what @googlecloud and @kinsta can pull of for #WordPress hosting! #DevOps #Cloud #WPDev #webdevelopment pic.twitter.com/Cr7UMaHdpH
— Neuralab (@Neuralab) July 22, 2017
@TheSportReview's new @Googlecloud based @kinsta environment handled the post-match @ManUtd v @ChelseaFC traffic spike in style 👌⚽ pic.twitter.com/kJewykSqaV
— Martin Caparrotta (@MartinCap) April 16, 2017
60%+ drop in @pingdom load times for @voompla after move to @kinsta + @CloudFlare CDN + site optimization! support by @tomzur @MarkGavalda
— Palash Bakshi (@ppbakshi) September 11, 2016
Types de Cache WordPress
Plongeons maintenant dans chaque type de cache WordPress que vous rencontrerez régulièrement chez Kinsta. Comprendre ce que fait chaque couche de mise en cache vous aidera à résoudre les problèmes liés à la mise en cache et à assurer le bon fonctionnement de votre site.
Cache Bytecode
Le cache Bytecode stocke le code PHP compilé de sorte que la prochaine fois qu’il est utilisé, l’étape de compilation peut être ignorée. Chez Kinsta, nous avons activé OPcache sur PHP 7.3 y 7.4 (et ce sera activé aussi dans les nouvelles versions de PHP dès leur sortie sur notre plateforme).
Mise à jour : PHP 8.1 (version officielle) est maintenant disponible pour tous les clients de Kinsta. PHP 7.4 n’est plus supporté chez Kinsta. Veuillez noter que nous prenons en charge les versions de PHP 8.0, 8.1 et 8.2.
Lorsqu’un fichier ou un script PHP est traité, il doit d’abord être compilé en un opcode lisible par la machine. Ce qu’OPcache fait est de stocker le opcode converti afin que PHP puisse ignorer l’étape de compilation la prochaine fois que ce fichier ou script spécifique est nécessaire. L’utilisation d’OPcache améliore significativement les performances de PHP. Cependant, cela signifie que les modifications apportées aux fichiers PHP ne sont pas reflétées immédiatement. Pour cette raison, OPcache est désactivé sur les sites de développement WordPress de Kinsta.
En savoir plus sur la façon dont OPcache accélère les applications PHP.
Cache Objet
Le cache objet stocke les résultats des requêtes de la base de données de sorte que la prochaine fois que ce bit particulier de données est nécessaire, il peut être livré à partir du cache sans interroger la base de données. Cela accélère les temps d’exécution PHP et réduit la charge de votre base de données de WordPress.
WordPress possède un cache objet intégré : WP_Object_Cache. Cependant, ce cache objet ne ne stocke que des objets pour le chargement d’une page seule. Le but du cache est de s’assurer que la base de données n’est pas interrogée exactement de la même manière plusieurs fois pendant le chargement d’une seule page. Cependant, les objets mis en cache ne sont pas utilisés après ce chargement de page unique. Bien que cette fonction soit utile dans WordPress, la mise en cache d’objets est beaucoup plus puissante si les objets du cache peuvent être utilisés entre plusieurs chargements de pages.
Vous pouvez modifier ce comportement et réutiliser les objets mis en cache pour plusieurs chargements de pages en passant du cache d’objets intégré de WordPress à une solution externe. Ceci est fait en déposant un script de mise en cache dans le répertoire /wp-content/. Il existe des options de cache d’objets basées sur des extensions telles que W3 Total Cache.
Nos clients de Kinsta peuvent également acheter notre module supplémentaire Redis et l’installer en même temps que PHP 8.0 ou 8.1. Redis est une structure de données en mémoire open-source, utilisée comme base de données, cache et courtier de messages. Consultez notre article sur comment utiliser Redis comme cache d’objets persistants si vous voulez en savoir plus.
Cache de page
La mise en cache des pages stocke tout le HTML d’une page afin que les pages suivantes puissent être générées sans que WordPress n’ait à générer la page.
Lorsque vous chargez un site Web WordPress, WordPress doit traiter un grand nombre de fichiers PHP et interroger la base de données plusieurs fois. Pour les pages qui ne sont pas constamment mises à jour, c’est du gaspillage. Il est beaucoup plus efficace de générer chaque page une seule fois, puis de stocker cette page et la livrer aux visiteurs suivants. C’est ce que la mise en cache des pages fait.
Les avantages de la mise en cache des pages incluent :
- Le chargement des pages est beaucoup plus rapide.
- Il en résulte une réduction drastique de la charge des serveurs et la possibilité de gérer beaucoup plus de trafic.
Nos serveurs utilisent le nginx fastcgi cache module pour la mise en cache des pages, et il est configuré pour expirer toutes les heures par défaut. Toutefois, les clients peuvent modifier l’expiration du cache des pages à tout moment dans le tableau de bord MyKinsta. Pour modifier l’heure d’expiration du cache des pages, rendez-vous sur la page « Outils » de votre site, cliquez sur le menu déroulant « Modifier » sous « Cache du site », puis cliquez sur « Modifier l’expiration du cache ».
Dans la modale « Modifier l’expiration du cache », sélectionnez le temps d’expiration souhaité et cliquez sur « Modifier l’expiration ». Nous proposons des options allant de 1 heure à 7 jours. Pour les sites qui ne changent pas souvent, il peut être avantageux en termes de performance d’avoir une expiration de cache plus longue.
Le cache de page est configuré pour fonctionner dès le départ avec les sites WordPress standards, BuddyPress, WooCommerce et Easy Digital Download. Cela signifie que les pages telles que le tableau de bord de WordPress, les boutiques WooCommerce, les forums BuddyPress pour les utilisateurs connectés, et plus encore, sont automatiquement ignorées du cache de page. Si vous utilisez une installation WordPress hautement personnalisée, des pré-requis supplémentaires aux réglages du cache de page peuvent être nécessaires, et notre équipe de support peut vous aider avec cela.
Par défaut, la mise en cache des pages est désactivée sur les sites de staging Kinsta. Dans certains cas, il est utile d’activer la mise en cache des pages sur les sites de staging pour effectuer des tests. La mise en cache des pages pour les sites de staging peut être activée dans le tableau de bord MyKinsta.
Cache CDN
La mise en cache CDN stocke les fichiers du site Web (tels que JavaScript, CSS et fichiers multimédia) sur un réseau de diffusion de contenu pour une livraison plus rapide aux utilisateurs qui sont géographiquement éloignés de l’emplacement du serveur hôte. Lorsque quelqu’un essaie d’accéder à un site Web, ces fichiers sont livrés à partir du CDN plutôt que d’être livrés à partir du serveur qui héberge le site Web. En savoir plus sur les raisons pour lesquelles vous devriez utiliser un CDN.
Un réseau de diffusion de contenu (CDN) offre deux avantages principaux :
- Il réduit les ressources du serveur nécessaires pour charger un site Web. Puisque le CDN fait le travail, le serveur Web n’a pas à le faire.
- Il permet aux ressources d’être distribuées à partir d’emplacements partout dans le monde, ce qui accélère les performances du site Web pour les utilisateurs qui sont géographiquement éloignés du serveur hébergeant le site Web.
Il existe deux types de base de CDN: ceux qui sont simplement des CDN et ceux qui offrent un CDN avec des caractéristiques de sécurité. Voici quelques exemples communs de chacun d’entre eux:
- CDN standard : Stackpath, CloudFront.
- CDN plus la sécurité : Kinsta CDN (Cloudflare), Sucuri, Akamai (facultativement).
Le premier type de CDN est mis en place en créant des URL CDN qui sont utilisées pour accéder aux ressources du site Web. La manière exacte de l’activer varie d’un CDN à l’autre. L’idée de base est que les URLs des ressources statiques seront remplacées par l’URL CDN afin que les ressources soient extraites du CDN. Un CDN standard ne met généralement en cache que les fichiers statiques comme les fichiers JS, CSS et les fichiers multimédias.
Le second type de CDN sert de serveur proxy complet. Cela signifie que chaque requête doit traverser les serveurs du fournisseur avant d’arriver sur les serveurs de Kinsta. Ceci est activé en utilisant les serveurs de noms du fournisseur de CDN, de sorte que le fournisseur de CDN a le contrôle total des DNS du site Web. Cela permet au fournisseur de faire beaucoup de choses qu’un simple CDN ne peut pas faire, comme filtrer le trafic des mauvaises adresses IP, offrir une protection DoS/DDoS, ou même stocker une page complète en cache sur le CDN. Notre CDN Kinsta est propulsé par Cloudflare, un service de proxy de performance/sécurité.
Cache CDN avancé
Si vous utilisez un serveur CDN proxy tel que Cloudflare ou Sucuri, vous avez la possibilité de créer un cache de page complet sur le CDN. L’utilisation d’un DNC comme Cloudflare ou Sucuri pour mettre en cache une page HTML complète décharge complètement le travail de nos serveurs et est une excellente solution pour un site qui s’attend à une augmentation massive du trafic.
- Sucuri configure le cache de page complète si le niveau du cache est réglé sur « Activé ».
- Cloudflare nécessite la mise en place de règles de page pour que la mise en cache de page entière fonctionne. Les règles doivent utiliser un niveau de cache « Cache Everything ».
En-tête de réponse Cache Kinsta
Vous pouvez tester pour voir si votre page est servie à partir du cache Kinsta en regardant vos en-têtes de réponse HTTP. Kinsta ajoute un en-tête X-Kinsta-Cache. Dès la première demande à une page non mise en cache, il affichera MISS, comme indiqué ci-dessous.
À la deuxième demande à la même page, l’entête X-Kinsta-Cache affichera HIT, ce qui signifie qu’elle est servie à partir du cache.
Et si vous lisez notre article sur comment obtenir la note de 100/100 dans Google PageSpeed Insights, vous saurez que Kinsta a également des optimisations supplémentaires au niveau du serveur pour corriger automatiquement les avertissements suivants que vous connaissez peut-être :
- Enable Compression (Kinsta a déjà activé Gzip sur tous les serveurs, pas besoin de l’activer)
- Reduce server response time (Kinsta est déjà très rapide, dans les paramètres acceptables de Google sans aucune optimisation)
- Expires Headers (pas besoin d’activer car Kinsta a activé les en-têtes de mise en cache au niveau du serveur)
Par exemple, notre site de test obtient un score de 100/100 sur PageSpeed Insights sans qu’aucune extension de mise en cache ne soit activée. La mise en cache de WordPress est gérée par Kinsta au niveau du serveur.
Paramètres de cache Kinsta
Vous vous demandez peut-être comment contrôler le cache de Kinsta. Il y aura bien sûr des moments où vous aurez besoin de le vider, en particulier lors du dépannage. Vous avez deux options faciles. Vous pouvez vider votre cache du tableau de bord MyKinsta ou utiliser le mu-plugin de Kinsta.
Effacer le cache WordPress
Pour effacer manuellement votre cache de page complète, vous pouvez le faire à partir du tableau de bord MyKinsta. Il suffit de cliquer sur votre site, de cliquer sur les outils et de cliquer sur le bouton « Effacer le cache ».
Par défaut, la mise en cache est désactivée sur les environnements de staging WordPress Kinsta. Si vous souhaitez tester la fonctionnalité de mise en cache des pages sur un site de staging, vous pouvez activer la mise en cache en utilisant l’outil « Cache du Site » dans le tableau de bord MyKinsta. Une fois la mise en cache activée pour un environnement de staging, vous pouvez utiliser le bouton « Effacer le cache » pour vider le cache comme dans l’environnement de production.
MU-plugin Kinsta
La deuxième option que vous avez est d’utiliser le mu-plugin de Kinsta. Quoi ? Oui, techniquement c’est un plugin de cache, mais ce n’est pas une extension de cache typique, car elle fonctionne au niveau du serveur.
Par défaut, le mu-plugin de Kinsta est installé sur chaque site que nous hébergeons et qui est disponible sur le côté gauche de votre tableau de bord d’administration WordPress. Ceci est utilisé pour effacer intelligemment le cache sur les pages appropriées de votre site Web. L’extension est nécessaire pour assurer le bon fonctionnement de votre site dans notre environnement. N’oubliez pas non plus que le cache de page expire toutes les 1 heure par défaut.
L’extension vous permet également de purger le cache directement depuis votre barre d’administration WordPress. Cela serait probablement l’une des plus grandes raisons de l’utiliser, car vous n’aurez pas à sauter dans le tableau de bord MyKinsta. Vous pouvez le faire à partir de votre site.
Elle vous permet également de configurer des règles de mise en cache personnalisées. En fonction de la configuration de votre site, des règles de mise en cache supplémentaires peuvent être nécessaires. Vous pouvez ajouter des chemins personnalisés pour purger chaque fois que votre site est mis à jour.
Vous pouvez également contacter notre équipe de support si vous avez besoin d’une certaine page ou URL exclue du cache.
Environnement de staging Kinsta
Par défaut, les environnements de staging sur Kinsta ont la mise en cache des pages désactivée. Cela facilite le développement et le débogage de votre site WordPress sans avoir à vider manuellement le cache après chaque modification. Dans certains cas, vous souhaiterez peut-être activer la mise en cache des pages dans un environnement de staging pour effectuer un test de vitesse précis pour une page mise en cache sans mettre votre site en ligne.
Pour activer la mise en cache des pages dans un environnement de staging, accédez à Sites > Outils dans MyKinsta et cliquez sur le bouton « Activer le cache ». Lorsque la mise en cache est activée sur le staging, vous pouvez utiliser le bouton « Vider le cache » pour purger le cache.
Statistiques du cache Kinsta
Vous pouvez vous analyser la qualité de la mise en cache de votre site WordPress dans MyKinsta Analytics. La pile de contenu du cache vous permet de voir l’état de chaque requête, qu’il s’agisse d’un HIT, BYPASS, MISS, ou EXPIRED. Vous pouvez filtrer les données par 24 heures, 7 jours ou 30 jours.
Le tableau des composants du cache vous donne un aperçu rapide de votre taux de mise en cache. Plus le nombre de requêtes que vous servez à partir du cache est élevé, mieux c’est.
Mettre en cache les pages 404
Les pages 404 peuvent demander beaucoup de ressources. Beaucoup de sites WordPress, en particulier les sites à grand nombre de membres, génèrent plus d’erreurs 404 que vous ne le pensez. Peut-être avez-vous changé l’emplacement d’une page et oublié d’ajouter une redirection, ou vous avez un mauvais lien sur quelque chose que vous avez partagé sur les médias sociaux. En d’autres termes, il y a beaucoup de choses qui font qu’un visiteur se retrouve sur votre page 404. Ces pages ont également tendance à avoir des requêtes pour extraire d’autres résultats de recherche qui sont ensuite affichés depuis la base de données.
Pour assurer une meilleure performance sur votre site WordPress, Kinsta met en cache les pages 404 pendant 15 minutes. La valeur de l’en-tête X-Kinsta-Cache affichera un HIT, ce qui signifie que la page est servi depuis le cache. Si vous créez une page qui était auparavant une 404, le cache est purgé immédiatement.
Notre outil MyKinsta analytics peut vous aider à déterminer le nombre exact d’erreurs 404 qui se produisent sur votre site.
Il est important de préciser cependant que nous ne mettons pas toutes les requêtes 404 en cache. Il y a deux types différents : ceux des pages PHP qui atterrissent sur votre page 404, et ceux des fichiers ou images manquants qui n’existent plus ou qui ont été déplacés. Nous mettons en cache les pages 404, les requêtes en 404 de fichiers et images manquants sont traitées différemment.
Par conséquent, vous pouvez utiliser le « Top des erreurs 404 » pour mieux déterminer où et quelle en est la cause.
Vous pouvez également vérifier les erreurs 404 dans Google Search Console ou installer un plugin tiers tel que Redirection qui enregistre les erreurs 404. Cependant, n’oubliez pas que de tels plugins ont également un impact sur les performances. Il est préférable de s’appuyer sur un outil au niveau du serveur.
Créez un template 404 simple qui évite si possible d’interroger la base.
BYPASS sur les requêtes POST pour le Cache
Nous voulons que nos analyses et nos statistiques de mise en cache soient aussi précises que possible. C’est important parce que lors du dépannage des problèmes de performances, vous examinerez typiquement le rapport HIT total de votre cache, que vous voulez être aussi élevé que possible. Par conséquent, les demandes POST sont incluses dans nos rapports.
Les requêtes POST ne peuvent pas être mises en cache, à l’exception de certaines configurations hautement spécialisées. La valeur de l’en-tête X-Kinsta-Cache affichera un BYPASS pour ces requêtes. Il ne faut pas les confondre avec les articles de blog ou tout autre type de article WordPress (qui peuvent être mis en cache). Une requête POST est utilisée pour envoyer des données au serveur. Ainsi, par exemple, les données envoyées lorsque vous soumettez un formulaire Web sont stockées dans le corps de la requête HTTP.
Résumé
Avec un peu de chance, vous comprenez maintenant un peu mieux le cache WordPress et les quatre types différents que vous rencontrerez régulièrement chez Kinsta : la mise en cache bytecode, la mise en cache d’objets, la mise en cache de pages et la mise en cache CDN.
Si vous en avez assez de jouer avec les extensions de mise en cache WordPress typiques et que vous voulez simplement un site rapide dès le départ, nous vous recommandons d’essayer Kinsta ! Il y a une raison pour laquelle nous avons été récompensés du statut “top tier” dans la performance de WordPress 4 années de suite par ReviewSignal. Et c’est dû au fait que nos serveurs sont optimisés sur la plateforme Google.
La section supérieure des « Bypasses » du cache vous permet de voir quelles requêtes ne sont pas servies à partir de la mémoire cache. Il s’agit généralement des tâches CRON, des requêtes admin-ajax, des pages de paiement eCommerce, des chaînes de requête, des paramètres UTM, etc.