WordPress est lent ? 9 causes et comment y remédier

Ton site WordPress met quatre à cinq secondes à charger, le panneau d'administration rame et le client t'écrit que "chez lui, ça mouline". C'est l'un des problèmes les plus courants que les propriétaires de sites rencontrent. La bonne nouvelle : dans neuf cas sur dix, la cause est l'une des quelques raisons bien connues, et elle peut être identifiée en une heure.

Ci-dessous, tu trouveras neuf raisons, classées par ordre de fréquence, qui ralentissent WordPress. Pour chacune, nous t'indiquons comment l'identifier et comment la corriger toi-même.

Sommaire

1. Comment vérifier si WordPress est vraiment lent ?
2. L'hébergement mutualisé est-il le coupable ?
3. As-tu trop de plugins ?
4. Les images sont-elles trop lourdes ?
5. Le site a-t-il le cache activé ?
6. Quelle version de PHP utilise le site ?
7. La base de données n'est-elle pas engorgée ?
8. Le thème ou le page builder ne sont-ils pas trop lourds ?
9. Les scripts externes ne bloquent-ils pas le chargement ?
10. Est-ce que wp-cron ne consomme pas trop de ressources ?
11. Par où commencer les réparations ?
12. FAQ

Comment vérifier si WordPress est vraiment lent ?

Avant de changer quoi que ce soit, mesure. Sans mesure, tu ne sais pas si la correction a eu un effet, et « il me semble plus rapide » n'est pas un résultat.

Trois outils suffisent :

• PageSpeed Insights (pagespeed.web.dev) affiche le score Google pour le mobile et l'ordinateur, ainsi que les indicateurs Core Web Vitals. Le plus important est le LCP, c'est-à-dire le temps après lequel le plus grand élément de la page est visible. Un bon résultat est inférieur à 2,5 secondes.
• GTmetrix ou WebPageTest détaillent le chargement sur un diagramme en cascade. On y voit quel fichier se charge le plus longtemps.
• TTFB (Time To First Byte), c'est-à-dire le temps jusqu'au premier octet de la réponse du serveur. Tu peux le vérifier avec les deux outils ou dans l'onglet Réseau de ton navigateur (F12). Si le TTFB dépasse 600 ms, le problème vient du serveur ou de PHP. Si le TTFB est bas, mais que la page se charge toujours lentement, les fichiers côté navigateur sont en cause : images, scripts, polices.

Cette distinction est cruciale. Un TTFB élevé indique un problème d'hébergement, un manque de cache, une ancienne version de PHP, une base de données saturée ou un wp-cron. Un TTFB bas avec un chargement lent indique des images, un thème lourd et des scripts externes. Les plugins peuvent nuire aux deux.

Mesure la page d'accueil et une sous-page, par exemple un article ou une fiche produit. Enregistre les résultats, tu y reviendras après chaque modification.

L'hébergement mutualisé est-il en cause ?

C'est la cause principale que le propriétaire du site ne soupçonne généralement pas, car « après tout, je paie pour l'hébergement ».

Sur un hébergement mutualisé classique, ton site est sur le même serveur que des centaines d'autres. Le processeur, la mémoire et le disque sont partagés. Quand un voisin a un pic de trafic, envoie une newsletter ou que quelqu'un attaque son site, ton WordPress ralentit aussi. À cela s'ajoutent les limites de processus PHP. Si plusieurs personnes accèdent simultanément à la boutique, les requêtes suivantes attendent dans la file d'attente.

Comment le reconnaître : Le TTFB fluctue. Le matin 300 ms, le soir 2 secondes, sans aucun changement sur le site. Dans le Panneau d'hébergement, tu vois des messages d'avertissement concernant le dépassement des limites de ressources (souvent appelés « resource limit reached » ou « 508 »).

Comment y remédier : L'optimisation du site n'aidera que partiellement. Si le serveur est surchargé par d'autres, il faut changer d'hébergement pour un hébergement où les ressources te sont dédiées. Chez Saplo, chaque Box est un conteneur séparé avec sa propre RAM et son propre disque. Box S a 1 Go de RAM (27 € par an), Box M 2 Go (65 € par an), Box L 6 Go (139 € par an), et personne d'extérieur ne consomme cette mémoire. Les détails des plans sont dans le cennik.

Trop de plugins ?

Le nombre de plugins n'est pas le problème en soi. Un site avec quarante plugins légers peut être plus rapide qu'un site avec dix plugins lourds. Le problème réside dans les plugins qui effectuent de nombreuses requêtes de base de données à chaque visite ou qui chargent leurs scripts sur chaque sous-page, même là où ils ne sont pas nécessaires.

Les coupables les plus fréquents sont les plugins de statistiques serveur complexes, les plugins de sécurité « tout-en-un » qui scannent les fichiers en temps réel, les plugins de publication connexe, les sliders et les formulaires chargés globalement.

Comment détecter le problème : installe le plugin gratuit Query Monitor. Dans la barre d'administration, il affichera le temps de génération de la page, le nombre de requêtes de base de données et quel plugin en envoie combien. Une page générée en plus de 0,5 seconde ou avec plusieurs centaines de requêtes a un problème.

Comment réparer :

1. Sauvegarde ton site.
2. Désactive les plugins que tu n'as pas utilisés depuis des mois. Supprime-les, ne te contente pas de les désactiver.
3. Pour les plugins lourds, recherche une alternative plus légère.
4. Utilise un plugin comme Asset CleanUp ou Perfmatters pour désactiver le chargement des scripts d'un plugin là où il est superflu (par exemple, les scripts de formulaire de contact uniquement sur la page Contact).
5. Mesure à nouveau.

Tes images sont-elles trop lourdes ?

Une photo prise avec un appareil photo ou un téléphone pèse 4 à 8 Mo et fait 4000 pixels de large. Elle s'affiche sur le site avec une largeur de 800 pixels, mais le navigateur doit quand même télécharger le fichier entier. Trois photos de ce type sur la page d'accueil et le LCP grimpe à plusieurs secondes, surtout sur mobile.

Comment le reconnaître : Dans PageSpeed Insights, tu verras les recommandations « Diffuser des images dans des formats nouvelle génération » et « Adapter la taille des images ». Dans le graphique en cascade, les barres les plus longues sont des fichiers JPG ou PNG.

Comment y remédier :

• Avant de les télécharger, réduis les photos à une largeur raisonnable, généralement 1600 à 2000 pixels pour les photos pleine largeur.
• Active la conversion au format WebP ou AVIF. Les plugins comme Converter for Media, EWWW Image Optimizer ou ShortPixel s'en chargent.
• Assure-toi que le chargement différé (lazy loading) fonctionne. WordPress l'ajoute automatiquement depuis la version 5.5, mais certains thèmes le désactivent.
• L'image visible tout en haut de la page (par exemple, une image d'en-tête) ne doit pas être chargée en différé. C'est elle qui détermine le LCP.

Le cache de ton site est-il activé ?

Sans cache, WordPress démarre PHP à chaque visite, se connecte à la base de données, assemble la page à partir de dizaines de requêtes, puis l'envoie au navigateur. Si dix visiteurs arrivent en même temps, le serveur effectue le même travail dix fois.

Il existe deux types de cache qu'il est bon de distinguer :

• Le cache de pages enregistre le HTML prêt à l'emploi et le fournit aux visiteurs suivants sans exécuter PHP. Il est fourni par les plugins WP Super Cache, W3 Total Cache, LiteSpeed Cache (uniquement sur les serveurs LiteSpeed) ou WP Rocket (payant).
• Le cache d'objets (object cache) stocke les résultats des requêtes de base de données en mémoire, le plus souvent dans Redis. Il est utile là où le cache de pages ne fonctionne pas : dans le panneau d'administration, dans le panier et sur le compte client dans une boutique WooCommerce.

Comment le reconnaître : Dans Query Monitor, vérifie si l'object cache est actif. Le TTFB sur une page que tu actualises une deuxième fois devrait diminuer de manière significative. Si ce n'est pas le cas, le cache de pages ne fonctionne pas.

Comment le réparer : Installe un plugin de cache de pages (pas deux à la fois, car ils peuvent entrer en conflit) et active l'object cache si ton hébergeur fournit Redis. Chez Saplo, l'installation de WordPress depuis le catalogue connecte automatiquement un Redis local dans le Box et active le plugin Redis Object Cache, avec un préfixe et une base de données séparés pour chaque site. Il n'est pas nécessaire de configurer quoi que ce soit manuellement.

Quelle version de PHP ton site utilise-t-il ?

WordPress est écrit en PHP, et chaque nouvelle version de PHP est plus rapide que la précédente. La différence entre PHP 7.4 et PHP 8.3, pour un même site, peut être nettement perceptible, surtout dans le panneau d'administration et pour les grandes boutiques en ligne. De plus, PHP 7.4 ne reçoit plus de mises à jour de sécurité.

Comment vérifier : Dans le panneau WordPress, va dans Outils, puis Santé du site, puis Informations, section Serveur. Tu y verras la version de PHP et la limite de mémoire.

Comment résoudre le problème :

1. Fais une sauvegarde.
2. Mets à jour WordPress, le thème et les plugins vers les dernières versions. Les anciens plugins peuvent être incompatibles avec les nouvelles versions de PHP.
3. Change la version de PHP dans le Panneau d'hébergement pour 8.2 ou 8.3.
4. Vérifie la page d'accueil, le formulaire, le panier et le Panneau. Si quelque chose ne fonctionne pas, reviens à la version précédente et cherche quel plugin est incompatible.

Chez Saplo, lors de l'installation de WordPress, tu choisis la version de PHP dans une liste allant de 7.4 à 8.5. Par défaut, nous installons la version 8.3, car elle est compatible avec pratiquement tous les plugins actuels.

La base de données n'est-elle pas engorgée ?

La base de données WordPress gonfle avec le temps. Elle accumule les révisions d'articles (chaque enregistrement crée une nouvelle copie), les articles dans la corbeille, les spams de commentaires, les données temporaires expirées (transients) et les options des plugins que tu as supprimés il y a longtemps. La table wp_options est particulièrement dangereuse. WordPress charge certaines de ses lignes à chaque visite de la page (options avec le drapeau autoload). Si elle atteint plusieurs mégaoctets, cela ralentit chaque visite.

Comment le savoir : Dans "Santé du site", WordPress, à partir de la version 6.6, avertit lui-même si les options d'autoload sont trop grandes. Dans Query Monitor, tu peux voir les requêtes lentes vers la base de données.

Comment y remédier :

• Limite le nombre de révisions en ajoutant la ligne define('WP_POST_REVISIONS', 5); au fichier wp-config.php.
• Nettoie la base de données avec le plugin WP-Optimize ou Advanced Database Cleaner : révisions, corbeille, spam, transients expirés.
• Supprime les options des plugins désinstallés. Advanced Database Cleaner montre à quel plugin appartient chaque option.
• Fais toujours une copie de la base de données avant de nettoyer.

Votre thème ou votre "page builder" est-il trop lourd ?

Les thèmes "polyvalents" vendus avec une centaine de mises en page prédéfinies chargent sur chaque page des scripts et des styles pour toutes leurs fonctions, même celles que vous n'utilisez pas. Les "page builders" (Elementor, Divi, WPBakery) ajoutent à cela du code HTML profondément imbriqué et leurs propres fichiers CSS et JS.

Cela ne signifie pas qu'il faut se débarrasser du builder, mais plutôt qu'il faut bien le configurer.

Comment le reconnaître : Dans PageSpeed Insights, les recommandations "Réduire le JavaScript inutilisé" et "Réduire le CSS inutilisé" pointent vers les fichiers du thème ou du builder. La page comporte plusieurs mégaoctets de scripts.

Comment y remédier :

• Dans Elementor, active les fonctions de performance dans les réglages (chargement optimisé des ressources, chargement du CSS dans un fichier plutôt qu'en ligne).
• Désactive les modules du thème que tu n'utilises pas (sliders, icônes, animations).
• Lors de la création d'un nouveau site, envisage un thème léger, par exemple GeneratePress, Kadence ou Astra, et un éditeur de blocs au lieu d'un builder lourd.

Les scripts externes bloquent-ils le chargement de ton site ?

Un chat en ligne, le pixel Facebook, Google Analytics, Tag Manager avec dix balises, une carte Google Maps, une vidéo YouTube intégrée, un widget d'avis, des polices de Google Fonts... Chacun représente une connexion distincte à un serveur différent, ajoutant des kilooctets de scripts sur lesquels tu n'as aucun contrôle.

Comment le détecter : dans le graphique en cascade, tu verras de nombreux fichiers provenant de domaines tiers. PageSpeed Insights affichera la recommandation « Réduire l'impact du code tiers ».

Comment y remédier :

• Passe en revue ton Tag Manager et supprime les balises des anciennes campagnes.
• Charge le chat uniquement après une interaction de l'utilisateur ou après quelques secondes.
• Intègre les vidéos YouTube sous forme de miniatures qui chargent le lecteur uniquement après un clic (WP YouTube Lyte le fait, par exemple).
• Télécharge les polices sur ton propre serveur au lieu de les charger depuis Google Fonts. Au passage, tu règles la question du RGPD.

Est-ce que wp-cron ne consomme pas trop de ressources ?

WordPress dispose d'un planificateur de tâches intégré, wp-cron. Il ne fonctionne pas comme un vrai cron système, mais se déclenche lorsque des visiteurs arrivent sur le site. Sur un site à fort trafic, il se déclenche trop souvent, et sur un site à faible trafic, les tâches (publication d'articles planifiés, sauvegardes, envoi d'e-mails depuis la boutique) s'exécutent avec un retard et peuvent ralentir une entrée aléatoire qui vient de les déclencher.

Comment le reconnaître : certaines pages se chargent visiblement plus lentement que les autres, sans raison apparente. Le plugin WP Crontrol affiche la liste des tâches et souvent des tâches d'anciens plugins qui restent actives pendant des années.

Comment résoudre le problème :

1. Dans WP Crontrol, supprime les tâches des plugins que tu n'utilises plus.
2. Désactive l'exécution de wp-cron par les visiteurs en ajoutant la ligne define('DISABLE_WP_CRON', true); à wp-config.php.
3. Configure un vrai cron système qui appellera wp cron event run --due-now ou l'adresse wp-cron.php toutes les 5 minutes. Sur Saplo, à partir de la Box M, tu as accès SSH avec des droits sudo complets, tu peux donc configurer cela en une seule ligne dans crontab.

Par où commencer la réparation ?

Si tu ne sais pas par où commencer, suis cet ordre. Les changements les moins chers et les plus efficaces sont en haut de la liste :

1. Mesure la page dans PageSpeed Insights et enregistre le TTFB et le LCP.
2. Fais une sauvegarde de tout le site et de la base de données.
3. Mets à jour WordPress, les plugins et PHP vers la version 8.2 ou 8.3.
4. Active le cache des pages et, si tu le peux, le cache d'objets dans Redis.
5. Optimise les images et convertis-les en WebP.
6. Examine les plugins dans Query Monitor et supprime ceux qui sont inutiles.
7. Nettoie la base de données et limite les révisions.
8. Allège les scripts externes et configure le thème.
9. Mesure à nouveau. Si le TTFB fluctue toujours en fonction de l'heure de la journée, le problème vient de l'hébergement et non du site.

Dans ce dernier cas, aucun plugin ne t'aidera. Tu dois déplacer le site là où les ressources du serveur sont uniquement les tiennes. Si tu envisages Saplo, nous transférerons WordPress pour toi : la migration est gratuite, avec la base de données et l'e-mail, sans interruption de service. Pour en savoir plus sur le fonctionnement de WordPress sur Saplo, consulte la page WordPress dans le catalogue d'applications et la page hébergement WordPress.

FAQ

Trop de plugins WordPress, ça existe ?

Il n'y a pas de limite précise. Ce qui compte, c'est ce que font les plugins, pas leur nombre. Un site avec trente plugins légers peut être rapide, tandis qu'un seul plugin mal codé peut le ralentir considérablement. Vérifie le temps de génération de la page et le nombre de requêtes dans Query Monitor, plutôt que de compter le nombre d'éléments dans la liste.

Un plugin de cache suffit-il à accélérer WordPress ?

Il offre souvent le plus grand bond en avant en une seule fois, mais il ne résout pas tout. Le cache des pages ne fonctionne pas dans le panneau d'administration, dans le panier d'achat ni pour les clients connectés. Dans ces cas, le cache d'objets dans Redis, une version PHP à jour et un nettoyage des plugins peuvent aider. Le cache ne corrigera pas non plus les images lourdes ou un serveur surchargé.

Pourquoi le panneau d'administration de WordPress est-il lent, alors que le site est rapide ?

Parce que les visiteurs reçoivent des pages déjà en cache, tandis que le panneau d'administration est toujours généré en temps réel par PHP et la base de données. Un panneau lent est généralement le signe de plugins lourds, d'une table wp_options engorgée, d'une ancienne version de PHP ou de l'absence de cache objet. Commence par Query Monitor ouvert dans le panneau.

Quel est le score PageSpeed Insights idéal ?

Un score de 90 ou plus est excellent. Entre 50 et 89, des améliorations sont nécessaires. Plus importants que le chiffre lui-même sont les indicateurs Core Web Vitals : LCP en dessous de 2,5 secondes, INP en dessous de 200 ms et CLS en dessous de 0,1. Ce sont eux qui influencent le classement de la page dans Google.

Un changement d'hébergeur va-t-il accélérer WordPress ?

Oui, si la cause est le serveur, c'est-à-dire un TTFB élevé et instable, ainsi que des messages concernant les limites de ressources. Non, si le site contient des images lourdes et des dizaines de scripts inutiles, car les mêmes fichiers devront être téléchargés depuis le nouveau serveur. Mesure d'abord, puis décide.