Sur cette page · 11 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 chiffres que personne ne vous montre#
Commençons par les données. Pas les promesses marketing des hébergeurs WordPress, les mesures réelles :
| Indicateur (mobile) | WordPress, médiane du marché | Ce qu’il faut viser |
|---|---|---|
| Score Lighthouse Performance | 43 / 100 | > 90 |
| Poids de page | ≈ 3 Mo | < 1 Mo |
| Sites qui passent les 3 Core Web Vitals | 48 % | Le vôtre |
Données HTTP Archive Tech Report, septembre 2026, mobile, toutes origines.
Un score médian de 43 sur 100, et plus d’un site WordPress sur deux qui échoue aux Core Web Vitals sur mobile. 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, selon le rapport 2025 de DebugHawk — 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.
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, selon le Web Almanac 2025 d’HTTP Archive, 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 plusieurs centaines de kilooctets de CSS et de JavaScript avant même votre contenu. Ce n’est pas un bug — c’est la conséquence directe du modèle “tout inclus”.
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 (même rapport DebugHawk). 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.
Raison 6 : l’hébergement et la version de PHP#
C’est la cause qu’on vous citera en premier, et elle est réelle. Un serveur mutualisé saturé ajoute de l’attente avant même que WordPress démarre, et la version de PHP pèse sur chaque page générée. WordPress recommande aujourd’hui PHP 8.3 ou plus récent. Vérifiez celle de votre hébergeur dans Outils > Santé du site, onglet Informations.
Changer d’hébergeur ou passer à une version récente de PHP réduit le temps de réponse du serveur. Ça ne retire ni le JavaScript des plugins, ni le poids du thème, ni les requêtes à la base de données. C’est souvent le premier conseil qu’on reçoit, et rarement celui qui suffit.
Ce que vous pouvez faire (sans migrer)#
Si migrer n’est pas une option immédiate, voici les actions par ordre d’impact :
- Cache serveur
Installez un plugin de cache (WP Rocket, LiteSpeed Cache). Impact : -50 à -70% sur le temps de chargement. C'est la mesure la plus rentable.
- Audit des plugins
Désactivez chaque plugin un par un et mesurez l'impact. Supprimez ceux qui chargent du JS sur toutes les pages sans raison.
- Images WebP
Convertissez toutes vos images en WebP. Utilisez le lazy loading. Déclarez les dimensions. Impact : -30 à -50% sur le poids de la page.
- CDN
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à.
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. C’est la méthode qu’on a appliquée à Marrakech City Guide, un site WordPress remis en ligne sous Astro en juillet 2026.
Questions fréquentes#
Comment savoir si mon site WordPress est lent ?
Collez l'adresse de votre page d'accueil dans PageSpeed Insights et regardez les données terrain, en haut : elles mesurent ce que vivent vos vrais visiteurs. Le rapport Core Web Vitals de Search Console donne la même information pour tout le site. Le détail des trois métriques est dans notre guide des Core Web Vitals.
Quel plugin de cache choisir ?
LiteSpeed Cache si votre hébergeur tourne sous LiteSpeed : son cache de page ne fonctionne que sur ces serveurs. WP Rocket sinon. Un seul plugin de cache à la fois : deux se marchent dessus.
Combien de plugins, c’est trop ?
Le nombre compte moins que ce que chacun charge. Un seul plugin qui ajoute son JavaScript sur toutes les pages coûte plus cher que dix plugins discrets. Désactivez-les un par un en mesurant à chaque fois : c'est la seule façon de trouver le coupable.
Changer d’hébergeur suffit-il ?
Ça réduit le temps de réponse du serveur, ce qui compte. Mais ça ne touche ni au JavaScript des plugins, ni au poids du thème, ni aux images. Sur un site chargé, un meilleur hébergeur fait gagner quelques points, rarement assez pour passer au vert.
WordPress est-il lent par nature ?
Pas forcément. Un WordPress léger, avec peu de plugins, un thème sobre, un bon hébergeur et un cache bien réglé peut être rapide. Mais par défaut, il reconstruit chaque page à chaque visite et accumule les extensions : le score médian du marché est de 43 sur 100.
Faut-il migrer pour avoir un site rapide ?
Pas toujours. Si l'optimisation vous amène au-dessus de 90 sur PageSpeed, gardez WordPress. Si vous plafonnez en dessous de 60 malgré le cache, l'audit des plugins et les images, le problème est l'architecture : le guide de migration explique comment en sortir sans perdre votre référencement.
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. Et si vous préférez qu’on s’en charge : notre offre de refonte WordPress.