Site WordPress lent : 7 causes et comment les corriger

Un site WordPress lent l’est le plus souvent pour l’une de sept causes : un hébergement trop juste, un constructeur de pages, trop d’extensions, des images lourdes, des polices mal chargées, des scripts tiers ou l’absence de cache. Mesurez avec PageSpeed Insights, puis corrigez cause par cause.

Votre site met plusieurs secondes à s’afficher sur téléphone ? Vos visiteurs le remarquent, et Google aussi : la vitesse fait partie des signaux qu’il utilise pour classer les pages. Le sujet concerne beaucoup de monde : WordPress fait tourner plus de quatre sites sur dix dans le monde (40,2 %), selon W3Techs en octobre 2026. Bonne nouvelle, les causes d’un site WordPress lent sont souvent les mêmes. Voici comment les repérer et les corriger.

Mesurer avant de corriger

Ouvrez PageSpeed Insights et testez votre page d’accueil, puis une page importante. Regardez d’abord le bloc « Découvrez ce que vivent vos utilisateurs » : ce sont les mesures réelles de vos visiteurs, celles que Google utilise. Le score sur 100, en dessous, est une simulation utile pour diagnostiquer.

Google mesure trois indicateurs, les Core Web Vitals, au 75e centile des visites (seuils de Google) :

Indicateur	Ce qu’il mesure	Bon	Mauvais
LCP	Temps d’affichage du plus gros élément visible	≤ 2,5 s	> 4 s
INP	Délai de réaction après un clic ou une saisie	≤ 200 ms	> 500 ms
CLS	Stabilité visuelle : les décalages inattendus de la mise en page	≤ 0,1	> 0,25

Entre les deux, Google parle d’indicateur « à améliorer ».

Notez vos chiffres : ils serviront à vérifier que chaque correction a un effet.

1. Un hébergement trop juste

Si le serveur met du temps à répondre, rien ne peut s’afficher avant. Dans PageSpeed Insights, regardez le TTFB (temps de réponse du serveur). Au-delà de 0,8 seconde, l’hébergement peut être en cause, mais aussi le thème, les extensions, la base de données, l’absence de cache ou la distance du serveur. Les offres mutualisées les moins chères partagent un serveur entre des centaines de sites.

Correction : un hébergement avec PHP récent, assez de mémoire, et un serveur situé près de vos visiteurs.

2. Le constructeur de pages

Elementor, Divi ou WPBakery permettent de construire une page sans coder, mais le prix est élevé : chaque section devient une pile de blocs imbriqués, et une grande partie du CSS et du JavaScript des widgets se charge sur toutes les pages, qu’ils servent ou non.

Un exemple : avant la refonte de notre propre site, son ancienne page d’accueil, construite avec Elementor et un thème premium, chargeait 57 scripts et un HTML de 430 Ko avant la moindre image.

Correction : désactiver les widgets inutilisés, activer les options d’optimisation du constructeur, et éviter les animations au défilement. Le gain reste limité : la structure de la page ne change pas.

3. Trop d’extensions

Chaque extension peut ajouter ses propres fichiers à chaque page et ses requêtes à la base de données. Une extension de formulaire chargée sur tout le site, une galerie utilisée sur une seule page, un slider oublié : tout s’additionne.

Correction : listez vos extensions et supprimez celles dont vous ne pouvez pas dire à quoi elles servent. Pour celles qui restent, limitez leur chargement aux pages qui les utilisent.

4. Des images trop lourdes

Une photo de 4 000 pixels de large affichée dans un cadre de 600 pixels, c’est jusqu’à dix fois trop de données. C’est une cause très fréquente d’un mauvais LCP.

Correction :

• redimensionner les images à leur taille d’affichage réelle ;
• utiliser les formats WebP ou AVIF ;
• charger en différé (loading="lazy") les images situées plus bas dans la page, mais jamais l’image principale du haut de page, qui doit arriver en premier.

5. Trop de polices

Trois familles de polices en cinq graisses chacune, chargées depuis Google Fonts : c’est une quinzaine de fichiers avant que le texte s’affiche correctement, et souvent un décalage visible quand la police arrive (CLS).

Correction : deux familles au maximum, une police variable si possible, hébergée sur votre serveur et préchargée.

6. Les scripts tiers

Chat en ligne, pixels publicitaires, carte Google Maps intégrée, vidéos YouTube : chacun télécharge son propre code depuis un autre serveur. Ils dégradent souvent l’INP, parce qu’ils occupent le navigateur au moment où le visiteur veut cliquer.

Correction : gardez seulement les scripts dont vous utilisez vraiment les données. Pour une carte ou une vidéo, affichez d’abord une simple image, et chargez le lecteur au clic.

7. Aucun cache

Sans cache, WordPress reconstruit chaque page à chaque visite : requêtes à la base de données, exécution du thème et des extensions. Avec un cache de pages, le serveur envoie une copie déjà prête.

Correction : une extension de cache, ou mieux, le cache proposé par l’hébergeur, complété par un CDN pour les images et les fichiers statiques.

Corriger ou reconstruire ?

Si vos problèmes viennent de l’hébergement, des images, des extensions ou du cache, les corrections ci-dessus suffisent souvent à passer au vert.

Si la cause principale est le constructeur de pages, chaque optimisation se heurte à la même limite. C’est ce qui nous a décidés à reconstruire ce site en pages statiques, sans constructeur ni extensions.

Vous voulez savoir ce qui ralentit votre site ? Notre formule Remise en forme WordPress commence par un audit de vitesse : nous vous dirons s’il vaut mieux le corriger ou le refaire. Parlez-nous de votre site. Pour qu’il reste rapide ensuite, nos formules de maintenance s’occupent des mises à jour et du cache.