Je m'intéresse ici à nouveau aux systèmes de cache côté serveur pour les CMS. On va parler de WordPress puisque c'est le plus connu mais on aurait pu prendre un autre exemple.
Pour moi, il est indispensable d'avoir un outil de cache lorsqu'on utilise un CMS qui produit des pages dynamiques. Recalculer les pages à chaque affichage en allant chercher des informations dans une base de données alors que la page n'a probablement pas bougé n'est pas une bonne chose du tout. Nous devons économiser les ressources systèmes qui seront de plus en plus précieuses.
Je n'ai pas toujours été suffisamment attentif à ça avant de me rendre compte du gâchis.
On peut envisager plusieurs méthodes :
Pour WP, il en existe plein. Je ne vais pas les lister. Ce qui est important à savoir, c'est que certains ont besoin d'exécuter une partie du code de WP pour fonctionner. C'est gourmand. Bien sûr, on voit des améliorations de performances mais ce n'est pas assez à mon goût. On peut parfois les adapter pour éviter ça.
D'autres n'ont pas besoin de charger le core nativement et utilisent quelques directives dans un fichier htaccess par exemple pour vérifier la présence de la page en cache et faire la bonne redirection. Là, on gagne réellement en performances (et surtout on économise des ressources).
Certains hébergeurs proposent des solutions qui tournent directement chez eux. On peut même parfois les piloter plus finement à l'aide d'un plugin WP (pas toujours). Je pense à Kinsta, O2Switch, Alwaysdata, etc.
Ici, on est pas directement chez l'hébergeur. On va utiliser un service supplémentaire. Certains CDN proposent eux aussi des solutions pour gérer du cache WP. C'est le cas de Cloudflare par exemple. Les CDN proposent aussi d'autres services qui peuvent être intéressants lorsqu'on atteint certains volumes ou lorsqu'on a "une clientèle" plutôt internationale.
En fonction des solutions, on aura des résultats plus ou moins importants.
Par exemple, un outil qui ira vérifier la présence du cache dans un système de fichier sera un peu plus lent qu'un outil stockant le cache en RAM.
En RAM, on pourrait parvenir à délivrer les pages à une vitesse pratiquement équivalente au statique.
Mais, n'oublions pas une chose, ce sont des outils qui eux aussi vont tourner sur des serveurs, utiliser des ressources.
Pour conclure, j'en reviens toujours au site statique (vous pensez que ça tourne à l'obsession ?) mais quand c'est possible, proposons directement un site statique. Nativement, on aura un site performant sans mettre en place une solution spécifique et sans avoir besoin de ressource complémentaire. D'ailleurs, il est possible même avec du statique d'améliorer encore les performances avec un serveur web bien configuré. Mais ... c'est encore une autre histoire.
La bonne nouvelle quand même, c'est que si vous ne pouvez pas vous passer d'un CMS qui génère des pages dynamiques (s'ils existent, c'est parce qu'ils sont tout de même utiles), un panel de solutions s'offrent à vous pour améliorer les performances, et surtout, économiser des ressources.
Dernière chose. Méfiez-vous lorsque vous êtes surpris par la réactivité d'un site web. Ce n'est pas parce que c'est rapide que c'est éco-conçu. On peut tout à fait avoir de bonnes performances sans aucune optimisation avec du matériel plus puissant. Ça, c'est du gâchis.