Vous avez installé une extension de cache. Le site est peut-être un peu plus rapide, ou pas du tout de façon notable, et vous vous demandez ce que vous avez payé. La réponse courte : une extension de cache ne fait qu’accélérer la livraison d’une page déjà assemblée. Si la page elle-même est lourde — un thème qui charge toute sa bibliothèque, un constructeur de pages qui affiche le même CSS sur chaque route, une base de données qui traîne derrière chaque requête — le cache sert simplement cette même lourdeur un peu plus vite. Il ne touche jamais à ce qui l’a rendue lourde au départ.
L’optimisation de la vitesse WordPress, c’est d’abord trouver laquelle de ces causes s’applique réellement, avant d’acheter une autre extension pour la corriger.
Ce qu’une extension de cache peut et ne peut pas faire
Une extension de cache enregistre le résultat HTML final d’une page pour que WordPress n’ait pas à la reconstruire à partir de la base de données à chaque visite. C’est un travail réel et utile — pour une page qui se reconstruit exactement de la même façon à chaque fois.
Ce qu’elle ne peut pas faire :
- Réécrire un thème ou un constructeur lourd. Si votre thème ou votre constructeur de pages charge toute sa bibliothèque CSS et JavaScript sur chaque page pour afficher une seule section, mettre le résultat en cache livre quand même ce même poids au navigateur du visiteur. L’extension n’a rien à couper; le poids est intégré à la page qu’elle met en cache.
- Corriger des pages qui ne peuvent tout simplement pas être mises en cache. Un panier, un passage à la caisse, une page de compte — du contenu différent pour chaque visiteur — ne peut pas être servi depuis un cache statique comme un billet de blogue. L’optimisation de la vitesse WordPress pour une boutique doit traiter ces pages à part, parce que l’extension est structurellement incapable de les aider.
- Nettoyer ce qui tourne de toute façon sur chaque page. Les extensions de formulaires, de fenêtres surgissantes, de carrousels et de suivi ajoutent chacune leur propre script, et plusieurs se chargent sur chaque page, que celle-ci utilise la fonctionnalité ou non. Une extension de cache ne sait pas et ne se préoccupe pas de laquelle fait réellement quelque chose; elle met la page en cache avec tout ce qui s’y trouve attaché.
- Corriger une base de données devenue lourde. Des années d’extensions installées puis retirées ont tendance à laisser des réglages dans la base de données que WordPress charge encore à chaque requête. La propre documentation de performance de WordPress recommande de garder ces données allégées et d’utiliser un vrai moteur de base de données ainsi qu’un cache côté serveur — rien de tout ça n’est le travail d’une extension de cache de page.
Le diagnostic, pas la liste : comment accélérer un site WordPress
La façon honnête de trouver où se situe le poids n’est pas de compter les extensions. Il n’existe aucune mesure officielle du nombre de millisecondes que coûte une extension donnée — la seule méthode réelle est d’en retirer une à la fois et de vérifier ce qui change, et c’est l’approche que WordPress.org lui-même recommande : désactiver ce dont vous pouvez vous passer, et mesurer, avec PageSpeed Insights ou les données de terrain que votre site recueille déjà. Dix extensions ne sont pas automatiquement un problème; trois extensions lourdes peuvent peser plus que dix légères. Ce qui compte, c’est ce que chacune fait — des requêtes supplémentaires à la base de données à chaque chargement, son propre script mis en file sur chaque page — pas le nombre affiché dans la liste des extensions.
La même logique s’applique au thème et à la version de PHP derrière lui. Une version plus récente de PHP donne généralement de meilleurs résultats qu’une plus vieille sur le même hébergement, sans coût autre que la mise à jour elle-même — la recommandation actuelle de WordPress.org est PHP 8.3 ou plus récent. Un thème lourd et chargé de graphismes donne de moins bons résultats qu’un thème léger qui fait le même travail, indépendamment des extensions qui s’y ajoutent.
Où se trouve habituellement le poids
Pour un site WordPress typique, voici les causes à vérifier, dans l’ordre :
- Le thème ou le constructeur. Charge-t-il du CSS et du JavaScript pour des fonctionnalités que la page n’utilise pas ?
- Les scripts d’extensions sur chaque page. Est-ce que les formulaires, carrousels et outils de suivi mettent leur code en file sur tout le site plutôt que seulement là où ils s’exécutent ?
- Le niveau d’hébergement. L’hébergement partagé échange le contrôle contre le coût; si le serveur lui-même répond lentement, aucune extension ne peut corriger ça.
- La base de données. Des années d’historique d’extensions ont-elles laissé des réglages à chargement automatique que plus personne n’utilise ?
- Pour une boutique : les fragments de panier et autres éléments dynamiques qui se rafraîchissent à chaque chargement, plus les pages de paiement qui ne peuvent tout simplement pas être mises en cache.
Une extension de cache arrive après toutes ces causes. Ça vaut la peine d’en avoir une, mais c’est une couche par-dessus la construction, pas un remplacement. Pour l’ordre général de correction des problèmes de vitesse sur n’importe quelle plateforme, voir l’ordre des correctifs de vitesse; les seuils qui déterminent ce que « assez rapide » veut vraiment dire sont couverts dans les seuils Core Web Vitals.
Améliorer la vitesse d’un site WordPress : extension ou reconstruction
Si le poids se trouve dans le thème, le constructeur ou des années d’extensions accumulées, une extension de cache ne fait que louer une correction partielle. Elle ne défera pas ce que le gabarit fait à chaque chargement de page. On construit nous-mêmes les sites WordPress et on règle ça au niveau du gabarit — en décidant ce qui se charge où avant même qu’une seule extension soit installée, plutôt que d’en ajouter une après coup pour compenser une construction lourde.
Construit ainsi dès le départ, un site d’au plus huit pages revient à 1 900 $ et une boutique à 3 900 $ — la rédaction fait partie de la construction, pas d’une ligne à part — avec un délai habituel de 10 jours ouvrables dès que les documents et les commentaires cessent d’être le goulot d’étranglement. Si vous passez ensuite à un autre développeur, vous gardez le site que vous avez payé — cette condition ne change pas selon qui en fait l’entretien par la suite. Des extensions s’ajoutent avec le temps — un formulaire ici, une fenêtre surgissante là — et chacune arrive avec ses propres scripts. Empêcher ça de revenir en douce fait partie de ce que couvre l’entretien, dont le prix est fixé après avoir examiné ce que le site fait tourner réellement.
Choisir WordPress en soi est une décision distincte de la vitesse — voir comment ça se compare à Wix si vous choisissez une plateforme plutôt que de corriger un site existant. Et si les pages de produits d’une boutique sont lentes précisément parce que les visiteurs ne trouvent pas ce qu’ils cherchent, c’est un problème différent avec sa propre solution.
Les images ont elles aussi leur propre correction, pas un réglage d’extension — voir Optimiser les images sans ralentir la boutique pour ce point précis.
Envoyez l’adresse de votre site et on vous dira si le poids se trouve dans les extensions ou dans la construction — et lequel des deux l’extension de cache n’allait de toute façon jamais corriger.
