En septembre 2026, seules 39 % des boutiques WooCommerce mesurées par HTTP Archive réussissaient les Core Web Vitals de Google sur mobile. Et seules 12 % avaient un temps de réponse du serveur jugé « bon ».
Si votre boutique vous paraît lente, vous êtes donc loin d'être seul. Mais « lent » n'est pas un diagnostic. C'est un symptôme.
La plupart des guides vous donnent 18 astuces et une extension de cache à acheter. Celui-ci vous donne 9 tests. Vous les faites, vous lisez les chiffres, et vous réparez ce qui est vraiment cassé.
Pour rester honnêtes, nous avons passé chaque test sur notre propre boutique WooCommerce de test : WooCommerce 10.9, le thème par défaut Twenty Twenty-Five, 94 produits, aucun cache. D'abord telle quelle, avec 7 extensions. Puis avec les extensions qu'on trouve sur la plupart des boutiques : liste de souhaits, avis produits, import AliExpress, factures PDF, suivi de commande, chat en direct. 15 extensions au total. Vous verrez les vrais résultats à chaque étape. Et ce qui la ralentissait n'était pas seulement ce qu'on croyait.
Source des chiffres d'ouverture : rapport Core Web Vitals Technology de HTTP Archive, données Chrome UX Report de septembre 2026 (notre calcul : sites qui réussissent sur sites mesurés).
Les 6 mots à connaître, sans jargon
- Serveur : l'ordinateur, chez votre hébergeur, qui fabrique vos pages et les envoie à vos visiteurs.
- Temps de réponse du serveur (TTFB) : le temps pendant lequel votre visiteur fixe un écran blanc avant que la page commence à arriver.
- Cache : une copie toute prête d'une page, mise de côté pour être servie tout de suite au lieu d'être refabriquée.
- PHP : le langage dans lequel WordPress et WooCommerce sont écrits. C'est votre hébergeur qui choisit sa version, et plus elle est récente, plus c'est rapide.
- Extension (plugin) : un module que vous installez. Chacune ajoute du code, qui peut tourner sur chaque page, même quand vous ne le voyez pas.
- Back-office (admin) : votre arrière-boutique, où vous gérez produits et commandes. Vos clients ne la voient jamais.
Étape 1 : votre site est-il vraiment lent, et pour qui ?
Le symptôme. Vous « sentez » que c'est lent. Un client s'est plaint. Ou un test de vitesse affiche un score rouge, et c'est la panique.
Le test.
- Ouvrez PageSpeed InsightsSur pagespeed.web.dev, collez l'adresse de votre fiche produit la plus vue, pas seulement l'accueil.
- Lisez d'abord le bloc du haut« Découvrez l'expérience de vos utilisateurs » montre les données de vrais visiteurs Chrome sur les 28 derniers jours.
- Puis le test de laboratoireLe score et les cinq mesures en dessous viennent d'une visite simulée sur un téléphone moyen de gamme.
Ce que ça veut dire. Les seuils de Google, d'après web.dev, s'appliquent à 3 visites sur 4 :
| Mesure | Ce qu'elle mesure | Bon | Mauvais |
|---|---|---|---|
| LCP | Le moment où le contenu principal (souvent la photo produit) s'affiche | 2,5 s ou moins | plus de 4 s |
| INP | La rapidité de réaction à un toucher ou un clic | 200 ms ou moins | plus de 500 ms |
| CLS | À quel point la page saute pendant le chargement | 0,1 ou moins | plus de 0,25 |
« Aucune donnée » dans le bloc du haut est normal pour une petite boutique : il n'y a pas encore assez de trafic Chrome. Vous travaillez alors avec le test de laboratoire, et avec vos propres mesures des étapes suivantes.
La vitesse compte aussi pour Google, avec une nuance. Google écrit que les Core Web Vitals « are used by our ranking systems », mais qu'il cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de la page est moyenne (Google Search Central).
Sur notre boutique de test, avec les 15 extensions courantes. Score de 67 sur mobile, aucune donnée de vrais visiteurs. La photo principale mettait 3,8 secondes à s'afficher, bien au-dessus de l'objectif de 2,5 secondes. Et une surprise : un CLS de 0,373, franchement dans le rouge. La page n'était pas seulement lente, elle sautait.
Le remède. Rien pour l'instant. Notez votre score, votre LCP, votre INP ou TBT et votre CLS dans un tableau « avant ». Faites le test 3 fois et gardez la valeur du milieu.
Étape 2 : le serveur met-il trop de temps à répondre ?
Le symptôme. Un écran blanc avant que quoi que ce soit n'apparaisse. Toutes les pages sont lentes, même les plus simples.
Le test.
- Ouvrez les outils de développement de ChromeClic droit, Inspecter, puis l'onglet Réseau. Cochez « Désactiver le cache ».
- Rechargez la pageCliquez sur la toute première ligne, la page elle-même, puis sur l'onglet Timing.
- Lisez l'attente de la réponse du serveurC'est votre temps de premier octet (TTFB). Faites-le sur 4 pages : l'accueil, une fiche produit, le panier, et une page en étant connecté.
Imaginez un restaurant. Sans cache, la cuisine prépare chaque plat de zéro pour chaque client, même si c'est le même plat commandé cent fois par jour. Avec un cache, le plat est déjà prêt sur le comptoir. Votre serveur, c'est la cuisine, et une page WooCommerce, un plat compliqué.
Ce que ça veut dire. Selon web.dev, la plupart des sites devraient viser un TTFB de 0,8 seconde ou moins. Ce n'est pas un Core Web Vital, mais tout le reste l'attend. La Santé du site de WordPress signale d'ailleurs une réponse de page au-delà de 600 ms.
- Accueil rapide, panier lent : un cache de page masque un serveur lent. Le panier et la commande, qui ne peuvent pas être mis en cache, paient le prix fort.
- Tout est lent : pas de cache de page du tout, ou un serveur et un PHP à revoir (étape 3).
Sur notre boutique de test. Avec ses 7 extensions, chaque page mettait environ une demi-seconde à être fabriquée : 0,45 s pour l'accueil, 0,51 s pour une fiche produit, 0,47 s pour le panier. Avec les 15 extensions courantes, 0,6 à 0,7 s. Sur le même serveur, un simple fichier image répondait en 7 millisecondes. Presque toute l'attente venait donc du serveur qui refaisait la page avec PHP, pour chaque visiteur.
Nous avons alors essayé le remède classique, le temps d'une soirée : un cache de page, avec LiteSpeed Cache réglé par défaut, puisque notre serveur de test tourne sous LiteSpeed.
| Page | Sans cache de page | Avec cache de page |
|---|---|---|
| Accueil | 0,42 à 0,50 s | 0,009 s |
| Fiche produit | 0,50 à 0,58 s | 0,007 s |
| Panier | 0,46 à 0,47 s | 0,50 s (jamais en cache) |
Temps de réponse mesuré depuis le serveur lui-même, 4 requêtes par page, le 21 octobre 2026. Nous avons retiré le cache ensuite pour remettre la boutique dans son état d'origine.
Le remède.
- Ajoutez un cache de page. Gratuits : LiteSpeed Cache si votre hébergeur tourne sous LiteSpeed (son cache demande un serveur LiteSpeed ou son CDN), ou WP Super Cache partout ailleurs. Payant : WP Rocket, dès 49,95 € par an pour un site selon sa page tarifs en octobre 2026. Quel que soit votre choix, le panier, la commande et Mon compte doivent rester hors cache, comme le recommande WooCommerce.
- Accélérez ce qui ne peut pas être mis en cache : PHP et ses caches, à l'étape 3.
Étape 3 : lisez le rapport Santé du site
Le symptôme. Vous ne savez pas par où commencer. Ou le site a « toujours » été lent.
Le test. Dans votre admin, allez dans Outils, puis Santé du site. Ouvrez l'onglet État et regardez chaque ligne marquée « Performances ».
Ce que ça veut dire.
| Vous voyez | Ça veut dire | Faites ceci |
|---|---|---|
| Mise en cache des pages non détectée, serveur lent | Chaque visiteur attend PHP (étape 2) | Ajoutez un cache de page |
| Version de PHP dépréciée | WordPress et WooCommerce recommandent tous deux PHP 8.3 ou plus | Changez de version dans le panneau de l'hébergeur, sur une copie d'abord |
| Le cache Opcode n'est pas activé | PHP relit tout le code de WordPress à chaque page, comme un cuisinier qui relirait la recette pour chaque plat | Demandez à l'hébergeur d'activer « OPcache » : un e-mail, aucune extension |
| Utilisez un cache objet persistant | WordPress va chercher les mêmes informations encore et encore, au lieu de les garder sous la main | Demandez à l'hébergeur s'il propose Redis, puis installez Redis Object Cache (gratuit) |
| Les options chargées automatiquement peuvent affecter les performances | Plus de 800 Ko de réglages chargés à chaque page, souvent laissés par d'anciennes extensions | Faites le ménage avec WP-Optimize ou un développeur |
Sur notre boutique de test. PHP 8.1, qui ne reçoit plus de correctifs de sécurité selon php.net. Pas de cache de page. Pas de cache objet persistant. Et le plus gros : le cache d'opcodes n'était pas seulement désactivé, son extension n'était même pas chargée. Un réglage d'hébergement que nous ne pouvons pas changer nous-mêmes. Les options chargées automatiquement, elles, allaient bien : 89 Ko.
Le remède. Commencez par ce que la Santé du site classe en critique. Pour PHP et OPcache, vous ne touchez à rien vous-même : copiez les lignes de la Santé du site dans un message à votre hébergeur. Ce seul e-mail fait souvent plus que n'importe quelle extension.
Étape 4 : trouvez les extensions qui se chargent partout (Query Monitor)
C'est l'étape la plus technique. Si c'est trop, lisez les résultats ci-dessous, puis confiez le test à un développeur : montrez-lui cette partie, il saura quoi faire.
Le symptôme. Le serveur reste lent même sur les pages qui ne peuvent pas être mises en cache. Ou le site est devenu plus lent après une installation.
Le test.
- Installez Query MonitorC'est gratuit, et seuls les administrateurs voient son panneau.
- Ouvrez une fiche produit en étant connectéCliquez sur le nouvel élément de la barre d'admin. Lisez le temps de génération de la page et le nombre de requêtes en base.
- Ouvrez « Queries by Component »Le panneau montre le travail de chaque extension sur cette page. Regardez aussi « HTTP API Calls » : les appels vers l'extérieur pendant le chargement.
Ce que ça veut dire. Beaucoup d'extensions chargent leur code sur toutes les pages, même là où elles ne servent à rien. Un importateur AliExpress tourne quand un client lit votre page d'accueil. Une extension d'avis tourne sur votre page de commande. Chacune coûte quelques millisecondes de serveur, à chaque visite, et ça s'additionne.
Sur notre boutique de test. Nous avons ensuite installé les extensions qu'on trouve sur la plupart des boutiques WooCommerce : une liste de souhaits (YITH WooCommerce Wishlist), des avis produits (Customer Reviews for WooCommerce), l'import AliExpress (Ali2Woo), les factures PDF (PDF Invoices & Packing Slips), le suivi de commande (ParcelPanel) et un chat (Tidio). 15 extensions au total. Puis nous avons chronométré le chargement de chacune, à chaque page :
| Extension | Temps serveur ajouté, à chaque page |
|---|---|
| WooCommerce | 77 ms |
| Ali2Woo | 73 ms |
| Customer Reviews for WooCommerce | 33 ms |
| Une extension de flux produits (versions gratuite et Pro) | 21 ms |
| Une extension SMTP | 10 ms |
| ParcelPanel | 7 ms |
| PDF Invoices & Packing Slips | 3 ms |
| Tidio, YITH Wishlist | moins d'1 ms (leur travail se fait plus loin dans la page) |
Mesuré le 21 octobre 2026 sur une fiche produit : chargement du fichier principal de chaque extension, avec un chronomètre temporaire sur le serveur, valeur du milieu sur 4 requêtes. Le travail fait plus loin dans la page n'est pas réparti par extension.
La page entière mettait désormais 0,73 s à se fabriquer au lieu de 0,51 s, avec 245 requêtes en base au lieu de 152. Vos visiteurs attendent plus longtemps avant de voir quoi que ce soit, sur chaque page, sans que vous ayez touché à vos produits.
Le remède. Mettez l'extension à jour, ou remplacez-la. Si rien ne ressort dans Query Monitor, faites le test de conflit que recommande WooCommerce sur une copie du site : désactivez la moitié des extensions, mesurez, et recommencez par moitiés jusqu'à trouver la coupable. Avec 20 extensions, 5 tours suffisent. Puis désinstallez Query Monitor : inutile de le garder toute l'année.
Étape 5 : comptez ce que vos extensions chargent chez le visiteur, et coupez
Le symptôme. Les fiches produit paraissent lourdes. PageSpeed Insights parle de « JavaScript inutilisé ». Vous avez beaucoup d'extensions et vous vous demandez lesquelles pèsent.
Le test. Dans l'onglet Réseau de Chrome (« Désactiver le cache » coché), filtrez sur JS, puis sur CSS. La barre du bas affiche le nombre de fichiers et le poids transféré. Le chemin de chaque fichier vous dit quelle extension l'a chargé : /wp-content/plugins/nom-de-l-extension/.
Sur notre boutique de test. Avec ces mêmes extensions courantes, voici ce qu'un visiteur télécharge sur une seule fiche produit :
| Fiche produit | Boutique avec 7 extensions | Avec les extensions courantes (15) |
|---|---|---|
| Poids téléchargé | 537 Ko | 921 Ko |
| Fichiers | 56 | 87 |
| JavaScript | 122 Ko | 467 Ko |
| Score PageSpeed (mobile) | 74 à 75 | 67 |
| Photo principale affichée (LCP) | 2,9 à 3,2 s | 3,8 s |
Qui a ajouté quoi : YITH Wishlist chargeait 151 Ko (7 fichiers) sur toutes les pages, accueil compris. Ali2Woo ajoutait 45 Ko, Customer Reviews 32 Ko. Et ces extensions tiraient des bibliothèques WordPress en plus : 204 Ko au lieu de 68 Ko. ParcelPanel, PDF Invoices & Packing Slips et Tidio (pas encore relié à un compte) ne chargeaient rien sur cette page.
Le remède : soyez sans pitié. Passez votre liste d'extensions une par une, et posez deux questions :
- Est-ce que je m'en sers vraiment ?Pas « ça pourrait servir un jour » : est-ce que vous l'utilisez chaque semaine ? Si non, supprimez-la. La désactiver ne suffit pas, certaines laissent derrière elles des tâches planifiées et des réglages.
- Est-ce qu'elle se charge partout ?Si vous en avez besoin mais qu'elle charge ses fichiers ou son code sur toutes les pages, remplacez-la par une extension plus légère, qui ne se charge que là où elle sert.
Pourquoi les boutiques finissent avec autant d'extensions, et comment Plume simplifie tout ça
Sur WooCommerce, presque chaque besoin passe par une extension. Une pour le suivi des commandes. Une pour synchroniser vos commandes AliExpress, comme Ali2Woo. Un chatbot. Une extension de factures. Chacune vient d'un éditeur différent, avec ses menus, ses bannières, ses scripts et ses tâches planifiées. Au bout d'un an, une petite boutique en fait tourner 20 ou 30 sans problème.
C'est exactement pour ça que nous avons créé Plume : une suite WooCommerce légère qui couvre ces besoins du quotidien, au même endroit. Chaque extension fait un seul travail, et « les scripts d'un plugin ne se chargent que sur les pages où il sert ». Nous avons mesuré nos extensions sur la même boutique, de la même façon, à côté des extensions courantes :
| Besoin | Extension courante | Coût par page | Plume | Coût par page |
|---|---|---|---|---|
| Suivi des commandes | ParcelPanel | 7 ms, 0 Ko | Plume Tracking | 6 ms, 0 Ko |
| Import AliExpress et synchro des commandes | Ali2Woo | 73 ms, 45 Ko | Plume Product AI + AliExpress Sync | 7 ms, 0 Ko |
| Factures PDF | PDF Invoices & Packing Slips | 3 ms, 0 Ko | Plume Invoices | 11 ms, 0 Ko |
| Chat en direct | Tidio | moins d'1 ms, 0 Ko tant qu'il n'est pas relié | Plume Chat | 3 ms, 13 Ko |
| Total | 84 ms, 45 Ko | 26 ms, 13 Ko |
Temps serveur ajouté sur chaque fiche produit, et fichiers téléchargés par le visiteur, mesurés le 21 octobre 2026. Deux précisions honnêtes. Plume Invoices coûte un peu plus de temps serveur que PDF Invoices & Packing Slips, car il gère aussi la facture électronique. Et Tidio ne charge rien tant qu'il n'est pas relié à un compte ; une fois relié, sa bulle téléchargeait environ 526 Ko sur le site de Tidio lui-même, dans notre test des chats.
Au total, les quatre mêmes besoins coûtent environ trois fois moins de temps serveur avec Plume, et une fraction des fichiers. Avec un seul abonnement, un seul style et un seul support, au lieu de quatre éditeurs.
Mais soyons clairs : des extensions plus légères ne répareront pas un serveur sans cache ni une photo produit de 3 Mo. Pour la plupart des boutiques, les étapes 2, 3 et 6 comptent tout autant. Faites-les aussi.
Étape 6 : vérifiez votre plus grosse image, et ce qui fait sauter la page
Le symptôme. La page s'affiche, mais la grande photo arrive en dernier. Ou les éléments bougent pendant le chargement, et votre client touche le mauvais bouton.
Le test. Dans PageSpeed Insights, descendez jusqu'aux diagnostics et ouvrez-en deux : l'élément LCP, c'est-à-dire le plus gros élément à l'écran (sur une fiche produit, en général votre photo principale), et les responsables des décalages de mise en page, ce qui fait sauter la page. Puis, dans l'onglet Réseau, filtrez sur Img et comparez la taille de chaque image à la taille où elle s'affiche.
Ce que ça veut dire. Une photo de 4 000 pixels affichée sur 800, ou plusieurs mégaoctets pour une seule image, suffisent à expliquer un LCP lent. Et un CLS élevé veut dire qu'un élément arrive en retard et pousse le reste : une galerie, une bannière, une image sans dimensions déclarées.
Sur notre boutique de test. La fiche produit téléchargeait 280 Ko d'images sur ordinateur, mais 575 Ko sur téléphone. Les écrans de téléphone, très denses, choisissent des versions plus grandes des mêmes photos. PageSpeed proposait d'économiser 41 Ko en améliorant la diffusion des images, et listait les responsables de notre CLS de 0,373.
Le remède. Redimensionnez les photos avant de les importer, exportez-les en WebP, et gardez des tailles d'image raisonnables dans les réglages de WooCommerce. Ne retardez jamais le chargement de la photo produit principale : c'est celle que votre client attend. Pour les décalages, corrigez les éléments que PageSpeed liste, en commençant par le premier.
Étape 7 : pourquoi le back-office WooCommerce est-il si lent ?
Le symptôme. La liste des commandes met des secondes à s'ouvrir. Enregistrer un produit rame. Votre boutique est rapide pour les clients, mais pas pour vous.
Pourquoi un cache n'aide pas. L'administration n'est jamais servie par un cache de page. Chaque clic est fabriqué par PHP et la base de données. Sur notre boutique de test, la liste des commandes mettait environ 1,05 seconde à répondre, deux fois plus qu'une fiche produit.
Le test, dans cet ordre.
- Le rangement de vos commandes (HPOS)WooCommerce, Réglages, Avancé, Fonctionnalités. Le « stockage des commandes haute performance » est une façon plus récente et plus rapide de classer les commandes. Il est activé par défaut sur les boutiques créées depuis WooCommerce 8.2 (octobre 2023). Les plus anciennes peuvent encore utiliser l'ancien système.
- Les actions planifiéesWooCommerce, État, Actions planifiées. C'est la liste de tâches de WooCommerce : e-mails à envoyer, données à nettoyer. Regardez les compteurs « En attente » et « Échoué ».
- WP-Cron, le réveilWordPress ne s'occupe de cette liste de tâches que lorsque quelqu'un visite votre site. Une boutique calme la nuit accumule les tâches.
- Les onglets d'admin ouvertsChaque onglet d'admin resté ouvert interroge votre site toutes les 15 à 120 secondes. Dix onglets toute la journée, ça compte.
Ce que ça veut dire.
| Vous voyez | Ça veut dire | Faites ceci |
|---|---|---|
| « Stockage des publications WordPress (ancien) » sélectionné | Les commandes vivent dans les anciennes tables, plus lentes | Passez à HPOS après une sauvegarde, sur une copie d'abord |
| Des milliers d'actions en attente | WP-Cron ne passe pas assez souvent | Demandez à votre hébergeur ou à un développeur de mettre en place une « vraie tâche cron », pour que la liste tourne toutes les quelques minutes, visites ou pas |
| Des actions échouées qui s'accumulent | Une tâche d'extension échoue en boucle | Ouvrez-les, trouvez l'extension, mettez-la à jour ou remplacez-la |
| Lent même avec peu de commandes | Serveur, PHP ou appels extérieurs | Retour aux étapes 3 et 4 |
Côté HPOS, le test de performance publié par WooCommerce, sur environ 400 000 commandes, mesurait la création de commandes environ 5 fois plus rapide, et la commande côté client environ 1,5 fois plus rapide (blog développeur de WooCommerce). C'est leur grosse boutique de test, pas une promesse pour la vôtre.
Étape 8 : testez le panier et la page de commande
Le symptôme. Le bouton « Ajouter au panier » réagit lentement. Le panier ou la commande mettent du temps à s'afficher.
Le test. Dans l'onglet Réseau, tapez wc-ajax dans la case de filtre et parcourez quelques pages. Une requête nommée get_refreshed_fragments apparaît-elle à chaque page ? C'est une petite requête en arrière-plan qui met à jour l'icône du mini-panier. Puis chargez votre panier et regardez son poids et son temps de réponse (étape 2).
Ce que ça veut dire. Depuis WooCommerce 7.8 (juin 2023), cette mise à jour du mini-panier ne tourne plus sur toutes les pages par défaut, seulement là où le mini-panier en a besoin (blog développeur de WooCommerce). Beaucoup d'anciens guides conseillent encore de le désactiver. Si vous le voyez toujours partout, c'est votre thème ou une extension qui l'impose.
Sur notre boutique de test. Aucune requête de fragments sur nos pages. En revanche, le panier était de loin la page la plus lourde : 862 Ko et 80 requêtes, dont 671 Ko de JavaScript. C'est le panier en blocs de WooCommerce et les bibliothèques de blocs de WordPress dont il a besoin, sans aucune extension en plus. Et comme le panier ne peut jamais être mis en cache, son temps serveur restait autour d'une demi-seconde, cache ou pas.
Le remède. Vérifiez que votre cache de page exclut le panier et la commande. Puis accélérez le côté serveur, car rien d'autre n'aide ici : PHP récent avec OPcache, cache objet (étape 3). Enfin, regardez quelles extensions ajoutent des champs ou des scripts à la page de commande (étape 4).
Étape 9 : corrigez une chose, puis mesurez à nouveau
Changez une seule chose à la fois. Même page, même outil, même appareil. Faites chaque test 3 fois et gardez la valeur du milieu. Puis notez-la à côté de votre chiffre « avant ».
Soyez patient avec le bloc des vrais visiteurs de PageSpeed : il couvre les 28 derniers jours, donc une amélioration met jusqu'à quatre semaines à s'y voir entièrement. Le test de laboratoire et le temps de réponse du serveur, eux, réagissent tout de suite.
Appelez un développeur si le serveur reste lent sans extension à accuser, si votre base de données pèse plusieurs gigaoctets, ou si Query Monitor pointe votre thème.
Le résultat de votre check-up
Voici la grille complète. Trouvez votre symptôme, et commencez par la première ligne qui vous concerne.
| Symptôme | Cause la plus probable | Étape | Remède gratuit | Option payante |
|---|---|---|---|---|
| Toutes les pages lentes, écran blanc d'abord | Pas de cache de page | 2 | LiteSpeed Cache ou WP Super Cache | WP Rocket |
| Panier, commande et admin lents | PHP ancien, pas d'OPcache, pas de cache objet | 3 | PHP récent, Redis Object Cache | Un meilleur hébergement |
| Fiches produit lourdes | Extensions qui se chargent partout | 5 | Supprimer les extensions inutiles | Remplacer les extensions lourdes par une suite plus légère, comme Plume |
| Lent après une mise à jour | Une extension ou le thème | 4 | Query Monitor, test de conflit | Un développeur |
| La photo arrive en dernier, la page saute | Images trop grandes, décalages | 6 | Redimensionner, WebP, corriger les responsables | Un service d'optimisation d'images |
| Liste des commandes lente | Ancien stockage des commandes, actions planifiées | 7 | HPOS, vrai cron | Un développeur |
| Ajout au panier lent | Fragments forcés, serveur lent | 8 | Réglages du thème, étapes 2 et 3 | Un meilleur hébergement |
Mesurez avant d'acheter. La plupart des boutiques lentes n'ont pas besoin d'une extension de plus. Elles ont besoin du bon remède.
Notre boutique de test en est la preuve. Son premier problème, c'était un serveur qui refaisait chaque page, sans cache de page ni cache d'opcodes. Ensuite, les extensions courantes : 0,2 s de serveur en plus et près de 400 Ko de plus sur chaque fiche produit. Puis une page qui sautait, et des images deux fois plus lourdes sur téléphone. Mesurez dans cet ordre, et vous ne paierez pas un remède dont vous n'aviez pas besoin.
Et quand viendra le moment de faire le tri dans vos extensions, posez-vous une seule question pour chacune : mérite-t-elle sa place sur chaque page ?
Questions fréquentes
Pourquoi mon site WordPress est-il lent ?
Le plus souvent, le serveur met trop de temps à fabriquer chaque page : pas de cache de page, un PHP ancien ou privé de son cache d'opcodes, rien en cache mémoire. Viennent ensuite les images trop lourdes, les décalages de mise en page et les extensions qui chargent des scripts partout. Les étapes 1 à 4 du check-up vous disent laquelle.
Comment rendre mon site WordPress plus rapide ?
Dans cet ordre : un cache de page qui exclut le panier et la commande, PHP 8.3 ou plus avec son cache d'opcodes, un cache objet persistant, le stockage des commandes haute performance de WooCommerce, des images redimensionnées, puis le ménage dans les extensions. Mesurez après chaque changement.
Comment savoir quelle extension ralentit mon site ?
Installez l'extension gratuite Query Monitor et ouvrez son panneau « Queries by Component » sur une page lente. Si rien ne ressort, faites un test de conflit sur une copie du site : désactivez la moitié des extensions, mesurez, et recommencez par moitiés jusqu'à trouver la coupable.
Pourquoi le back-office WordPress est-il lent ?
L'administration n'est jamais servie par un cache de page : chaque clic est fabriqué par PHP et la base de données. Sur une boutique WooCommerce, vérifiez que le stockage des commandes haute performance est activé, regardez les actions planifiées en attente et échouées, assurez-vous que WP-Cron passe, et fermez les onglets d'admin inutiles.
WooCommerce ralentit-il WordPress ?
WooCommerce ajoute des pages qui ne peuvent pas être mises en cache, comme le panier, la commande et le compte client, et beaucoup de données : commandes, sessions, actions planifiées. Il n'est pas lent par nature : un cache de page qui exclut le panier, un PHP récent et le stockage des commandes haute performance font l'essentiel.
Comment vider le cache de mon site WordPress ?
Depuis le menu de votre extension de cache, avec son bouton de purge. Videz ensuite le cache de votre hébergeur ou de votre CDN s'il y en a un. Pour tester, ouvrez aussi la page en navigation privée, ou cochez « Désactiver le cache » dans les outils de développement de Chrome.
Comment déboguer un site WordPress ?
Commencez par Outils, Santé du site, qui liste les problèmes critiques. Installez ensuite Query Monitor pour voir les requêtes, les erreurs PHP et les appels extérieurs de chaque page. Enfin, faites un test de conflit sur une copie du site, extension par extension.
Shopify est-il plus rapide que WooCommerce ?
En moyenne, les sites Shopify réussissent plus souvent les Core Web Vitals de Google : 76 % sur mobile contre 39 % pour les boutiques WooCommerce, selon les données HTTP Archive de septembre 2026. Mais Shopify héberge et met en cache chaque boutique lui-même, alors que la vitesse d'une boutique WooCommerce dépend de son hébergement et de ses réglages, que vous maîtrisez.
Je vends moi-même sur WooCommerce, et je développe des extensions légères à partir de ce que je vis avec mes propres boutiques. Plume, ce sont les essentiels d'une boutique, sans l'usine à gaz.