Optimisation du cache du site web

La cause première de la “lenteur” d'un site web n'est généralement pas une image particulière, mais plutôtLien de demande + Génération de serveurs + Distribution de ressources statiquescausée par la superposition :

• Les utilisateurs sont trop éloignés de vos serveurs, le temps de transit du réseau est élevé (plus perceptible sur les continents).
• WordPress exécute PHP, vérifie la base de données, et rend le modèle pour chaque requête → TTFB (time to first byte) vers le haut
• Les pages chargent également des JS/CSS/fontes/scripts tiers, ce qui ralentit le rendu et l'interaction.

Plugin de mise en cacheLe cœur de la solution consiste à enregistrer les résultats des pages “doublement comptées” afin que le serveur ne doive pas les recalculer à chaque fois, et à réduire de manière significative le TTFB en permettant à un plus grand nombre d'utilisateurs d'accéder au cache dans le cadre d'une stratégie appropriée.Documentation officielle de WordPressIl a également été souligné que des plugins tels que W3 Total Cache et WP Super Cache peuvent mettre en cache des pages en tant que fichiers statiques, puis les servir directement à l'utilisateur, réduisant ainsi la charge de traitement sur le serveur.

Avant de lire cette page, rappelez-vous trois règles inflexibles

1. les plug-ins de mise en cache des pages en même temps qu'un seul

Le résultat le plus courant de l'activation simultanée de plusieurs plugins de mise en cache n'est pas plus rapide :

• Remplacer les règles de cache des uns et des autres, vider les caches des uns et des autres, le taux de réussite des caches diminue.
• Le contenu dynamique, tel que l'état de connexion, la langue, la voiture ou le prix, est mis en cache, ce qui entraîne des incidents dus à un “contenu erroné”.
  De nombreuses documentations/instructions de plugins suggèrent que lors de l'utilisation d'un certain plugin de mise en cacheDésactiver les autres plugins de mise en cachepour éviter les conflits.

2) Sites de commerce électronique, d'affiliation et multilingues : la mise en cache n'est pas un “interrupteur”, c'est un “système de règles”.”

Documentation officielle sur les performances de WooCommerceRappel explicite : dans le plugin de cache, s'assurer que Panier d'achat / Checkout / Compte Il est également recommandé d'éviter la compression des fichiers JavaScript (car elle tend à causer des problèmes de compatibilité).

3) “Cache plug-in ≠ CDN”, mais le cache plug-in est la base de CDN

Plugin de mise en cache pour résoudre le problème du “sous-dénombrement des stations sources” ;CDN Résoudre le problème du “contenu plus proche des utilisateurs”. La relation entre les deux est superposée : tout d'abord, la source TTFB est pressée, puis les ressources statiques sont transmises à CDN pour diffusion, ce qui constitue la voie la plus stable pour les utilisateurs mondiaux.

Sélection rapide : 4 des scénarios les plus courants pour les sites web

Si vous ne voulez pas lire l'article en entier, vous ne pouvez pas vous tromper avec les 4 choix suivants :

1. Vous voulez économiser de l'argent, être stable et vous orienter vers un accès mondial. → WP Rocket(Payé)
2. L'hébergement est explicitement LiteSpeed/OpenLiteSpeed → LiteSpeed Cache(gratuit mais fortement dépendant de la capacité du serveur)La fonction de mise en cache nécessite Composants du serveur LiteSpeedne travailler qu'à ce moment-là
3. Sites de contenu/blogs/sites documentaires qui veulent être libres et stables → WP Super Cache(cache HTML statique)Les utilisateurs non connectés ont la possibilité de générer des fichiers HTML statiques qui seront mis à leur disposition.
4. Vous disposez d'équipes techniques pour affiner le contrôle (CDN/object caching/multi-modules) → W3 Total Cache(fort mais complexe)La gestion de l'environnement : Maintient un cadre de performance complet avec l'intégration de CDN

Que cache exactement le cache ?

“Pourquoi certains sites sont encore lents avec la mise en cache”, nous avons décomposé les performances de WordPress en 5 couches :

1. cache du navigateurLes utilisateurs doivent pouvoir accéder plus rapidement aux ressources secondaires (en-têtes de cache des ressources statiques, numéros de version).
2. cache de pageLa page de cache est affichée au format HTML (caractère principal de cette page)
3. cache d'objetsLes stations dynamiques ont plus de valeur.
4. PHP OPcacheCache PHP bytecode (généralement configuré par le serveur, ce n'est pas l'objet du plugin)
5. CDN/cache de bordLes ressources sont réparties entre les nœuds les plus proches des utilisateurs.

L'objet de cet article : le plugin de mise en cache des pages ;
Mais on vous rappelle constamment que les sites web ont souvent besoin d'une combinaison de 2 + 5 pour être “vraiment rapides”.

Plug-in 1 :WP Rocket(payants) - Programmes intégrés “sans souci

WP Rocket est populaire sur la scène “WordPress” non pas parce qu'il est magique, mais parce qu'il transforme les trois types de performance les plus courants en “paquets gérables” :

• Mise en cache des pages (réduit le TTFB du site source)
• Préchargement/préchauffage du cache (pour améliorer l'expérience de la première visite avec un accès distribué à l'échelle mondiale)
• Optimisations frontales clés (en particulier latence JS, gestion CSS, etc.)

sondocument officielIl mentionne aussi explicitement que l'activation du préchargement peut déclencher certaines optimisations (par exemple, des optimisations liées à CSS/JS) même si vous désactivez la mise en cache de la page.

1.1 A qui s'adresse WP Rocket ?

WP Rocket est particulièrement adapté à ces stations :

• Site web de l'entreprise, site de marque, site de marketing de contenu, page d'atterrissage (trafic en provenance de plusieurs pays et régions)
• Je veux “mettre en service rapidement, la stabilité d'abord”, je ne veux pas utiliser beaucoup de combinaisons de plugins gratuits.
• Pas d'ingénieurs dédiés à l'exploitation et à la performance, mais expérience et exigences en matière de référencement
• WooCommerce Il peut également être utilisé, mais avec plus de précautions (voir plus loin dans cette section).Règles et risques）

1.2 Sa valeur clé dans les scénarios d'accès au web (pas seulement un “cache switch”)

A. Préchargement du cache : résoudre le problème des “premières visites instables dues à l'accès distribué aux sites web”

Vous constaterez un ralentissement typique lorsque les utilisateurs du site sont dispersés :
Un utilisateur d'une région ouvre une page pour la première fois et il se trouve qu'elle n'est pas en mémoire cache ou qu'elle n'a jamais été réchauffée → cet utilisateur subit l'intégralité du coût de rendu de PHP/DB.
Mécanisme de préchargeLa signification de cela est la suivante :Payer les coûts de la “première génération” dès le départLa première visite du programme sera un “cobaye”, ce qui réduit la probabilité d'une "première visite en tant que cobaye".

• Pas de préchargement : celui qui accède en premier souffre
• Avec préchargement : grâce à la génération unifiée de cache par le système en arrière-plan, la première visite est plus stable.

B. Exécution différée de JavaScript : la fonction la plus simple pour “se sentir immédiat” lors de la visite d'un site web, mais aussi la plus risquée.

WP Rocket met officiellement “Exécution retardée de la JS”Il reporte l'exécution du script jusqu'à ce que l'utilisateur ait interagi (en déplaçant la souris, en touchant l'écran, en faisant défiler la page, en appuyant sur une touche, etc.

C'est important pour l'accès aux sites web, car le blocage du chargement et de l'exécution des scripts est plus susceptible d'être amplifié sur les réseaux intercontinentaux :

• Téléchargement plus lent des ressources → le fil principal est plus susceptible d'être encombré par des scripts
• Les scripts tiers (statistiques, publicités, plugins de chat) sont plus susceptibles d'aggraver les retards d'INP/d'interaction.

Mais cela peut aussi poser des problèmes :

• Le retard de la JS est susceptible d'affecter : les menus, les rotations, les popups, la validation des formulaires, les paiements, le suivi des enterrements.
• Il convient donc à une stratégie “étape par étape + exclusion de la liste noire”.

C. Compatibilité avec d'autres plug-ins/thèmes : “zéro conflit” n'est pas synonyme de "tranquillité d'esprit".”

WP Rocket a officiellement inscrit “Plugins/thèmes incompatibles”pour des raisons qui incluent des mécanismes tels que la mise en mémoire tampon de sortie qui affecterait la mise en cache/optimisation de WP Rocket.

• Si votre site est très riche en plugins et en thèmes, considérez l“”optimisation des performances" comme un mini-projet de mise en service : tests de régression pour chaque modification (formulaires, connexions, paiements, passage au multilinguisme, etc.)

1.3 Rappel spécial pour WooCommerce/Dynamic Site

Le rappel principal de la documentation officielle de WooCommerce lors de la configuration du plugin de mise en cache est le suivant :

• Panier d'achat / Checkout / Compte Ne pas mettre en cache
• En outre, il est recommandé queÉviter la compression des fichiers JS

Pourquoi ? Pour les raisons suivantes :

• Forte dépendance à l'égard du panier, de la caisse, de la page de compte cookie / session / nonce
• Une fois que le cache traite ces pages comme des “pages statiques”, les boutons ne fonctionneront pas et les informations relatives aux prix, à l'inventaire et aux comptes seront altérées.
• Voici la partie la plus effrayante : vous pouvez effectuer des tests corrects dans une région et rencontrer des problèmes dans une autre en raison de divergences entre CDN et le nombre de hits de la mémoire cache !

1.4 Recommandations au niveau de la stratégie du plugin de cache

Niveau 1 : Prestations de sécurité de base (presque toutes les stations devraient le faire)

• Activer la mise en cache des pages
• ouvrePréchargement du cache(Amélioration de la stabilité de la première visite)
• Politique raisonnable de mise en cache du navigateur (WP Rocket/Server/CDN L'une ou l'autre couche peut être mise en œuvre)

Niveau 2 : Récompense moyenne, risque moyen (adapté à la plupart des sites de contenu)

• Chargement retardé des images/iframe (la page d'optimisation des images va plus loin)
• Contrôle du volume de CSS (par exemple, suppression des CSS inutilisés)

Niveau 3 : Rendement élevé mais risque élevé (liste de contrôle des tests de régression obligatoire)

• Exécution JavaScript retardée (donne la priorité au rendu, mais peut affecter l'interaction)
• Compression/fusion JS/CSS : soyez très prudent avec le commerce électronique/les membres/multilingues (WooCommerce met également en garde contre le risque de compression JS）

1.5 Prix et autorisations

• WP Rocket est une licence payante, avec différentes licences en fonction du nombre de sites.

Plugin 2 :LiteSpeed Cache (LSCWP)--La prémisse des “tops gratuits” est que le serveur est réellement LiteSpeed.

Beaucoup de gens ont une fausse idée de LiteSpeed Cache : ils pensent que c'est juste un plugin WordPress que vous pouvez installer et obtenir toute la puissance sur n'importe quel hébergeur, tout comme WP Rocket. Ce n'est pas le cas.

Documentation officielle de LiteSpeedExplication claire : la fonction de mise en cache de LSCWP nécessite LiteSpeed Server parce qu'elle communique avec le cache de page intégré de LiteSpeed Web Server (LSCache) ; le plugin est responsable d'indiquer au serveur quelles pages peuvent être mises en cache, pour combien de temps, et de déclencher le nettoyage avec des balises.

La force principale de LiteSpeed Cache vient de “Mise en cache des pages au niveau du serveur (LSCache)”. Sans les serveurs LiteSpeed/OpenLiteSpeed, il n'y a pas cet avantage fondamental.

2.1 LiteSpeed Cachepour qui

En forme :

• Votre panneau d'hébergement est clairement identifié LiteSpeed / OpenLiteSpeed(par exemple, de nombreux hébergeurs cPanel écriront)
• Vous voulez “une solution libre qui peut également fonctionner en mode TTFB et en mode concurrentiel”.”
• Vous êtes prêt à l'accepter : c'est très puissant, mais aussi plus conceptuel (TTL, Tag, Purge, ESI, Crawler...)

Pas vraiment :

• Vous n'êtes pas sûr du serveur Web de l'hébergeur, ou vous ne confirmez pas qu'il s'agit de Nginx/Apache (à moins que vous ne souhaitiez utiliser que certaines de ses fonctions d'optimisation frontale, mais alors le rapport prix/performance et la complexité ne sont pas nécessairement rentables).
• Vous êtes un site complexe de commerce électronique, d'adhésion ou multilingue, mais vous ne disposez pas d'un processus de test (LSCWP est puissant, mais il est également plus facile de “mettre en cache le mauvais contenu”).

2.2 Son mécanisme de mise en cache : pourquoi il s'agit plutôt d'une “partie de la capacité du serveur”.”

Vous pourriez écrire la mécanique de LiteSpeed Cache comme une “explication technique” :

• WP Rocket / WP Super Cache Il s'agit plutôt du côté WordPress/PHP de la mise en cache et de l'optimisation ;
• LSCWP C'est une combinaison du panneau de contrôle WordPress + LSCache intégré de LiteSpeed Server : le plugin est responsable de l'émission des règles et des signaux de nettoyage, et la véritable mise en cache de la page à grande vitesse se produit dans le panneau de contrôle WordPress.couche serveur。

Cela a un impact direct sur l'expérience du site web : la mise en cache des spits au niveau du serveur est généralement plus légère, plus rapide et plus simultanée (en particulier en cas d'afflux de trafic et de visites fréquentes de robots d'indexation de moteurs de recherche).

2.3 La “bonne façon” d'ouvrir le LSCWP pour les scénarios d'utilisation du site web”

Nous avons divisé la “bonne façon d'ouvrir” en 4 niveaux :

Couche 1 : Politique de mise en cache des pages (détermine si le TTFB peut réellement baisser)

• Préciser quelles pages peuvent être mises en cache (la plupart des pages de contenu public)
• Indiquez clairement les pages qui ne doivent jamais être mises en cache (pages de connexion, de compte, de panier d'achat, de paiement, de changement de langue ou de devise qui s'appuient sur une cookie forte).
• Fixez un TTL raisonnable pour le cache (plus le contenu est mis à jour fréquemment, plus le TTL est court, et plus le TTL est long).
• Créer une stratégie de nettoyage : nettoyer la balise pertinente après la mise à jour du contenu (plutôt que de procéder à un nettoyage brutal de l'ensemble du site).

Cette couche, si elle est correctement réalisée, est plus directement visible sur le site web en tant que TTFB en baisse, premier écran plus stable。

Couche 2 : Warm-up/Crawler (détermine la “lenteur de la première visite sur une page froide”)

Une “incohérence” courante dans l'accès aux sites web provient des “différences chaudes/froides” dans la mise en cache :

• Les pages les plus populaires sont toujours visitées et le cache est toujours chaud.
• Les pages froides n'ont pas été cliquées depuis longtemps et les personnes qui cliquent pour la première fois sont lentes.

L'échauffement n'est pas la cerise sur le gâteau, c'est la clé d'une expérience cohérente pour les visiteurs du site web.

Couche 3 : Programmes de sécurité pour le contenu dynamique (commerce électronique/adhésion/multilinguisme)

La puissance de LSCWP réside dans le fait qu'il vous offre de nombreux “outils avancés”, par exemple :

• Stratégies de mise en cache différenciées pour les utilisateurs connectés, les utilisateurs de commentaires, etc.
• L'idée centrale de l'Edge Side Inclusion (ESI) est de diviser la page en "corps public cachable" et en "fragments dynamiques non cachables", qui sont traités séparément puis assemblés au niveau des nœuds de bordure.

Niveau 4 : Services en ligne et améliorations optionnelles

De nombreux webmasters trouveront les services en ligne de QUIC.cloud (par exemple, les services de type "on-page optimisation") utiles dans le cadre du LSCWP.QUIC.cloud DocumentationIl est explicitement écrit qu'elle fournit des services d'optimisation de page à LSCWP, y compris Critical CSS (CCSS), Unique CSS (UCSS), Viewport Images (VPI) et autres.

• Ce type de service est facultatif: vous pouvez vous contenter d'utiliser la mise en cache du serveur et ne pas activer l'optimisation en ligne
• Une fois les services en ligne activés, les ressources de votre site et les liens de traitement des pages seront modifiés (il s'agit d'une information importante pour les entreprises et les clients sensibles à la protection de la vie privée).

2.4 Fosse commune LSCWP

1. Le serveur n'est pas LiteSpeed, mais utilise LSCWP comme plugin de mise en cache complet.
   Résultat : la mise en cache n'est pas aussi efficace que prévu et augmente la complexité de la configuration. Solution : Confirmez d'abord la pile d'hôtes ; si ce n'est pas le cas LiteSpeedPar exemple, WP Rocket ou WP Super Cache.
2. L'activation d'un trop grand nombre d'optimisations frontales entraîne des anomalies fonctionnelles
   Les optimisations de page (CSS/JS) sont souvent plus susceptibles de causer des problèmes de compatibilité que la “mise en cache elle-même”. Suggestion : lancez d'abord le cache de la page, puis activez les optimisations une par une, et créez une liste de tests de régression (formulaires, menus, paiements, suivi, changement de langue, etc.)
3. Absence de stratégies d'exclusion/de découpage pour les pages dynamiques
   Les incidents les plus fréquents sont les suivants : panier d'achat, paiement, page de compte mise en cache ou commutation incorrecte entre plusieurs langues et plusieurs devises. Les sites de commerce électronique doivent prendre en compte cette vérification avant le lancement (et les responsables de WooCommerce insistent également sur les points suivants)Ne pas mettre en cache les pages clés）。

Plugin 3 :WP Super Cache(gratuit) - Une solution classique “à faible risque et à haut rendement” pour les sites de contenu.

WP Super Cache Pourquoi est-il populaire depuis si longtemps ? Parce qu'il résout les problèmes d'une manière très directe et très “conviviale” pour le serveur :
Générer des fichiers HTML statiques à partir de pages dynamiques de WordPressLes fichiers HTML sont alors servis directement par le serveur web, sans passer par le traitement coûteux de PHP.

La page du plugin mentionne également que : le HTML statique sera servi à la grande majorité des utilisateurs non connectés, et donne une déclaration très intuitive - “99% visitors will be served static HTML files” (99% visiteurs recevront des fichiers HTML statiques), et un seul fichier mis en cache peut être servi des milliers de fois.

3.1 A qui s'adresse WP Super Cache ?

Hautement recommandé :

• Blogs, sites de contenu média, sites documentaires, sites vitrines d'entreprise, pages d'atterrissage
• Les visiteurs sont principalement des utilisateurs non connectés
• Vous souhaitez : gratuité, stabilité, faibles coûts d'entretien

Faire preuve de prudence/besoin de stratégies plus solides :

• Site fortement dynamique : beaucoup de contenu personnalisé, des pages qui changent en fonction de l'état de l'utilisateur.
• Grandes entreprises de commerce électronique : cela peut fonctionner, mais assurez-vous que les pages clés ne sont pas mises en cache et travaillez avec votre processus de test.

3.2 Ses trois méthodes de mise en cache :

La description du plugin WP Super Cache répertorie 3 méthodes de mise en cache par vitesse et explique les différences :

• mod_rewrite (expert)La configuration la plus rapide, contournant complètement PHP, mais nécessitant de modifier .htaccess, une mauvaise configuration peut conduire à l'indisponibilité du site, le risque est plus élevé !
• Simple (approche recommandée): fichiers statiques “super mis en cache” fournis par PHP, proches de la vitesse de mod_rewrite, mais plus faciles à configurer.
• WP-Cache Cache: plus souple pour les utilisateurs connus, les URL avec paramètres, les flux d'abonnement, etc.

Choix recommandé :

• Débutants/en quête de stabilité : utiliser la méthode recommandée (simple)
• Vous connaissez les règles du serveur et vous êtes prêt à prendre le risque de les réécrire : repensez au modèle expert !
• Vous avez besoin d'une gestion plus flexible de “Known User/With Parameters” : Comprendre la position de WP-Cache

3.3 Avantages et inconvénients de WP Super Cache

Avantage :

1. Idéal pour une utilisation avec le CDN.
   Comme il s'agit essentiellement de “générer du HTML statique”, cela correspond naturellement à l'idée du CDN/edge cache.
2. Les améliorations de la pression de la station source CPU/base de données sont très simples.
   Les moteurs de recherche et les robots d'exploration des médias sociaux peuvent également venir du monde entier lorsque le trafic du site web est dispersé. La statisation permet de lutter efficacement contre le “re-rendering”.

Planche courte :

1. Il ne s'agit pas d'une “suite d'optimisation des performances tout-en-un”.”
   Il est principalement axé sur la mise en cache des pages, et les optimisations CSS/JS profondes ne sont pas aussi complètes que dans WP Rocket. Vous devrez peut-être en faire plus dans la “Page d'optimisation des images” et la “Page d'optimisation du frontend” (ou utiliser d'autres optimisations au niveau du plugin/thème).
2. Soyez plus prudent en ce qui concerne la “personnalisation dynamique”
   Par exemple, afficher un contenu différent selon la région, afficher des prix/langues/recommandations différents selon le statut de l'utilisateur, etc. À ce stade, vous devez soit créer une politique d'exclusion, soit introduire un système de mise en cache en tranches plus approprié.

3.4 Compatibilité avec WooCommerce : pourquoi c'est plus sûr“

Aide officielle de WooCommerceMentionné : WooCommerce est nativement compatible avec WP Super Cache et WooCommerce envoie un message à WP Super Cache pour qu'il ne mette pas en cache les pages Cart, Checkout, My Account par défaut.

• Même si vous êtes nouveau à WP Super Cache + WooCommerce, il est beaucoup moins probable que vous marchiez sur la mine “key pages cached” !
• Cependant, il est toujours recommandé d'effectuer des tests de régression avant la mise en service (paiements, coupons, expédition, taux de taxation, multidevises, etc.)

Plugin 4 :W3 Total Cache (W3TC)--Le cadre de performance le plus polyvalent pour les équipes d'ingénieurs.

W3 Total Cache Plutôt qu'un “plugin de cache unique”, WordPress.org se positionne plutôt comme un “cadre d'optimisation des performances des sites web” : il met l'accent sur l'amélioration du référencement, de Core Web Vitals et de l'expérience globale grâce à l'intégration de CDN et aux meilleures pratiques. Vitales et expérience globale grâce à l'intégration de CDN et aux meilleures pratiques.

La description du plugin énumère un large éventail de fonctionnalités : mise en cache des pages/postes, mise en cache des CSS/JS, mise en cache des flux, mise en cache des résultats de recherche, mise en cache des objets de la base de données, mise en cache des objets, mise en cache des fragments (fragment cache), et prise en charge d'une variété de méthodes de mise en cache telles que Redis/Memcached/APC, mais inclut également la mise en cache des groupes mobiles par UA/Referrer, AMP, l'intégration de reverse proxy (Nginx/Varnish), etc.

4.1 À qui s'adresse W3 Total Cache ?

Parfait pour :

• Vous avez des compétences en matière de développement et d'exploitation et vous êtes prêt à effectuer des tests d'habilitation, des tests de pression et des tests de régression.“
• Votre site est complexe : multilingue, changement de thème, différenciation mobile, structure de contenu complexe.
• Vous ne voulez pas seulement une mise en cache des pages, vous voulez incorporer la mise en cache des objets et des fragments dans le système (en particulier pour les sites dynamiques).

Il ne convient pas :

• Vous voulez “installer et partir”, vous ne voulez pas comprendre les hiérarchies de cache !
• Vous n'avez pas de processus de test, mais vous souhaitez activer d'un seul coup des éléments à haut risque tels que la compression et les scripts différés.

4.2 Pourquoi est-elle “forte mais complexe” : la valeur “contrôlabilité” des sites web.”

La valeur de W3TC ne réside pas dans le fait qu'il doit être plus rapide que les autres, mais dans le fait qu'il vous donne suffisamment de boutons de contrôle pour élaborer une stratégie de performance :

• Cache de page : peut être en mémoire, sur disque ou CDN
• Cache d'objets de la base de données, cache d'objets : disponible Redis/Memcached, etc.
• La mise en cache des fragments : une bonne chose pour les “pages semi-dynamiques”.
• Support mobile : mise en cache des pages par référent ou par groupe d'agents utilisateurs respectivement
• Gestion CDN : Gestion CDN transparente des bibliothèques de médias, des fichiers de thèmes, etc.

Ces capacités sont particulièrement précieuses pour les sites web, où l'accès global est fréquent :

• Variantes de la même page sur différents appareils, dans différentes régions, dans différentes langues
• Certains contenus peuvent être mis en cache, d'autres doivent être en temps réel (par exemple, le prix, l'inventaire, le statut de l'utilisateur).

4.3 “Ordre d'habilitation recommandé” par le W3TC”

Commande recommandée :

1. Commencez par activer la mise en cache des pages uniquement
   Vérifier : la CFT est désactivée, le contenu est cohérent, les processus clés relatifs à l'état de connexion, au multilinguisme et au commerce électronique fonctionnent.
2. Réactiver le cache du navigateur
   Objectif : accélérer le chargement des visites et des ressources statiques et réduire les téléchargements répétés à travers les continents.
3. Réévaluer le cache d'objets / le cache d'objets de la base de données
   Applicable : site dynamique (WooCommerce, système d'adhésion, requêtes complexes).
   N/A : Les stations à contenu unique peuvent avoir un rendement limité ou même augmenter la consommation de ressources.
4. Touche finale Compression / Latency Scripting / Front End Optimisation
   Comme il s'agit de la couche la plus susceptible de déclencher des anomalies fonctionnelles, une liste de tests de régression doit être établie (paiements, formulaires, suivi, fenêtres contextuelles, menus, changement de langue, etc.)

Rappel de WooCommerce sur la “Configuration du plugin de cache”.Les pages critiques ne sont pas mises en cache et il est recommandé d'éviter la compression des fichiers JS.

Matrice de comparaison des quatre plug-ins

Remarque : il ne s'agit pas de savoir “qui est le meilleur”, mais “qui correspond le mieux à votre scénario”.

dimension (math.)	WP Rocket	LiteSpeed Cache	WP Super Cache	W3 Total Cache
positionnement de base	Une intégration astucieuse (mise en cache + optimisation)	Mise en cache au niveau du serveur (repose sur LSCache)	Mise en cache du HTML statique	Cadre de performance (couches de cache multiples + CDN)
dépendant de l'hôte	Faible (universel)	Élevé (nécessite LiteSpeed/OpenLiteSpeed pour fonctionner comme cache central)	Faible (universel)	Moyen (universel, mais plus dépendant de l'environnement/configurabilité)
Coûts d'apprentissage	bas-moyen	Moyen	低	Élevé
Recommandation de la station de contenu	Très élevé	Très élevé (à condition qu'il soit respecté)	Très élevé	Moyenne-élevée (en fonction de l'équipe)
Site de commerce électronique/adhésion	Disponible mais à exclure avec précaution (les pages clés de WooCommerce ne sont pas mises en cache)	Disponible, mais besoin accru de règles/stratégies de découpage	est disponible, et WooCommerce mentionne la compatibilité native et l'absence de mise en cache des pages clés par défaut	Disponible et adapté au contrôle technique
budget	couvrir les coûts	logiciel gratuit	logiciel gratuit	Version gratuite + payante

“Incidents de cache et liste de contrôle pour la prévention

1. trois causes profondes de “contenu erroné” dues à la mise en cache

A. Traiter les pages “avec état” comme des “pages statiques sans état”

Typique : la page de compte, le panier d'achat, la page de paiement sont mis en cache.WooCommerce Les fonctionnaires ont souligné à plusieurs reprises Le panier, la caisse et le compte ne doivent pas être mis en cache.

B. Les variantes multilingues/multidevises/régionales ne sont pas correctement mises en cache.

Si votre site affiche un contenu différent en fonction de cookie, des paramètres de la requête et de la situation géographique, le cache doit prendre en compte les “dimensions de la variante”. Sinon, un cache généré par un utilisateur de la région A peut être réutilisé par un utilisateur de la région B.

C. Optimisation du front-end (réécriture JS/CSS) entraînant des anomalies fonctionnelles

En particulier, la compression JS, la fusion et l'exécution différée.Éviter la compression des fichiers JS。

2. liste de contrôle des tests de régression avant le lancement

• La connexion et la déconnexion sont normales
• Les formulaires de soumission (formulaire de contact, d'abonnement, d'enregistrement) fonctionnent correctement.
• Processus de commerce électronique : ajouter un achat → coupon → expédition/taxes → paiement → page de commande
• Stabilité du passage au multilinguisme (contenu, URL, hreflang, devise après le passage)
• Les menus mobiles, les fenêtres contextuelles, le défilement et le chargement paresseux fonctionnent correctement.
• Vérifier si les scripts se déclenchent toujours (GA, Meta Pixel, événements de transformation)

problèmes courants

Q1：Pourquoi l'accès à l'étranger reste-t-il lent bien que j'aie installé le plugin de mise en cache ?

La raison la plus fréquente est que vous n'avez résolu que le problème de la duplication du rendu à la source, mais pas celui de la latence du réseau intercontinental.
Les plugins de mise en cache permettent au serveur de recracher le contenu plus rapidement (TTFB down), mais les ressources statiques (images, CSS, JS, polices) et le RTT pour les liens globaux doivent toujours être mis en cache. CDN pour réduire la distance.
👉 Le chemin à suivre est donc le suivant :Stabilisez d'abord le cache de la station source.Puis CDN pour la distribution mondiale.。

Q2 : Pourquoi le contenu n'est-il pas mis à jour lorsque je le modifie après la mise en cache ?

Parce que vous voyez l“”ancien cache". Idée de solution :

• Créer une stratégie de nettoyage : nettoyer le cache correspondant après la mise à jour des articles/pages (au lieu d'un nettoyage de l'ensemble du site).
• Pour les scénarios avec échauffement/crawlers : nettoyer et ensuite s'échauffer, sinon la première visite sera lente.
• Pour CDN : il faut tenir compte du fait que les bords de CDN peuvent également mettre en cache d'anciennes ressources.

Q3 : Puis-je installer WP Rocket + WP Super Cache en même temps ?

Non recommandé. Un seul plugin de mise en cache des pages à la fois est la solution la plus stable. Vous pouvez comprendre l'idée de “un pour la mise en cache et un pour l'optimisation” comme une “division du travail”, mais en réalité, ils touchent souvent à la mise en cache des pages et à la réécriture des ressources, et la probabilité de conflit est élevée. Il est plus recommandé de choisir un “plugin de mise en cache principal”, d'autres besoins avec un outil unique plus clair pour combler l'écart.

Q4 : N'est-il pas dangereux d'utiliser la mise en cache pour les sites de commerce électronique ?

Ce n'est pas dangereux, c'est l'absence de règles qui est dangereuse.Recommandations WooCommerceTrès clair : le panier / la caisse / le compte ne sont pas mis en cache et la compression JS est évitée.
En outre, WooCommerce mentionne également qu'il fonctionne avec la norme Compatibilité native de WP Super Cacheet éviter de mettre en cache les pages critiques par défaut.
Le site de commerce électronique peut donc être mis en cache, mais il doit être testé en tant que “changement réel”.

Q5 : Dois-je choisir LiteSpeed Cache ou WP Rocket ?

• Êtes-vous sûr que l'hôte est LiteSpeed/OpenLiteSpeed ?Cache : Priorité LiteSpeed Cache (gratuit et solide, avec les avantages principaux de LSCache au niveau du serveur)
• Vous n'êtes pas sûr de la pile d'hébergement / vous ne voulez pas faire de compromis / vous voulez intégrer et économiser.WP Rocket est plus stable
• Vous êtes un site de contenu et vous êtes sensible au budgetWP Super Cache est plus stable et plus léger.

Cache plug-in avec CDN

Le plugin de mise en cache résout le problème du “moindre comptage des stations sources et de la réduction du TTFB” ; CDN résout le problème des “ressources statiques et des pages plus proches des utilisateurs mondiaux”. La superposition des deux est la solution optimale commune pour l'accès global.

• Une combinaison courante de stations de contenu :Page Cache + CDN Distribution statique
• Combinaisons courantes de stations dynamiques :Page Cache (contrôle étroit des exclusions) + Object Cache (à la demande) + CDN distribution statique

👉 Lire :Accélération CDN (nœud global et politique de mise en cache)

Combinaisons recommandées pour la mise en cache de sites web

1. site de contenu / blog / site documentaire

Objectif : Réduire le TTFB, rendre le premier écran plus stable, réduire la pression sur les serveurs, travailler avec CDN pour la distribution mondiale.

1.1 La combinaison commerciale la plus simple

• WP Rocket (mise en cache des pages + préchargement + optimisation frontale)
  • CDN (aller à CDN page talk)

Applicable :

• Vous voulez “peu de frais, des résultats rapides, peu de risques”.”
• Thèmes/plugins à foison, pour réduire les problèmes de compatibilité.

Points d'attention :

• Les optimisations frontales (notamment la latence JS) sont activées par étapes pour éviter les anomalies fonctionnelles (menus, formulaires, suivi, etc.).
• Les sites qui font l'objet de révisions et d'affichages fréquents devraient avoir une stratégie de “nettoyage + réchauffement”, sinon la première visite sur les pages froides sera lente.

1.2 Combinaisons classiques libres et stables

• WP Super Cache (cache HTML statique): Générer du HTML statique à partir de pages dynamiques, principalement pour les utilisateurs non enregistrés.
  • CDN

Applicable :

• Budget sensible mais stable
• Les visiteurs ne se connectent pas
• Rythme contrôlé des mises à jour de contenu

Points d'attention :

• Il s'agit d'une combinaison de “mise en cache de la page d'abord”, ne vous attendez pas à ce qu'elle résolve toutes les complexités CSS/JS en cours de route !

---

2. site d'entreprise / site de marque / page d'atterrissage

Objectif : Soyez rapide, mais surtout “ne rompez pas le lien de conversion à cause de l'optimisation”.

2.1 Robuste et contrôlable (stations de placement/conversion mondiales recommandées)

• WP Rocket
• + (optionnel) optimisation des images légères (vous avez une page “Optimisation des images”)
  • CDN

Pourquoi c'est bon pour les stations de conversion :

• Les sites de conversion craignent que les “formulaires/popups/scripts de suivi soient perturbés par l'optimisation”
• WP Rocket est plus “intégré” dans le sens où vous pouvez activer et tester la régression de chaque élément d'un système.

Le “principe en ligne” du site web de l'entreprise :

• L'optimisation des performances est un “changement à mettre en œuvre” et doit faire l'objet d'une liste de contrôle des tests de régression.
• Tout paramètre impliquant la latence, la fusion ou la compression de JS doit être vérifié dans un environnement de préversion avant d'être mis en ligne !

---

3. site de commerce électronique WooCommerce (commandes + sécurité dynamique des pages)

Objectif : Il est important d'être rapide, mais aussi de veiller à ce que les pages du panier, de la caisse et du compte soient parfaitement correctes.

Les points officiels de WooCommerce concernant le plugin de mise en cache sont très clairs :Panier d'achat / Checkout / Page de compte Do Not CacheIl est également recommandé d'éviter la compression des fichiers JavaScript pour minimiser les problèmes de compatibilité.

3.1 Des itinéraires gratuits et sûrs, plus adaptés aux débutants

• WP Super Cache + WooCommerce
  • CDN

Pourquoi est-il considéré comme un “point de départ plus sûr” ?

• WooCommerce mentionne officiellement qu'il est nativement compatible avec WP Super Cache, et informera WP Super Cache qu'il ne met pas en cache des pages clés telles que le panier/la caisse/les comptes par défaut.
• Pour les sites qui se lancent dans le commerce électronique, “pas d'accident d'abord” est plus important que “des performances extrêmes”.

3.2 Si vous utilisez un hébergeur LiteSpeed (gratuit mais puissant)

• LiteSpeed Cache (doit être un hôte LiteSpeed/OpenLiteSpeed pour profiter de la mise en cache du serveur principal)
• + (optionnel) cache d'objets (Redis/Memcached, en fonction de la capacité d'hébergement et de la taille du site)
  • CDN

Applicable :

• La pile d'hôtes est claire et vous êtes prêt à établir des règles de mise en cache et des politiques d'exclusion.
• Le volume des commandes et des marchandises est important, et un poste source plus puissant est nécessaire pour supporter la pression.

3.3 Équipes d'ingénierie/commerce électronique complexe (multi-modules contrôlables)

• W3 Total Cache (cadre de performance, couche multi-cache intégrée à CDN)
  • Mise en cache d'objets (à la demande)
  • CDN

Applicable :

• Avec Dev/Ops, vous pouvez mettre en service un “module étape par étape d'activation + test de pression + test de régression”.
• Nécessité d'une mise en cache des fragments / variantes plus complexes de la stratégie (par exemple, mise en cache fine par appareil/région/langue)

---

4. site d'adhésion / communauté / cours en ligne (nombreuses connexions, forte personnalisation)

Objectif : Rendre le contenu public rapide tout en garantissant que “le contenu des utilisateurs connectés n'est pas enchaîné”.

4.1 Sauvegarde mais nécessité de stratégies d'exclusion strictes

• WP Rocket
• + (optionnel) la mise en cache des objets (si les requêtes dynamiques sont nombreuses)
  • CDN

Points clés :

• Vous devez exclure de la mise en cache les pages “modifiées par l'utilisateur” : Centre personnel, Commandes, Progression des études, Messages, Panier d'achat, etc.
• Ce type de site est le plus exposé au risque de “voir le contenu d'autres personnes/de mauvaises autorisations”, et les risques doivent être précisés sur la page.

4.2 LiteSpeed Hosting + Politique avancée

• LiteSpeed Cache (mise en cache du serveur + outils de politique plus sophistiqués)
• + mise en cache d'objets (à la demande)
  • CDN

Points clés :

• Les sites d'adhésion ont tendance à avoir besoin d'une mentalité “corps cachable + fragment non cachable”.
• Les stratégies d'échauffement et de nettoyage doivent être affinées, faute de quoi les utilisateurs verront encore d'anciens contenus après la mise à jour.

Cache web “Recueil de cas de déminage”

Cas 1 : Installation du plugin de mise en cache, la vitesse est presque inchangée

Phénomène :

• Débits locaux/co-régionaux corrects, débits outre-mer (intercontinentaux) encore lents
• TTFB s'est améliorée, mais les temps de chargement globaux n'ont pas diminué de manière significative.

Causes courantes :

• Vous ne faites que la mise en cache de la source (TTFB), mais les ressources statiques (images/JS/CSS/fonts) sont toujours chargées à partir de la source à travers les continents.
• Les scripts tiers (publicités, chat, statistiques) ralentissent le rendu et l'interaction.
• Lenteur des téléchargements due à la taille importante des images (la mise en cache ne résout pas le problème de la taille du “premier téléchargement”).

Idée de solution :

• Le plugin de cache s'occupe d'abord du “sous-comptage de la source + des hits”.”
• Ressources statiques pour CDN
• Optimisation de l'image en dehors de l'image
• Les scripts de tierces parties permettent d'appliquer des stratégies de retardement et de division.

Lecture :

• CDN Accélération : nœuds globaux et stratégies de mise en cache
• Optimisation des images : format/compression/chargement lent

---

Cas 2 : Après avoir activé la mise en cache, la page est modifiée mais le frontend n'est pas mis à jour.

Phénomène :

• Le contenu/style a été mis à jour dans le backend et l'ancienne version est toujours affichée dans le frontend.
• Ou seules certaines régions sont mises à jour et d'autres restent inchangées (cas fréquent pour les stations mondiales).

Causes courantes :

• Le cache de la page n'a pas été vidé ou l'a été de façon incorrecte.
• L'échauffement/le moteur de recherche ne fonctionne pas, le cache nettoyé se refroidit, ce qui ralentit la première visite, alors que vous pensez à tort qu'il n'y a pas de mise à jour.
• Si vous activez la mise en cache de la périphérie CDN, la périphérie peut également conserver d'anciennes ressources.

Idée de solution :

• Créer une “stratégie de nettoyage après le lancement/la refonte” : nettoyer les pages pertinentes, pas un nettoyage en profondeur du site.
• Créer une stratégie d'échauffement pour les pages importantes (page d'accueil, pages d'atterrissage principales) afin d'éviter que “nettoyage = ralentissement”.”
• CDN Couche pour nettoyer les bords si nécessaire

---

Cas 3 : Contenu égaré après le passage au multilinguisme et au multi-devises

Phénomène :

• La page affiche toujours la langue précédente après le changement de langue
• Ou les utilisateurs de certaines régions voient la mauvaise devise/le mauvais contenu.

Causes courantes :

• Le cache ne fait pas de distinction entre les “dimensions variantes” (cookie / paramètres / préfixes linguistiques / sous-domaines).
• Le cache hit donne à l'utilisateur de la langue B les résultats de la page de la langue A.

Idée de solution :

• Clarifiez votre programme multilingue : directories/subdomains/parameters/cookie
• Ajouter des “politiques de variantes” aux règles de mise en cache ou exclure des pages clés
• Certains sites nécessitent des idées de mise en cache plus avancées (W3TC est mieux adapté au contrôle technique).

---

Cas 4 : Problèmes avec le panier/la caisse sur un site de commerce électronique où la mise en cache est activée

Phénomène :

• Panier d'achat avec une mauvaise quantité, un mauvais prix, le bouton de paiement ne fonctionne pas
• Se connecter et voir un contenu qui ne vous appartient pas (sérieusement)

Causes courantes :

• Les pages essentielles telles que le panier/la caisse/mon compte sont mises en cache.
• JS minify/merge provoque une incompatibilité entre les paiements et les composants dynamiques

Idée de solution :

• WooCommerce est officiel : cart/checkout/accounts ne doivent pas être mis en cache et il est recommandé d'éviter la compression des fichiers JS.
• Exécutez d'abord “page cache + exclure”, puis envisagez l'optimisation du front-end.
• Si vous utilisez WP Super Cache, WooCommerce mentionne qu'il est nativement compatible et évite la mise en cache des pages clés par défaut.

---

Cas 5 : Menu/formulaire/popup cassé après avoir activé “Delay JS/Merge Scripts” (retarder les scripts JS/fusionner les scripts).

Phénomène :

• Le menu de navigation ne s'ouvre pas
• La validation du formulaire a échoué ou n'a pas pu être soumise
• Exception Popup/Rollup
• Les statistiques/événements de conversion ne se déclenchent pas (le plus gros problème pour les sites de lancement)

Causes courantes :

• Le langage JS différé modifie le calendrier d'exécution des scripts : les scripts ne sont pas exécutés tant que l'utilisateur n'interagit pas avec eux, et certains composants reposent sur l'option “initialiser au chargement de la page”.”
• La fusion/compression peut modifier l'ordre des scripts ou rompre des dépendances.

WP Rocket décrit officiellement “l'exécution JS différée” comme l'une de ses plus fortes optimisations JS : les scripts sont différés jusqu'à ce que l'interaction avec l'utilisateur soit terminée afin de donner la priorité au rendu de la page. Il s'agit d'une grande capacité, mais elle implique également un risque de compatibilité plus élevé.

Idée de solution :

• Activation par étapes : cache, puis images, puis CSS, puis JS.
• Ajouter des exclusions aux scripts clés (paiements, formulaires, menus, suivi)
• Effectuer une liste de contrôle des tests de régression pour chaque modification

---

Cas 6 : Seul LiteSpeed Cache est installé, mais il ne semble pas fonctionner.

Phénomène :

• LiteSpeed Cache est activé, mais TTFB ne baisse pas beaucoup.
• Les résultats ne sont pas évidents non plus

Causes courantes :

• Votre serveur n'est pas LiteSpeed/OpenLiteSpeed et ne peut pas utiliser les capacités principales de LSCache.
• Ou peut-être avez-vous activé un certain nombre d'optimisations, mais la “politique de mise en cache des pages/préchauffage/exclusion” n'a pas été créée !

Idée de solution :

• Vérifiez d'abord la pile de l'hôte : s'agit-il de LiteSpeed/OpenLiteSpeed (c'est un prérequis)
• Remettre l'accent sur “Page Cache Policy + Warm Up + Exclude + Clean Up” (Politique de mise en cache des pages + échauffement + exclusion + nettoyage)”
• Si ce n'est pas un hébergeur LiteSpeed : Considérez WP Rocket ou WP Super Cache