Comment fonctionne la mise en cache dans WordPress ? - ūüŹÜ Serveur g√©r√©

BLOG

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

Managed Server Srl est un acteur italien leader dans la fourniture de solutions syst√®me GNU/Linux avanc√©es orient√©es vers la haute performance. Avec un mod√®le d'abonnement peu co√Ľteux et pr√©visible, nous garantissons que nos clients ont acc√®s √† des technologies avanc√©es en mati√®re d'h√©bergement, de serveurs d√©di√©s et de services cloud. En plus de cela, nous proposons des conseils syst√®me sur les syst√®mes Linux et une maintenance sp√©cialis√©e en SGBD, s√©curit√© informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'h√©bergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapt√© aux administrations publiques, aux PME et √† toutes tailles.

Red Hat, Inc. d√©tient les droits de Red Hat¬ģ, RHEL¬ģ, RedHat Linux¬ģ et CentOS¬ģ ; AlmaLinux‚ĄĘ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux¬ģ est une marque d√©pos√©e de la Rocky Linux Foundation ; SUSE¬ģ est une marque d√©pos√©e de SUSE LLC ; Canonical Ltd. d√©tient les droits sur Ubuntu¬ģ ; Software in the Public Interest, Inc. d√©tient les droits sur Debian¬ģ ; Linus Torvalds d√©tient les droits sur Linux¬ģ ; FreeBSD¬ģ est une marque d√©pos√©e de la FreeBSD Foundation ; NetBSD¬ģ est une marque d√©pos√©e de la Fondation NetBSD ; OpenBSD¬ģ est une marque d√©pos√©e de Theo de Raadt. Oracle Corporation d√©tient les droits sur Oracle¬ģ, MySQL¬ģ et MyRocks¬ģ ; Percona¬ģ est une marque d√©pos√©e de Percona LLC ; MariaDB¬ģ est une marque d√©pos√©e de MariaDB Corporation Ab ; REDIS¬ģ est une marque d√©pos√©e de Redis Labs Ltd. F5 Networks, Inc. d√©tient les droits sur NGINX¬ģ et NGINX Plus¬ģ ; Varnish¬ģ est une marque d√©pos√©e de Varnish Software AB. Adobe Inc. d√©tient les droits sur Magento¬ģ ; PrestaShop¬ģ est une marque d√©pos√©e de PrestaShop SA ; OpenCart¬ģ est une marque d√©pos√©e d'OpenCart Limited. Automattic Inc. d√©tient les droits sur WordPress¬ģ, WooCommerce¬ģ et JetPack¬ģ ; Open Source Matters, Inc. d√©tient les droits sur Joomla¬ģ ; Dries Buytaert d√©tient les droits sur Drupal¬ģ. Amazon Web Services, Inc. d√©tient les droits sur AWS¬ģ ; Google LLC d√©tient les droits sur Google Cloud‚ĄĘ et Chrome‚ĄĘ ; Facebook, Inc. d√©tient les droits sur Facebook¬ģ ; Microsoft Corporation d√©tient les droits sur Microsoft¬ģ, Azure¬ģ et Internet Explorer¬ģ ; La Fondation Mozilla d√©tient les droits sur Firefox¬ģ. Apache¬ģ est une marque d√©pos√©e de The Apache Software Foundation ; PHP¬ģ est une marque d√©pos√©e du groupe PHP. CloudFlare¬ģ est une marque d√©pos√©e de Cloudflare, Inc. ; NETSCOUT¬ģ est une marque d√©pos√©e de NETSCOUT Systems Inc. ; ElasticSearch¬ģ, LogStash¬ģ et Kibana¬ģ sont des marques d√©pos√©es d'Elastic NV. Ce site n'est affili√©, sponsoris√© ou autrement associ√© √† aucune des entit√©s mentionn√©es ci-dessus et ne repr√©sente aucune de ces entit√©s de quelque mani√®re que ce soit. Tous les droits sur les marques et noms de produits mentionn√©s sont la propri√©t√© de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionn√©es appartiennent √† leurs titulaires. MANAGED SERVER¬ģ est une marque d√©pos√©e au niveau europ√©en par MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italie.

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