31 octobre 2022

Comment fonctionne la mise en cache dans WordPress ?

Explication des différentes techniques de mise en cache dans WordPress et comment s'en passer avec un code d'application approprié.

La mise en cache peut donner l'impression qu'elle est le "Saint Graal" pour tous les problĂšmes de performances. Sans surprise, les gens lĂšvent un sourcil quand je dis "ArrĂȘtez d'utiliser la mise en cache"Dans mes prĂ©sentations ou consultations.

Cependant, comme nous l'avons toujours expliqué partout, une grande partie de notre succÚs en tant que société d'hébergement orienté performance Web est due aux mécanismes et technologies de cache, allant de Cache PHP comme Zend Opcache à Cache pleine page de niveau entreprise comme Varnish Cache.

Il n'est donc pas difficile de risquer dans certains contextes d'ĂȘtre accusĂ© d'hypocrisie avec des plaintes telles que : "Pourquoi, n'avez-vous pas dit que la mise en cache amĂ©liore les performances et rĂ©sout les problĂšmes ? »

Il est donc temps de clarifier ce que je veux vraiment dire par ce sujet, quand et Ă  quoi il doit servir. Et peut-ĂȘtre le plus important, quand non utilisez la mise en cache et recherchez des solutions de contournement directement du cĂŽtĂ© du dĂ©veloppement.

Nous, en tant que sociĂ©tĂ© d'hĂ©bergement et d'ingĂ©nierie systĂšme, rĂ©solvons les problĂšmes cĂŽtĂ© systĂšmes sans entrer dans le cĂŽtĂ© dĂ©veloppement (si ce n'est pour des requĂȘtes uniques, ou de trĂšs petits bugs) sur les sites clients qui se plaignent de problĂšmes de performances et de vitesse, il est donc normal que Les techniques de mise en cache peuvent cacher les problĂšmes du cĂŽtĂ© de l'application, exactement comment la poussiĂšre se cache sous le tapis.

Le problÚme demeure, mais en fait il ne crée pas de problÚmes tangibles et le client et ses visiteurs sont heureux de consulter des sites ou de faire des achats sur des sites qui ne se déconnectent pas. Cependant, nous avons toujours aimé une approche adéquate et axée sur les performances de la part des développeurs.

Quand utiliser la mise en cache pleine page ?

Commençons par le plus grand de tous. Le cache de page complĂšte ou simplement la mise en cache de page est une technique dans laquelle vous stockez temporairement une version prĂ©-gĂ©nĂ©rĂ©e d'une page pour fournir exactement le mĂȘme code (HTML) aux visiteurs dans un laps de temps limitĂ©.. Voici comment fonctionne le cache pleine page :

  1. Le visiteur A visite abc.com/page. Cette page n'est pas mise en cache, atteint PHP et est gĂ©nĂ©rĂ©e Ă  partir de la base de donnĂ©es. Avant d'ĂȘtre servi au visiteur A, il est Ă©galement mis en cache pleine page avec une expiration de 10 minutes.
  2. Le visiteur B visite abc.com/page 2 minutes aprĂšs le visiteur A et est alors servi avec la mĂȘme page, mais cette fois directement depuis le cache. Les pages servies aux visiteurs A et B sont identiques.
  3. Le visiteur C visite abc.com/page 15 minutes aprĂšs le visiteur A et parce que la version en cache de la page a expirĂ©, la requĂȘte atteint Ă  nouveau PHP et la page est rĂ©gĂ©nĂ©rĂ©e tout comme le visiteur A.

Étant donnĂ© que tous ceux qui visitent cette page dans le laps de temps oĂč une page en cache valide existe, la page peut ĂȘtre livrĂ©e trĂšs rapidement.

Pratiquement aucune ressource n'est utilisée pour fournir une page mise en cache. La mise en cache de la page entiÚre peut donc améliorer les performances et, plus important encore, l'évolutivité. Cela peut sembler trÚs intéressant, mais la mise en cache pleine page présente également de gros inconvénients.

  1. Si vous souhaitez fournir un contenu dynamique, personnalisĂ© ou autrement diffĂ©rent Ă  diffĂ©rents utilisateurs, cela doit ĂȘtre adressĂ© avec javascript (ajax) qui est exĂ©cutĂ© aprĂšs que le document HTML a Ă©tĂ© livrĂ© au visiteur. Cela peut fonctionner correctement, mais cela nĂ©cessite une autre demande supplĂ©mentaire au serveur. Si vous utilisez la mise en cache pour Ă©viter d'Ă©crire du code rapide, vous continuerez Ă  rencontrer des problĂšmes de performances avec vos requĂȘtes ajax dynamiques.
  2. Ce n'est pas parce que quelque chose fonctionne rapidement pour vous qu'il est rapide pour tout le monde. Les sites Web n'ont pas un seul point d'entrĂ©e et les visiteurs accĂšdent Ă  votre site via une variĂ©tĂ© de pages. Cela est particuliĂšrement vrai pour WooCommerce, oĂč les visiteurs utilisent Google et parcourent les pages de produits. Ou, si vous effectuez des achats Google sur le catalogue complet avec des liens directement vers les pages de produits. Pour rĂ©soudre ce problĂšme, certaines personnes essaient mĂȘme de le rĂ©soudre en "leurrant" le cache de la page entiĂšre en utilisant des araignĂ©es pour indexer l'ensemble du site afin de s'assurer que chaque page est mise en cache Ă  l'avance. En pratique, cela ne fonctionne pas bien. Il est vulnĂ©rable, difficile Ă  installer et Ă  configurer correctement, difficile Ă  entretenir et chronophage, et totalement inutile.
  3. Vous perdez le contrÎle des performances réelles de votre site Web et du fonctionnement du code (ou ne fonctionne pas comme il le devrait). Si vous utilisez la mise en cache pleine page, vous perdez le sens du temps de réponse réel de votre site et de la qualité de votre code. L'expérience montre qu'un manque de concentration sur les performances réelles est la principale raison pour laquelle les sites plantent des jours comme le Black Friday ou lors du déploiement de grandes campagnes.

Qu'en est-il des plugins de mise en cache comme W3 Total Cache ?

Les plugins WordPress comme W3 Total Cache fonctionnent comme toutes les autres pages de cache. Ils stockent une version pré-générée d'une page dans le systÚme de fichiers ou la mémoire et l'offrent aux utilisateurs jusqu'à expiration. W3 Total Cache est utilisé par 1 million de sites Web, mais cela ne signifie pas que c'est une bonne idée. Surtout si vous utilisez un hébergement rapide.

W3 Total Cache est un plugin trĂšs volumineux, et pour la plupart des sites, il ajoute simplement beaucoup de code inutile au site Web. Plus il y a de code, plus les choses peuvent mal tourner. Si vous deviez vraiment mettre en cache toute la page, cela ne devrait pas ĂȘtre fait dans la partie PHP de votre application car PHP est lent. La mise en cache de la page complĂšte doit ĂȘtre effectuĂ©e aussi prĂšs que possible de l'utilisateur sur le serveur Web (NGINX dans notre cas).

W3 Total Cache consiste à charger des pages en moins de 2 secondes en affichant un thÚme comme TwentySixteen. Pour clarifier, un test similaire sur nos serveurs sera livré en environ 150 millisecondes sans l'utilisation de la mise en cache, pas de secondes.

Alors, quand devriez-vous utiliser la mise en cache pleine page et pourquoi ?

La mise en cache de la page entiĂšre a Ă©tĂ© crĂ©Ă©e pour redimensionner les sites Web avec trĂšs trafic pour gĂ©rer plus facilement les pics de trafic. La mise en cache pleine page a Ă©tĂ© inventĂ©e lorsque les gens utilisaient le Web principalement pour lire des articles de presse. GĂ©nĂ©rer un contenu unique pour chaque visiteur n'est pas judicieux pour les journaux, car leurs pages sont pour la plupart statiques avec de rares mises Ă  jour. Pour ce scĂ©nario, la mise en cache d'une page complĂšte est tout Ă  fait appropriĂ©e, mais uniquement pour les sites qui ne nĂ©cessitent pas d'utilisateurs connectĂ©s ou de contenu personnalisĂ©. En fait, les sites Web d'aujourd'hui ressemblent davantage Ă  des applications.

Les sites Web contemporains sont plus complexes, dynamiques et de plus en plus personnalisĂ©s. Le code devient de plus en plus complexe, et ajouter des mĂ©canismes encore plus complexes (techniques de mise en cache de lecture) sur du code dĂ©jĂ  complexe n'est pas toujours une bonne idĂ©e. En pratique, un autre niveau de technologie sera ajoutĂ© qui introduit de nouveaux points de dĂ©faillance uniques, nĂ©cessite une maintenance, des mises Ă  jour et des opĂ©rations dĂ©diĂ©es. Cela rendra les bogues plus difficiles Ă  corriger et le dĂ©veloppement gĂ©nĂ©ral plus difficile (plus coĂ»teux). Si vous basez vos performances sur la mise en cache pleine page, je peux fermer pour m'assurer que la solution s'effondrera si la mise en cache cesse de fonctionner.

La rĂ©ponse Ă  la question est donc d'Ă©crire du code et des requĂȘtes de bonne qualitĂ© et de garder Ă  l'esprit que la solution doit ĂȘtre Ă©volutive. Il est acceptable d'utiliser la mise en cache d'une page complĂšte pour gĂ©rer les pics de trafic soudains, tout comme les journaux l'ont fait et le font toujours.

Vous devriez pouvoir dĂ©sactiver la mise en cache d'une page entiĂšre un jour normal, avec un trafic normal, sans vous inquiĂ©ter. Et si vous le faites correctement, vous devriez pouvoir dĂ©sactiver la mise en cache d'une page entiĂšre mĂȘme les jours de pointe, sans planter votre site Web.

Sur le serveur gĂ©rĂ©, la plupart des magasins fonctionnent sans mise en cache de la page complĂšte, mĂȘme les jours de fort trafic comme le Black Friday.

WordPress Object Cache : Vous l'utilisez sans le savoir

Beaucoup de gens ignorent que le cache d'objets WordPress est utilisĂ© sur presque tous les sites WordPress. Et oui, le cache d'objets est efficace mĂȘme si vous n'utilisez pas de cache d'objets externe, comme MemCached ou REDIS.

Comment fonctionne le cache d'objets WordPress ?

  1. Vous faites une demande d'utilisation des valeurs postmeta c'est Ă  dire get_post_meta()
  2. WordPress exĂ©cute la requĂȘte et obtient le rĂ©sultat de la base de donnĂ©es et stocke automatiquement le rĂ©sultat dans le cache d'objets (mĂ©moire, RAM)
  3. Vous obtenez le résultat et l'utilisez quelque part dans votre code
  4. Plus tard dans votre code, faites-en un autre  get_post_meta() demander les mĂȘmes donnĂ©es
  5. WordPress l'a déjà dans le cache d'objets et le renvoie directement sans interroger à nouveau la base de données
  6. La page est livrée au visiteur et le cache d'objets est vidé (mémoire libérée)

Toutes les fonctions WordPress n'enregistrent pas leurs rĂ©sultats dans le cache d'objets, mais  get_post_meta() ils le font. En effet, la table _postmeta de la base de donnĂ©es peut devenir trĂšs volumineuse et les requĂȘtes peuvent devenir coĂ»teuses (utiliser beaucoup de ressources de traitement).

En tant que dĂ©veloppeur, vous pouvez ajoutez vous-mĂȘme les rĂ©sultats au cache d'objets , de sorte que la rĂ©utilisation ultĂ©rieure des mĂȘmes donnĂ©es peut ĂȘtre plus rapide. Si vous Ă©crivez vos requĂȘtes avec par exemple WP_Query, vous devrez stocker vous-mĂȘme les rĂ©sultats dans le cache d'objets. Il est important de se rappeler, cependant, que, comme pour toute mise en cache, vous ne pouvez pas lui faire confiance. Assurez-vous donc de ne pas Ă©crire de code qui suppose que vos rĂ©sultats se trouvent dans le cache d'objets.

Vous pouvez vĂ©rifier les performances du cache d'objets et le nombre de requĂȘtes de base de donnĂ©es en installant un plug-ins tels que Query Monitor.

Dans nos tests avec un WooCommerce normal, un taux de réussite normal du cache d'objets se situe entre 95% et 98%.

Comment utiliser le cache d'objets WordPress pour vos requĂȘtes

$ result = wp_cache_get ('some_unique_name'); if (false === $ result) {$ result = $ wpdb-> get_results ($ query); wp_cache_set ('some_unique_name', $ result); } // Faire quelque chose avec $ result ;

Cet exemple de code essaie d'abord d'obtenir un  $result, puis vĂ©rifiez s'il y a vraiment un rĂ©sultat en $. wp_cache_get()rĂ©sultats falses'il n'existe pas. S'il n'y a pas de donnĂ©es, nous interrogeons nos donnĂ©es, puis les stockons dans wp_cache_set() afin qu'ils soient disponibles pour de futures demandes.

Qu'en est-il des caches d'objets externes comme MemCached et REDIS ?

Un cache d'objets externe peut fournir ce que l'on appelle plus prĂ©cisĂ©ment un « cache d'objets persistant ». Il s'agit d'un cache d'objets qui n'est pas tĂ©lĂ©chargĂ© entre les pages vues ; par consĂ©quent, il stocke ses donnĂ©es dans diffĂ©rentes pages vues. IdĂ©e intelligente, non ? Mais comme d'habitude avec la mise en cache, ce n'est pas si simple.

  1. Le gain de performances potentiel liĂ© Ă  l'utilisation d'un cache d'objets persistant est limitĂ© aux hits qui Ă©chouent dans le cache d'objets. En utilisant le taux d'accĂšs au cache non persistant par dĂ©faut de 95 % Ă  98 %, le potentiel d'amĂ©lioration des performances se situe entre 2 % et 5 % de la demande. De plus, un cache d'objet externe ajoutera une latence supplĂ©mentaire car il s'agit d'une application externe, il ralentira donc de 95 Ă  98 % ce qui Ă©tait servi directement dans PHP auparavant. Le gain net de la latence supplĂ©mentaire + le gain de performances du cache d'objets externes vont souvent mal pour les magasins de commerce Ă©lectronique.
  2. MĂȘme si vous utilisez un cache d'objets externe, vous ne pouvez pas faire confiance Ă  l'existence des informations lors de l'Ă©criture du code.
  3. Si vous dĂ©pendez d'un cache d'objets externe pour charger les pages Ă  une vitesse dĂ©cente, cela signifie que votre code n'est pas valide, que les requĂȘtes de la base de donnĂ©es sont trop lourdes ou qu'elles sont trop nombreuses. Le vrai problĂšme est dans votre code, pas dans la rĂ©activitĂ© de la base de donnĂ©es. C'est pourquoi vous ne devriez pas utiliser le patch MemCached ou Redis.
  4. Si vous utilisez une base de données rapide et optimisée qui utilise correctement les index, vous n'avez pas besoin d'un cache d'objets externe.

Si vous n'avez pas besoin d'un cache d'objets externe, il peut ĂȘtre dangereux d'en utiliser un

Cela vaut vraiment pour toute la technologie que vous incluez dans votre pile Web, dont vous n'avez pas besoin. Si vous l'avez, le risque d'en devenir accro est grand, mĂȘme si vous n'en avez pas vraiment besoin. Si vous en dĂ©pendez, vous augmentez les chances que quelque chose tourne mal. De plus, chaque technologie ajoutĂ©e Ă  la pile nĂ©cessite une installation, une configuration, une maintenance, des mises Ă  jour de sĂ©curitĂ© et introduit un autre point de dĂ©faillance unique.

Les transitoires peuvent ĂȘtre bons, mais ils peuvent aussi nuire Ă  votre site

Les transitoires sont utilisés par WordPress et une variété de plugins, et le concept est assez simple. Vous faites une demande et enregistrez le résultat, ou des parties de celui-ci, dans la base de données pour une réutilisation ultérieure. Contrairement au cache d'objets, aucune technologie supplémentaire n'est nécessaire pour rendre cela persistant d'une page à l'autre, car les données sont stockées dans la base de données. Les transitoires peuvent ou non avoir un délai d'expiration - c'est votre choix.

Personnellement, je n'aime pas l'utilisation excessive des transitoires, et il y a de nombreuses raisons Ă  cela

  1. Les transitoires sont enregistrés dans la table WordPress _options. Cette table est déjà trÚs utilisée et une écriture excessive dans _options peut introduire des problÚmes de blocage (mise en file d'attente).
  2. L'utilisation excessive de transitoires se traduira par une grande table _options. Chaque vue de page individuelle dépend de cette table, et une grande table d'options peut dégrader les performances sur toutes les vues de page.
  3. Les transitoires qui n'expirent pas seront interrogés à chaque chargement de page (chargement automatique) via wp_load_alloptions(). Cela réduira les performances sur toutes les pages vues.

Mais cela dit, les transitoires peuvent ĂȘtre excellents pour les performances lorsqu'ils sont utilisĂ©s correctement. Si vous recherchez des donnĂ©es souvent utilisĂ©es et rarement modifiĂ©es, il peut ĂȘtre judicieux de stocker le rĂ©sultat dans transitoire. Il est beaucoup plus facile pour WordPress de rĂ©cupĂ©rer la valeur de la touche X dans le tableau des options, plutĂŽt que de faire des sĂ©lections sur d'autres tableaux. Mais, si vous utilisez des transitoires, assurez-vous de garder un Ɠil sur la table _options pour vous assurer qu'elle ne devient pas sauvage, et assurez-vous d'implĂ©menter le nettoyage des transitoires que vous n'utilisez plus ou qui ont expirĂ©. Et n'utilisez jamais de transitoires pour les donnĂ©es qui nĂ©cessitent des mises Ă  jour frĂ©quentes, car cela dĂ©grade les performances.

La mise en cache des fragments est bonne lorsqu'elle est utilisée correctement

Le Fragment Cache est un type de mise en cache oĂč l'on stocke un Ă©lĂ©ment, une partie d'une page, ou autre chose dont la gĂ©nĂ©ration est coĂ»teuse en termes de ressources et/ou est souvent utilisĂ©e. Beaucoup ont choisi d'implĂ©menter la fonctionnalitĂ© de Mark Jaquith pour effectuer la mise en cache de fragments dans WordPress.

La mise en cache de fragments consiste Ă  stocker un rĂ©sultat (sortie HTML) afin qu'il puisse ĂȘtre livrĂ© beaucoup plus rapidement par la suite. L'idĂ©e est aussi simple que surprenante. Vous pouvez choisir les Ă©lĂ©ments Ă  mettre en cache et vous n'avez pas besoin de mettre en cache l'intĂ©gralitĂ© de la sortie, comme la mise en cache d'une page complĂšte.

La façon dont vous procĂ©dez dans WordPress Ă©quivaut Ă  la mise en cache d'objets, car il n'y a pas de limite aux donnĂ©es que vous pouvez mettre en cache. Par consĂ©quent, les mĂȘmes principes s'appliquent; ne faites jamais confiance Ă  quelque chose qui est mis en cache, assurez-vous de ne pas en dĂ©pendre et concentrez-vous sur votre code plutĂŽt que de prendre le raccourci du cache de fragments.

Beaucoup implĂ©mentent la mise en cache des fragments basĂ©e sur la mĂ©moire. Mais pour que cela prenne effet, un cache d'objets externe est nĂ©cessaire pour rendre les Ă©lĂ©ments disponibles dans les vues de page (voir ci-dessus). Je recommande une utilisation douce de la mise en cache des fragments et du stockage des donnĂ©es dans les transitoires. En pratique, cela vous donnera les mĂȘmes rĂ©sultats en termes de performances, sans ajouter de technologie supplĂ©mentaire Ă  votre pile.

Voici comment enregistrer les transitoires

$ sortie = get_transient ('some_unique_key'); if ($ output === false) {$ output = 'Quelques données'; set_transient ('some_unique_key', $ sortie, 3600); } // Faire quelque chose avec la sortie $

Dans cet exemple de code, nous lisons $output Ă  partir d'un transitoire et testez si la sortie $ existe. Soi  get_transient()rĂ©sultats false , nous gĂ©nĂ©rons les donnĂ©es et les stockons dans un transitoire pour une utilisation ultĂ©rieure.

Quelle technique de mise en cache dois-je utiliser et quand ?

Il utilise le stockage Full Page Cache pour la mise à l'échelle, c'est pour cela qu'il est fait : il n'est pas fait pour améliorer les performances. Assurez-vous de ne pas devenir accro à cela. Vous devriez pouvoir désactiver la mise en cache de pages entiÚres sans subir de perte de performances significative.

Utilisez le cache d'objets autant que possible, surtout si vous utilisez WooCommerce, mais Ă©vitez les caches d'objets externes, ils introduiront toutes sortes de nouveaux problĂšmes. Les caches externes dĂ©placeront votre attention vers les mauvaises parties de votre application. Une meilleure astuce consiste Ă  obtenir un un hĂ©bergement plus rapide, avec des bases de donnĂ©es performantes comme le nĂŽtre.

Vous devez utiliser des transitoires pour les requĂȘtes frĂ©quentes qui ne changent pas beaucoup. Assurez-vous de dĂ©finir une date d'expiration appropriĂ©e en fonction de la frĂ©quence Ă  laquelle les donnĂ©es doivent ĂȘtre mises Ă  jour.

Assurez-vous également de supprimer les transitoires expirés. Utilisez le cache de fragments dans les transitoires pour les éléments gourmands en ressources et fréquemment utilisés.

Vous avez des doutes ? Vous ne savez pas par oĂč commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modÚle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systĂšmes sans avoir Ă  migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entiÚrement gratuite.

Non merci, mes clients préfÚrent le site lent.
Retour en haut de page