WordPress est l'un des outils les plus utilisés au monde pour créer des sites web. Et pour cause : il est gratuit, accessible, avec une communauté énorme et un écosystème de plugins qui permet théoriquement de faire à peu près n'importe quoi sans écrire une seule ligne de code. C'est exactement ce qui en fait un outil puissant pour tout le monde, du développeur aguerri au gérant de PME qui gère son site entre deux réunions.
Mais c'est aussi exactement ce qui, avec le temps, peut transformer un site WordPress en quelque chose de péniblement lent.
Je travaille régulièrement sur des sites WordPress qui ont été construits il y a quelques années, souvent par des prestataires différents, et dans la grande majorité des cas le problème de performance suit toujours le même schéma. Pas un seul coupable, mais une accumulation de petites décisions qui, mises bout à bout, finissent par peser lourd. Dans cet article je vais vous expliquer comment identifier ces problèmes, dans quel ordre les traiter, et ce que je fais concrètement quand j'interviens sur ce type de site.
Avant de toucher quoi que ce soit : comprendre d'où vient la lenteur
La première erreur quand on veut améliorer les performances d'un site, c'est de se jeter sur des solutions sans avoir diagnostiqué correctement le problème. Installer un plugin de cache sur un site dont le vrai problème est une base de données mal entretenue, ça peut donner l'impression que ça va mieux, mais ça ne règle rien en profondeur.
Donc avant toute intervention, je commence toujours par observer. Et pas uniquement avec des outils : j'essaie d'abord de noter des patterns concrets.
Quelques questions à se poser :
- Est-ce que le site est lent sur toutes les pages ou seulement certaines ?
- Est-ce que c'est lent dans l'administration WordPress mais pas sur le site public, ou l'inverse ?
- Est-ce que ça arrive à certains horaires en particulier ?
- Est-ce que les utilisateurs connectés voient le problème, ou tout le monde ?
Ces questions peuvent paraître basiques, mais elles orientent vers des pistes très différentes. Un site lent uniquement dans l'admin pointe vers un problème de plugins d'administration ou de requêtes lourdes côté back-office. Un site lent uniquement aux heures de pointe suggère plutôt un problème de ressources serveur. Une page précise plus lente que les autres peut cacher un plugin ou un widget particulier.
Les outils de diagnostic
Une fois les observations faites, j'utilise deux outils principaux : Lighthouse (intégré dans Chrome DevTools, accessible via la touche F12) et GTmetrix. Ces outils vont analyser votre site et vous remonter une série de métriques.
La métrique la plus importante à regarder en premier est le TTFB (Time To First Byte). C'est le temps que met le serveur à commencer à envoyer une réponse après qu'un utilisateur a demandé une page. Un TTFB élevé (au-delà de 600ms, voire 1 seconde) indique presque toujours un problème côté serveur : requêtes en base de données trop lourdes, plugins qui font des appels coûteux à chaque chargement, ou simplement un serveur sous-dimensionné.
Si par contre votre TTFB est correct mais que la page reste lente à afficher, le problème est plutôt côté front : trop de fichiers CSS ou JavaScript, images non optimisées, DOM trop chargé.
Cette distinction serveur / front est vraiment fondamentale parce que les solutions ne sont pas du tout les mêmes. Beaucoup de personnes passent des heures à optimiser leurs images alors que leur vrai problème est une table WordPress qui grossit depuis des années sans jamais être nettoyée.
Les plugins : le premier endroit où regarder
Si je devais choisir une seule cause pour résumer 80% des problèmes de performance sur les sites WordPress que je vois, ce serait les plugins. Pas les plugins en eux-mêmes, mais la manière dont ils s'accumulent.
Le problème vient du fonctionnement même de l'écosystème WordPress. Quand vous avez besoin d'une nouvelle fonctionnalité, vous allez sur le dépôt WordPress.org ou sur un marketplace, vous cherchez ce qu'il vous faut, vous en testez plusieurs, et vous installez celui qui semble le mieux. Puis six mois plus tard vous recommencez pour autre chose. Et ainsi de suite.
Résultat : des sites avec 40, 50, parfois 70 plugins actifs. Et autant de plugins qui chargent leurs fichiers CSS, leur JavaScript, leurs requêtes en base de données à chaque affichage de page, qu'ils soient réellement utiles sur cette page ou non.
Ce que je fais en premier sur chaque site :
Désactiver et supprimer les plugins inutilisés. Ça paraît évident mais dans la réalité, beaucoup d'entreprises laissent tourner des plugins installés "pour tester" il y a deux ans et jamais supprimés. Chaque plugin actif consomme de la mémoire et potentiellement du temps de traitement. Et en prime, un plugin non maintenu est une potentielle faille de sécurité.
Identifier les plugins "usine à gaz". Certains plugins font dix choses alors que vous n'en avez besoin que d'une. Un plugin de formulaires de contact avec gestion des newsletters, des notifications push, un CRM intégré et un système de pop-ups, alors que vous voulez juste un formulaire simple — c'est typiquement ce genre de situation. Dans ce cas je cherche une alternative plus légère, ou je développe directement la fonctionnalité sur mesure.
Analyser l'impact de chaque plugin restant. Il existe des outils comme Query Monitor (un plugin lui-même, l'ironie) qui permettent de voir précisément quelles requêtes SQL sont lancées par chaque plugin à chaque chargement de page. Ça permet d'identifier très rapidement le ou les plugins responsables de ralentissements.
Je suis développeur et honnêtement, je n'aime pas utiliser des plugins tout faits quand une solution sur mesure est possible. Pas par dogmatisme, mais parce qu'un plugin conçu pour des milliers de sites différents doit forcément être générique. Il embarque des fonctionnalités que vous n'utiliserez jamais, gère des cas particuliers qui ne vous concernent pas, et s'adapte à des configurations que vous n'avez pas. Quand je peux faire un petit module sur mesure qui fait exactement ce qu'il faut et rien d'autre, le gain en performance est souvent significatif.
Les thèmes : même problème, même logique
Le thème WordPress c'est la peau visuelle de votre site, mais aussi beaucoup plus que ça. C'est lui qui pilote la structure des pages, charge les fichiers de style, les scripts, les polices, et potentiellement des centaines de fonctionnalités que vous n'utilisez jamais.
Les thèmes commerciaux populaires — je pense à des thèmes comme Avada, Divi, ou les thèmes livrés avec des page builders — sont conçus pour être polyvalents. Ils doivent pouvoir créer un site vitrine, un e-commerce, un portfolio, un blog... Du coup ils embarquent tout ce qu'il faut pour chaque cas d'usage. Même si votre site est un simple site de présentation avec cinq pages, votre thème charge potentiellement le CSS d'une boutique en ligne que vous n'avez pas.
Ma recommandation générale :
Si vous utilisez un constructeur de page comme Elementor ou Divi pour créer votre design, utilisez un thème dit "starter" ou "headless" en dessous — des thèmes ultra-légers conçus pour ne pas interférer. Des thèmes comme Hello Elementor, Blocksy ou GeneratePress dans leurs configurations minimales sont de bons exemples.
Si le client me donne carte blanche, je préfère reconstruire le thème entièrement à la main. La raison est simple : chaque page de votre site charge le header et le footer. Si ce header est construit avec Elementor et embarque trois bibliothèques JavaScript, ce coût est payé à chaque visite, sur chaque page. Refaire ce même header en HTML/CSS brut me prend quelques heures et le résultat est souvent dix fois plus léger. Certes, c'est plus difficile à modifier sans connaissances techniques ensuite — c'est un compromis à assumer — mais pour un header qui ne change quasiment jamais, ça a beaucoup de sens.
Elementor : un cas particulier qui mérite d'être mentionné
Puisqu'on parle de thèmes et de constructeurs de page, je veux m'arrêter une seconde sur Elementor parce que c'est de loin le plus utilisé et que son impact sur les performances est souvent sous-estimé.
Elementor est un excellent outil. Son interface est intuitive, on peut créer des designs complexes sans coder, et pour quelqu'un qui doit maintenir son site lui-même sans développeur à portée de main, c'est très précieux. Mais cette facilité a un coût.
Pour que vous puissiez déplacer des éléments visuellement, que les animations fonctionnent, que les colonnes s'adaptent, Elementor génère du HTML avec beaucoup de div imbriquées, charge plusieurs fichiers CSS, plusieurs fichiers JavaScript, et des bibliothèques entières pour gérer des effets dont vous n'utiliserez peut-être que 5%. C'est inhérent à la nature de l'outil : plus on abstrait la complexité technique, plus on ajoute de couches.
Je ne dis pas de ne pas utiliser Elementor — dans beaucoup de contextes c'est le bon choix. Mais si vous constatez que votre site est lent et que vous avez Elementor installé, c'est une piste sérieuse à explorer, notamment en regardant quels widgets vous utilisez vraiment et si certains effets visuels méritent vraiment le coût qu'ils représentent en termes de chargement.
La base de données : la cause la plus négligée
C'est souvent là que le vrai problème se cache, et c'est souvent la dernière chose que les gens regardent.
WordPress stocke absolument tout en base de données : vos articles, vos pages, vos médias, les paramètres de votre site, les paramètres de chaque plugin, les révisions de chaque article que vous avez modifié, les commentaires, les sessions utilisateurs, les logs de certains plugins... Avec le temps, tout ça s'accumule.
Les principaux problèmes :
Les tables orphelines laissées par des plugins désinstallés. Quand vous supprimez un plugin, WordPress ne supprime généralement pas les tables que ce plugin avait créées en base de données. Après quelques années et plusieurs dizaines de plugins testés puis abandonnés, il peut rester des dizaines de tables qui ne servent plus à rien.
Les révisions d'articles qui s'accumulent. Par défaut WordPress sauvegarde une révision à chaque fois que vous enregistrez un article. Si vous modifiez souvent vos articles, vous pouvez vous retrouver avec des centaines de révisions pour un même contenu.
Les drafts auto-sauvegardés et les commentaires spam non modérés.
La table
wp_options— c'est celle qui m'intéresse le plus. Cette table stocke tous les paramètres du site : l'adresse, l'email admin, les paramètres de chaque plugin, les configurations de thème... Le problème c'est que WordPress charge une grande partie de cette table à chaque affichage de page. Et les développeurs de plugins, très logiquement de leur point de vue, ne suppriment pas leurs paramètres quand on désinstalle leur plugin — pour que vous n'ayez pas à tout reconfigurer si vous le réinstallez un jour. Résultat : des années de paramètres de plugins qui n'existent plus continuent de se charger à chaque visite.
Comment je procède pour nettoyer :
Pour le nettoyage de premier niveau, des plugins comme WP-Optimize ou Advanced Database Cleaner font un très bon travail gratuitement sur les fonctionnalités de base : suppression des révisions, drafts, commentaires spam, transients expirés. C'est une bonne première étape si vous n'êtes pas à l'aise avec une intervention directe.
Quand je veux aller plus loin, j'interviens directement en base de données — via phpMyAdmin ou Adminer. Et la première règle avant de toucher quoi que ce soit : faire une sauvegarde complète. Sans exception. La base de données c'est le cœur de votre site, il y a tout dedans, et on peut très facilement tout casser en supprimant la mauvaise table.
Une fois dans la base, je cherche et supprime les tables orphelines, puis je travaille sur wp_options : identifier les lignes dont le nom de l'option correspond à un plugin qui n'est plus installé, et les supprimer proprement, une par une. C'est laborieux mais l'effet sur les performances peut être spectaculaire sur un site vieux de plusieurs années.
Le serveur et le cache : quand le nettoyage ne suffit plus
Une fois les plugins rationalisés, le thème allégé et la base de données nettoyée, on mesure à nouveau les performances. Dans beaucoup de cas, ça suffit déjà à constater une amélioration significative. Mais parfois le problème vient aussi de l'infrastructure en elle-même.
La configuration serveur idéale pour WordPress :
- Un SSD pour le stockage. La lecture/écriture sur un disque mécanique est significativement plus lente que sur un SSD, et ça se ressent directement sur les temps de réponse de la base de données.
- Les fichiers WordPress et la base de données sur le même serveur. C'est un point souvent sous-estimé. Si votre site est hébergé chez OVH et votre base de données chez un autre prestataire (certaines offres d'hébergement mutualisé fonctionnent ainsi), chaque requête SQL doit transiter entre deux serveurs. Sur une page WordPress qui peut facilement générer 50 à 100 requêtes, cette latence s'additionne rapidement.
- Suffisamment de RAM allouée à PHP. Une valeur de
memory_limittrop basse (128Mo est souvent insuffisant sur des sites complexes) force PHP à paginer en disque, ce qui est beaucoup plus lent.
Les différents niveaux de cache :
Le cache consiste à mémoriser le résultat d'un traitement coûteux pour ne pas avoir à le recalculer à chaque fois. Il y a plusieurs niveaux possibles.
Le cache de pages : le plus impactant. L'idée est de sauvegarder la page HTML finale telle qu'elle sera affichée au visiteur, pour la servir directement sans appeler PHP ni la base de données. Des plugins comme WP Super Cache ou W3 Total Cache font ça. La configuration nécessite quelques réglages côté serveur web (Nginx ou Apache) mais une fois en place, les pages statiques sont servies extrêmement rapidement.
Le cache de base de données avec Redis. Redis est un système de cache en mémoire qui peut mémoriser les résultats des requêtes SQL fréquentes. Très efficace quand la base de données est la goulot d'étranglement, notamment si elle est sur un serveur distant ou si vos requêtes sont complexes.
Le cache d'objets via des plugins WordPress qui utilisent Redis ou Memcached pour cacher les résultats PHP intermédiaires.
Pour quelqu'un sans connaissances techniques, un plugin de cache correctement configuré reste une très bonne option. C'est imparfait par rapport à une configuration serveur optimisée à la main, mais ça donne des résultats.
Les assets : images, CSS, JavaScript et polices
Une fois les problèmes serveur traités, on s'attaque au front-end. Ce sont les fichiers que votre serveur envoie au navigateur de vos visiteurs, et leur optimisation peut faire autant de différence que tout le reste.
Les images
C'est la cause la plus fréquente de lenteur côté front, et c'est aussi la plus facile à corriger.
Les actions à mener :
Compresser les images avant de les uploader. Il existe deux types de compression : avec perte (lossy) et sans perte (lossless). Pour la plupart des images sur un site web, une compression avec perte légère est invisible à l'œil mais peut réduire le poids d'une image de 50 à 80%. Des outils gratuits comme Squoosh (en ligne) ou ImageOptim (Mac) permettent de le faire manuellement. Des plugins WordPress comme Imagify ou ShortPixel peuvent l'automatiser.
Utiliser les bons formats. Le format WebP est aujourd'hui supporté par tous les navigateurs modernes et offre une compression bien meilleure que JPEG ou PNG pour une qualité équivalente. Si vos images sont encore en PNG ou JPEG, passer en WebP est souvent le gain le plus rapide à obtenir.
Dimensionner les images à la bonne taille. WordPress génère automatiquement des miniatures à différentes tailles, mais si vous uploadez une image de 4000px de large pour l'afficher dans une colonne de 400px, les versions réduites ne seront peut-être pas exactement à la bonne taille. Rédimensionner l'image en amont, avant l'upload, reste la solution la plus propre.
Activer le lazy loading. C'est une balise HTML (
loading="lazy") qui indique au navigateur de ne pas charger les images qui ne sont pas encore visibles à l'écran. WordPress le gère nativement depuis la version 5.5.
CSS et JavaScript
C'est plus technique, mais potentiellement très impactant.
Chaque fichier CSS et JavaScript que votre site charge représente une requête réseau supplémentaire et, dans certains cas, bloque l'affichage de la page pendant son chargement. Un site qui charge 30 fichiers CSS et 25 fichiers JavaScript a un problème structurel.
Ce qu'il est possible de faire :
Minifier les fichiers CSS et JS (supprimer les espaces, commentaires et retours à la ligne inutiles). Gain modeste mais sans effort avec des plugins.
Combiner plusieurs fichiers en un seul pour réduire le nombre de requêtes. À utiliser avec précaution selon la configuration.
Charger certains fichiers de manière différée. En JavaScript, les attributs
deferetasyncpermettent de ne pas bloquer le rendu de la page pendant le chargement d'un script. C'est une des optimisations les plus efficaces que je mets en place sur les sites que j'optimise.Ne charger certains fichiers que sur les pages qui en ont besoin. Si un plugin de galerie d'images charge son CSS et son JS sur toutes les pages du site alors qu'il n'est utilisé que sur une seule, c'est du gâchis pur. Certains plugins le gèrent nativement, pour d'autres il faut intervenir manuellement.
Les polices (fonts)
Un point souvent négligé. Les polices personnalisées (Google Fonts, Adobe Fonts, ou des polices auto-hébergées) peuvent peser plusieurs centaines de kilooctets, et elles sont utilisées sur chaque page de votre site — tout votre texte en dépend.
Mes recommandations :
Limiter le nombre de polices. Deux polices différentes sur un site c'est déjà beaucoup. Trois c'est le maximum raisonnable. Chaque famille de police et chaque variante (gras, italique, etc.) représente un fichier supplémentaire.
Utiliser le format WOFF2. C'est le format le mieux compressé et le plus universellement supporté aujourd'hui pour les polices web.
Auto-héberger vos polices plutôt que de les charger depuis Google Fonts. Contre-intuitif ? Pas vraiment : charger une police depuis un serveur externe ajoute une résolution DNS et une connexion réseau supplémentaire. En hébergeant la police sur votre propre serveur, vous éliminez cette latence.
Les métriques Lighthouse à surveiller
Pour finir, voici une synthèse des métriques que vous allez retrouver dans Lighthouse et ce qu'elles indiquent concrètement :
FCP — First Contentful Paint
C'est le temps avant que le navigateur affiche le premier élément visible sur la page (un texte, une image, quoi que ce soit). Un FCP élevé pointe généralement vers un problème serveur : TTFB élevé, PHP lent, requêtes BDD coûteuses.
LCP — Largest Contentful Paint
C'est le temps qu'a mis le plus grand élément visible de la page à se charger. Dans la plupart des cas c'est une image hero ou un bandeau en haut de page. Un LCP mauvais combiné à un FCP correct signifie que le serveur répond vite mais qu'un gros asset met du temps à arriver.
TBT — Total Blocking Time
C'est la durée totale pendant laquelle le navigateur a été "bloqué" par des scripts et n'a pas pu réagir aux interactions de l'utilisateur. Un TBT élevé signifie trop de JavaScript lourd ou mal optimisé.
CLS — Cumulative Layout Shift
C'est une mesure des décalages visuels qui se produisent après le chargement initial. Si des éléments de la page se déplacent parce qu'une image a été chargée plus tard et a poussé le contenu vers le bas, ou parce qu'une police a changé la taille d'un bloc de texte, le CLS augmente. C'est mauvais pour l'expérience utilisateur et pour le référencement.
Tableau des 4 Métriques Clés
| Métrique | Description Simple | 🟢 Bon | 🟠 À améliorer | 🔴 Médiocre |
|---|---|---|---|---|
| FCP (First Contentful Paint) | Temps pour que le tout premier élément (texte, image) s'affiche. | < 1,8s | 1,8s - 3,0s | > 3,0s |
| LCP (Largest Contentful Paint) | Temps pour que l'élément le plus grand (image principale, titre) soit visible. | < 2,5s | 2,5s - 4,0s | > 4,0s |
| TBT (Total Blocking Time) | Temps total où la page est bloquée et ne peut pas répondre aux clics. | < 200ms | 200ms - 600ms | > 600ms |
| CLS (Cumulative Layout Shift) | Mesure la stabilité visuelle (si les éléments bougent tout seuls au chargement). | < 0,1 | 0,1 - 0,25 | > 0,25 |
Quoi retenir concrètement
Les performances WordPress se dégradent rarement d'un coup. C'est une accumulation progressive : un plugin de plus par-ci, une image jamais compressée par-là, une base de données qui grossit sans jamais être nettoyée. Et un jour on réalise que le site qui s'affichait en 1,5 secondes en prend maintenant 6 ou 7.
La bonne nouvelle c'est que dans la plupart des cas, les causes sont identifiables et les solutions existent. Le diagnostic est l'étape la plus importante : comprendre d'où vient le problème avant de chercher une solution. Un TTFB de 3 secondes et un CLS de 0,8 n'ont pas les mêmes causes et ne se règlent pas de la même manière.
Dans ma façon de travailler, j'aborde toujours ces interventions dans le même ordre :
- Audit et diagnostic (Lighthouse, GTmetrix, Query Monitor)
- Nettoyage des plugins et des thèmes inutiles
- Nettoyage de la base de données
- Optimisation des assets (images, CSS, JS, fonts)
- Mise en cache et configuration serveur
C'est rarement une seule intervention qui fait tout, mais c'est presque toujours une combinaison de ces actions qui permet de passer d'un site qui peine à s'afficher à quelque chose de vraiment réactif. Si vous êtes dans cette situation et que vous ne savez pas par où commencer, c'est exactement le type de mission sur lequel j'interviens.