Pourquoi un site WordPress devient lent : causes mesurées sur mon site
Par Vasile Boulay, fondateur de Stea Web · publié le
Le 21 septembre 2026, j’ai audité stea-web.com, mon propre site, construit avec WordPress et Elementor. J’y ai relevé plusieurs causes de lenteur. J’en détaille huit : cinq corrigées le soir même, trois encore ouvertes. Pour chacune, je donne la mesure avant et après, ou son état. Méthode : Lighthouse en mobile, jusqu’à trois passages par page, temps de réponse mesuré cinq fois, en-têtes HTTP, tâches planifiées et journaux du serveur du 14 au 19 septembre 2026.
Comment j’ai mesuré
J’ai croisé plusieurs mesures, parce qu’un score Lighthouse seul varie trop : sur la page d’accueil, en mobile, trois passages consécutifs ont donné 64, 91 et 98 sur 100. Je donne donc d’abord les temps de réponse et les poids, puis les scores en médiane, avec le nombre de passages.
Ces trois passages datent du 21 septembre au soir, après les corrections. Le passage à 64 reste inexpliqué. Lighthouse 12 simule une connexion mobile lente (latence de 150 ms, débit de 1,6 Mbit/s) et un processeur ralenti quatre fois. Or le mobile domine. Selon la Search Console, 82 % des affichages du site dans Google venaient du mobile : 13 467 impressions sur 16 377, sur 90 jours arrêtés au 19 septembre.
1. Le cache se vidait toutes les 5 minutes, Cloudflare compris
L’extension WP Fastest Cache effaçait tout son cache toutes les 5 minutes, et faisait vider celui de Cloudflare à chaque fois. Avec les deux causes suivantes, ce réglage explique que, du 14 au 19 septembre, seules 19 % des pages demandées par des navigateurs soient sorties du cache. Le vidage est corrigé ; le nouveau taux reste à mesurer.
Chez Cloudflare, trois fichiers statiques gardés depuis 226 à 234 secondes étaient tous à recharger une minute plus tard, juste après le passage de la tâche. Dans les journaux du serveur, 183 pages sur 947 demandées par des navigateurs sortaient du cache, contre 59 sur 578 lors de passages de robots. Ce tri par user-agent, la signature que se donne chaque client, reste approximatif : un robot peut se présenter comme un navigateur.
Le vidage a désormais lieu toutes les 6 heures, sans purge de Cloudflare. Je ne l’ai pas espacé davantage : les pages en cache contiennent des jetons de sécurité WordPress (nonces), valables de 12 à 24 heures. Une page gardée plus longtemps peut faire échouer un formulaire. Le soir même, un script restait en cache chez Cloudflare depuis 1 426 secondes, alors que la purge toutes les 5 minutes l’empêchait auparavant de dépasser 300 secondes.
2. La page d’accueil était exclue du cache
La page d’accueil, celle qui reçoit le plus de clics depuis Google, était recalculée par WordPress à chaque demande, parce qu’une règle l’excluait du cache. Remise en cache, elle répond en 119 ms au lieu de 463 ms (médianes de cinq mesures depuis mon poste, à travers Cloudflare).
Sur 90 jours arrêtés au 19 septembre, l’accueil a reçu 43 des 76 clics venus de Google. Du 14 au 19 septembre, il représentait 487 des 1 525 demandes de pages HTML, passages de robots compris. Je n’y ai trouvé aucun contenu personnalisé qui justifie l’exclusion. Sur le serveur, son calcul prenait de 249 à 348 ms, contre environ 6 ms une fois en cache.
Lighthouse mesure bien la baisse du temps de réponse : de 446 à 130 ms (médianes de trois passages en mobile). Mais son score en tient peu compte. Dans son découpage du LCP (le moment où le plus grand élément s’affiche), la part du temps de réponse est simulée. Elle reste entre 632 et 738 ms, avant comme après.
3. Le préchargement du cache ne tournait jamais
Le préchargement, qui remet les pages en cache avant l’arrivée des visiteurs, s’arrêtait à chaque passage : sa liste de plans du site (sitemaps) n’avait jamais été remplie. C’est corrigé : le 21 septembre au soir, 31 pages étaient en cache.
WP Fastest Cache ne remplit cette liste qu’à l’enregistrement de son écran de réglages. Faute de liste, le préchargement s’arrêtait toutes les 5 minutes sur le message « No sitemap detected! ». Cet arrêt coupait au passage le processus chargé des autres tâches planifiées du site. Sans préchargement, une page n’entrait en cache qu’à la première demande d’un visiteur ou d’un robot, qui attendait alors son calcul complet.
4. Un en-tête de sécurité de plus de 7 Ko partait avec chaque fichier
Une politique de sécurité (en-tête Content-Security-Policy) de 7 471 caractères accompagnait chaque réponse du serveur, images, polices et scripts compris. Depuis qu’elle est limitée aux pages HTML, les en-têtes d’un petit script de 881 octets sont passés de 9 068 à 1 107 octets.
Ce bloc était resté dans le fichier .htaccess après la désactivation d’une extension de sécurité. Selon Lighthouse, qui relève les tailles transférées dans Chrome, chaque image ou police de l’accueil mobile portait en médiane 6,4 Ko d’en-têtes, contre 1,1 Ko après correction. Ces mesures encadrent aussi la correction de la police (cause 5). Entre les deux, le poids transféré de l’accueil mobile passe de 1 697 à 1 279 Ko (médianes de trois passages). Celui de Tarifs passe de 595 Ko (un passage) à 400 Ko (médiane de deux).
5. La même police était téléchargée trois fois
La police Rubik existait en quatre fichiers identiques, un par graisse, et l’accueil en téléchargeait trois : environ 83 Ko de trop. Les quatre déclarations pointent désormais vers un seul fichier.
C’est une police variable : un seul fichier couvre toutes les graisses utilisées, et les quatre fichiers avaient la même empreinte numérique. Mais chaque règle @font-face citait un nom de fichier différent, et le navigateur ne pouvait pas savoir qu’ils étaient identiques. L’affichage ne change pas.
6. Une extension qui vérifie les liens à chaque consultation (non corrigé)
L’extension Broken Link Notifier fait vérifier par le serveur tous les liens d’une page, chaque fois qu’un navigateur l’ouvre. Sur l’accueil, cet appel dure de 7,9 à 8,4 secondes. Au 21 septembre au soir, je ne l’avais pas corrigé, car la correction change l’usage de l’outil.
Le serveur interroge chaque lien et peut attendre jusqu’à 5 secondes la réponse de chacun. Selon Lighthouse, l’appel dure de 1,4 à 2,6 s sur trois autres pages. L’affichage n’attend pas, mais un processus PHP reste occupé tout ce temps.
Deux solutions existent : remplacer la vérification pendant les visites par une analyse programmée, ou retirer l’extension. C’est une décision sur la surveillance des liens, pas un simple réglage de vitesse.
7. Un anti-spam chargé avant d’être utile (non corrigé)
Sur la page Contact, le reCAPTCHA de Google se charge dès l’ouverture : environ 400 Ko de fichiers tiers, avant toute utilisation du formulaire. Ce n’est pas encore corrigé.
Avant les corrections, la page obtenait 58 sur 100 en mobile (deux passages), et 57 avec un bridage réellement appliqué au navigateur plutôt que simulé. Après les cinq corrections, elle monte à 76, sur un seul passage. Son LCP atteint encore 6,27 s, car son image de fond est découverte tard.
La correction prévue consiste à charger reCAPTCHA à la première interaction avec le formulaire. Elle touche à la protection contre le spam : je dois d’abord vérifier qu’un message légitime passe toujours et que la protection tient.
8. Du CSS qui bloque l’affichage sur mobile (non corrigé)
Sur mobile, le plus grand élément de l’accueil est un paragraphe de texte, qui attend le CSS et jQuery pour s’afficher. Lors de l’audit, ce retard atteignait 1,8 à 2,7 s (trois passages). Ce n’est pas corrigé, car la correction peut modifier l’apparence des pages.
L’essentiel du CSS de l’accueil forme un seul fichier de 349 Ko une fois décompressé, inutilisé à 89 % sur cette page. Deux scripts jQuery se chargent aussi de façon bloquante, dans la section head du code. Les réglages de performance d’Elementor 4.2.4 sont pourtant tous actifs sur le site. Après les autres corrections, le LCP de laboratoire de l’accueil est encore de 2,78 s en médiane. Or Google fixe à 2,5 s le seuil d’un bon LCP, évalué sur de vrais visiteurs. Cinq des sept pages mesurées en laboratoire dépassent ce seuil.
La correction consiste à placer dans la page le CSS du premier écran, puis à charger le reste ensuite. Le risque : afficher un instant la page sans mise en forme, ce qui impose de vérifier chaque gabarit à l’œil. Quant à jQuery, il ne peut pas descendre en bas de page, car un script en ligne, placé lui aussi dans la section head, en dépend.
Les scores Lighthouse avant et après
Les scores mobiles montent sur les six pages mesurées avant et après, mais sur de petits échantillons. Les temps de réponse et les poids donnés plus haut restent les mesures les plus fiables. Toutes ces mesures datent du 21 septembre 2026, avant puis après les corrections.
| Score mobile Lighthouse | Avant : médiane (passages) | Après : médiane (passages) |
|---|---|---|
| Accueil | 87 (3 : 85, 87, 95) | 91 (3 : 64, 91, 98) |
| Tarifs | 83 (1) | 98 (2) |
| Création sur mesure | 74 (1) | 84 (2) |
| Vidéo | 75 (1) | 87 (1) |
| Étude de cas e-dugas | 95 (1) | 99 (2) |
| Contact | 58 (2) | 76 (1) |
Trois autres points restaient ouverts ce soir-là : des images que Cloudflare ne garde jamais en cache, une image préchargée sur toutes les pages alors qu’elle ne sert que sur l’accueil et Tarifs, et deux extensions chargées partout sans y servir. Le lendemain, 22 septembre, le préchargement a été limité à ces deux pages, et Contact Form 7, qui ne servait à aucun formulaire, a été désactivé ; ces deux changements restent à remesurer. Enfin, Google écrit que de bons Core Web Vitals ne garantissent pas la première place dans ses résultats : la pertinence prime.
Ce qui n’était pas en cause : le serveur
Le serveur n’était pas en cause : il avait beaucoup de marge. Avant de payer un serveur plus puissant, mieux vaut mesurer.
Pendant l’audit du 21 septembre, la charge était de 0,18 pour 4 processeurs virtuels, et 6,4 Go de mémoire vive restaient disponibles. Le cache d’objets Redis trouvait 91,5 % des données demandées, et la base MariaDB servait 99,99 % de ses lectures depuis la mémoire. Un serveur plus puissant n’aurait supprimé aucune des causes décrites ici.
Ce qu’il faut vérifier sur votre propre site
Commencez par le cache et les en-têtes. Chez moi, c’étaient de simples réglages, sans effet sur l’apparence du site, et le temps de réponse de l’accueil a été divisé par près de quatre.
- Les tâches planifiées de l’extension de cache : un vidage complet fréquent, CDN compris, annule l’essentiel de l’effet du cache.
- Les exclusions : la page d’accueil ne doit pas en faire partie sans raison.
- Le préchargement : vérifiez qu’il avance.
- Les en-têtes d’une image, dans l’onglet Réseau du navigateur : 1,1 Ko chez moi après correction, 6,4 Ko avant.
- Les polices et les scripts en double ou inutiles.
- Les appels longs à admin-ajax.php après le chargement de la page.
- Les scripts tiers chargés d’emblée.
Je décris ma démarche sur la page consacrée à l’optimisation de la vitesse WordPress.
Sur mon site, la lenteur ne venait pas du serveur. Elle venait de réglages qui annulaient le cache et d’extensions qui travaillaient au mauvais moment, ou pour rien. Les trois causes restantes demandent une décision ou des tests ; je mettrai l’article à jour après une nouvelle mesure. Si votre site montre ces symptômes, je peux faire le même diagnostic sur le vôtre. Je suis installé à Fresnes, près de Blois, et je travaille à distance partout en France.