Sur cette page · 9 sections
Vous avez investi dans un site WordPress. Vous avez choisi un “bon” hébergement, installé un thème premium, ajouté les plugins recommandés par votre agence. Et pourtant, quand vous testez sur PageSpeed Insights, le score est entre 30 et 55. Le site met 3 à 5 secondes à charger. Sur mobile, c’est pire.
Ce n’est pas votre faute. C’est l’architecture.
Les 5 raisons techniques pour lesquelles WordPress est lent par défaut, les chiffres réels de performance en 2026, et les options qui s’offrent à vous — de l’optimisation à la migration.
Les chiffres que personne ne vous montre
Commençons par les données. Pas les promesses marketing des hébergeurs WordPress, les mesures réelles :
| Métrique | WordPress (moyenne) | Seuil recommandé |
|---|---|---|
| Temps de chargement (desktop) | 3,4 secondes | < 2,5 secondes |
| Temps de chargement (mobile) | 8,6 secondes | < 2,5 secondes |
| Poids moyen d’une page | 2,3 MB | < 1 MB |
| Taux de passage CWV | 33 à 40% | 100% |
| Score Lighthouse moyen | 40 à 55 | > 90 |
8,6 secondes sur mobile. Plus de 60% des sites WordPress échouent aux Core Web Vitals. Ce ne sont pas des sites mal faits — c’est la moyenne du parc WordPress.
La page publique WordPress moyenne exécute 55 requêtes SQL et 483 millisecondes de PHP avant d’envoyer le moindre octet au navigateur. Un site statique envoie le HTML immédiatement.
Données DebugHawk, 5,7 millions de pages vues analysées (2025).Raison 1 : PHP reconstruit chaque page à chaque visite
Quand quelqu’un visite votre site WordPress, voici ce qui se passe :
- Le navigateur envoie une requête au serveur
- Le serveur démarre PHP
- PHP charge WordPress (core, thème, plugins)
- WordPress interroge la base de données MySQL (55 requêtes en moyenne)
- PHP assemble la page HTML
- Le serveur envoie le HTML au navigateur
Ce processus prend en médiane 483 millisecondes — avant même que le navigateur ne commence à afficher quoi que ce soit. Et il se répète à chaque visite, pour chaque page.
Un site statique (Astro, Hugo, Eleventy) fait l’étape 5 une seule fois, au moment de la construction. Ensuite, le serveur envoie directement le fichier HTML — pas de PHP, pas de base de données, pas de reconstruction.
WordPress est un restaurant qui prépare chaque plat à la commande, même si 80% des clients commandent la même chose. Un site statique prépare tous les plats à l’avance et les sert immédiatement. Le résultat dans l’assiette est le même — le temps d’attente, non.
Raison 2 : les plugins chargent du JavaScript partout
Votre plugin de formulaire de contact charge 200 KB de JavaScript. Sur chaque page. Y compris celles qui n’ont pas de formulaire.
Votre slider charge son script d’animation. Votre plugin SEO charge ses scripts d’analyse. Votre chatbot charge sa bibliothèque complète. Votre outil d’analytics charge son tracker. Chaque plugin ajoute du JavaScript — et la plupart le chargent sur toutes les pages, pas seulement là où ils sont utilisés.
Un site WordPress moyen charge entre 300 et 450 KB de JavaScript. Chaque script doit être téléchargé, analysé (parsé) et exécuté par le navigateur avant que la page ne devienne interactive.
Le résultat : votre page semble chargée, mais rien ne réagit quand vous cliquez. C’est exactement ce que mesure la métrique INP (Interaction to Next Paint) — et 23% des sites mobiles échouent sur ce seuil, un pourcentage bien plus élevé sur les sites WordPress chargés de plugins.
Raison 3 : les thèmes premium sont lourds par design
Les thèmes WordPress “premium” (Divi, Avada, Elementor) sont conçus pour tout faire. Menu mega, parallax, animations, sliders, grilles dynamiques, modales, accordéons — le thème charge le code pour toutes ces fonctionnalités, même si vous n’en utilisez qu’une fraction.
Un thème comme Divi charge environ 1,2 MB de ressources (CSS + JS) avant même votre contenu. Ce n’est pas un bug — c’est la conséquence directe du modèle “tout inclus”.
Elementor, Divi, WPBakery et compagnie créent du HTML profondément imbriqué (des dizaines de div dans des div). Ce “DOM bloat” ralentit le rendu du navigateur, augmente le CLS, et rend le HTML plus lourd. Le problème n’est pas que ces outils soient mal faits — c’est que leur flexibilité a un coût en performance que personne ne mentionne à l’achat.
Raison 4 : la base de données grossit et ralentit
WordPress stocke tout dans MySQL : articles, pages, commentaires, options, métadonnées, révisions, données de plugins, sessions, transients. Au fil du temps, cette base de données grossit.
Les problèmes concrets :
- Révisions infinies : par défaut, WordPress garde toutes les révisions de tous les articles. Un article modifié 50 fois a 50 copies en base
- Transients expirés : des données temporaires qui ne sont jamais nettoyées
- Données de plugins désinstallés : beaucoup de plugins laissent leurs tables en base après désinstallation
- Requêtes non optimisées : certains plugins font des requêtes sans index, qui ralentissent au fur et à mesure que la table grossit
Sur les pages admin, le P95 (le 5% de requêtes les plus lentes) atteint 1 598 requêtes SQL et 3,2 secondes de traitement base de données. C’est pourquoi votre tableau de bord WordPress peut sembler si lent.
Raison 5 : les images ne sont pas optimisées par défaut
WordPress accepte les images telles que vous les téléversez. Si vous uploadez un JPEG de 3 MB sorti de votre appareil photo, WordPress le sert tel quel (avec quelques versions redimensionnées, mais pas toujours au bon format).
Les problèmes courants :
- Pas de conversion automatique en WebP ou AVIF
- Pas de lazy loading natif fiable avant WordPress 5.5 (et encore imparfait)
- Les dimensions ne sont pas toujours déclarées (ce qui cause du CLS)
- Les images “above the fold” ne sont pas priorisées
Un plugin comme ShortPixel ou Imagify corrige partiellement le problème. Mais c’est encore un plugin de plus — avec son propre JavaScript, ses propres requêtes, et souvent un abonnement payant.
Ce que vous pouvez faire (sans migrer)
Si migrer n’est pas une option immédiate, voici les actions par ordre d’impact :
Installez un plugin de cache (WP Rocket, LiteSpeed Cache). Impact : -50 à -70% sur le temps de chargement. C'est la mesure la plus rentable.
Désactivez chaque plugin un par un et mesurez l'impact. Supprimez ceux qui chargent du JS sur toutes les pages sans raison.
Convertissez toutes vos images en WebP. Utilisez le lazy loading. Déclarez les dimensions. Impact : -30 à -50% sur le poids de la page.
Mettez Cloudflare devant votre site (plan gratuit). Les fichiers statiques sont servis depuis le serveur le plus proche du visiteur.
Résultat réaliste : avec ces 4 actions, vous pouvez passer d’un score Lighthouse de 35 à 60-70. C’est un progrès significatif. Mais vous ne passerez probablement pas au-dessus de 80 — parce que PHP, la base de données et le JavaScript des plugins sont toujours là.
Les plugins de cache (WP Rocket, W3 Total Cache) masquent le problème — ils stockent la page HTML en mémoire pour éviter de reconstruire à chaque visite. C’est efficace, mais fragile : chaque formulaire, chaque contenu personnalisé, chaque cookie casse le cache. Et vous vous retrouvez avec un outil de performance qui nécessite lui-même de la configuration et de la maintenance.
Ce que coûte la lenteur
Les chiffres ne sont pas abstraits :
- +8,4% de conversions retail pour 0,1 s de chargement en moins (Deloitte / Google, Milliseconds Make Millions, 2020)
- +32% de probabilité de rebond quand le chargement passe de 1 à 3 secondes (Google / SOASTA, 2017)
- Taux de conversion 3× plus élevé sur un site B2B qui charge en 1 s vs 5 s (Portent, 2022)
- 53% des visiteurs mobiles abandonnent au-delà de 3 secondes de chargement (même source Google / SOASTA)
Si votre site génère 10 000 visites par mois et que 2% convertissent, même une amélioration de 0,1 seconde peut représenter des dizaines de conversions supplémentaires par mois. Ce n’est pas un argument marketing — c’est de l’arithmétique.
Quand l’optimisation ne suffit plus
Si après le cache, l’audit des plugins, les images WebP et le CDN, votre score Lighthouse reste en dessous de 60, le problème n’est plus dans la configuration. Il est dans l’architecture :
- PHP reconstruit la page à chaque visite non cachée
- La base de données est sollicitée à chaque requête
- Les plugins chargent du JavaScript que vous ne pouvez pas supprimer sans perdre des fonctionnalités
- Le thème premium est trop lourd pour être allégé
À ce stade, deux options :
- Vivre avec — et accepter que votre site sera toujours plus lent que vos concurrents qui ont fait un autre choix technique
- Migrer — vers une architecture qui ne souffre pas de ces problèmes par conception
On a écrit un guide complet sur la deuxième option : Migrer de WordPress à Astro : le guide complet.
Vous voulez savoir où en est votre site ? PageSpeed Insights vous donne la réponse en 30 secondes. Si les résultats confirment ce que vous soupçonniez, le configurateur vous dit ce qu’un site Astro coûterait — avec les mêmes fonctionnalités, sans la lenteur.