Comprendre la mise en cache dans WordPress, partie 1
En mai, j’ai écrit un article sur l’utilisation de l’API WordPress Transients. Je résume l’article ainsi :
Pour simuler les cookies et leur fonction d’expiration, l’utilisation de transitoires WordPress peut être une solution viable.
https://wordpress.mediadoma.com/fr/utiliser-des-transitoires-wordpress-au-lieu-de-cookies/
Bien que le but de l’article était de jeter les bases de la façon dont nous pouvons concevoir une classe pour travailler avec l’API Transients afin de simuler le comportement des cookies, l’un des effets secondaires de l’article est qu’il n’a pas fait un bon travail d’expliquer comment l’API Transients (et, par procuration, comment MySQL) fonctionne.
Cela a été porté à mon attention par e-mail par David à UpDraft Plus.
J’ai donc pensé qu’il était utile de parler du concept de mise en cache d’un point de vue pratique, de la manière dont il est implémenté dans WordPress, puis peut-être de voir comment utiliser des plugins ou des technologies plus récentes pour mieux alimenter nos sites et applications et avoir une meilleure compréhension.
Comprendre la mise en cache : les bases
Le concept de mise en cache est relativement simple. Mais je pense que c’est mieux démontré en parlant d’abord de la sérialisation et de la récupération des données sans mise en cache.
Sans mise en cache
Écrire des données
Chaque fois que vous écrivez des informations dans la base de données sous-jacente, vous enregistrez un enregistrement (ou une série d’enregistrements) dans la base de données.
Par exemple, lorsque vous publiez une publication, vous allez écrire un enregistrement dans la table des publications et la table des métadonnées de publication, chacune étant liée par un ID de publication.
La façon dont ils sont liés n’est pas importante pour ce post.
Au lieu de cela, la chose à comprendre dans cette partie est que lorsque les données sont écrites dans la base de données, au moins un enregistrement, sinon plusieurs, est créé.
Lecture de données
Lorsqu’un visiteur arrive sur le site pour lire ce message particulier, toutes les informations pour ledit message seront demandées à partir de la base de données, servies à l’application WordPress, puis rendues sur le front-end.
Considérez tout ce processus comme un voyage :
- ❓le visiteur demande la page,
- 🔍 le serveur web a identifié quelle page charger,
- 📂 la page est demandée à partir de la base de données à partir de plusieurs tables,
- 🏗 les données sont assemblées et envoyées à l’application principale,
- 🖥 les données sont présentées à l’utilisateur.
Ainsi, le voyage commence lorsque l’utilisateur demande une page et se termine lorsque l’information lui est présentée dans son navigateur.
C’est un voyage
Et, sans mise en cache, cela se produit pour chaque utilisateur. Autrement dit, pour chaque utilisateur qui visite votre site, un voyage doit être effectué.
Cela peut devenir très coûteux en termes de ressources et de temps (notamment en fonction de la taille de votre base de données).
Mais c’est là que la mise en cache peut entrer en jeu.
Avant de se lancer dans la mise en cache
L’idée derrière la mise en cache est de rendre tout ce processus plus rapide. Autrement dit, si nous savons qu’un voyage est sur le point de se produire, nous pouvons conserver les informations dans un endroit tel qu’elles soient déjà assemblées et plus rapides à récupérer.
Avant d’en parler cependant, ce que je ferai dans le prochain post, notez que cela revient à faire un tour sur le disque dur du serveur sur lequel le site est hébergé à chaque fois que le site est visité.
Parce qu’en fin de compte, la base de données, les fichiers et tous les actifs nécessaires pour alimenter le site résident sur un disque dur. Et oui, des choses comme les disques SSD peuvent accélérer ce processus, ce n’est toujours pas aussi optimal que possible.
Et c’est là que la mise en cache entre en scène. Pour mieux comprendre l’API Transients, il est important de comprendre la mise en cache, qui nécessite d’abord une compréhension de base de la façon dont les choses fonctionnent sans mise en cache.
C’est un abécédaire
Considérez donc cela comme une introduction de base sur le fonctionnement d’un site basé sur une base de données sans mise en cache. Et puis nous nous appuierons davantage sur cela dans le prochain post.