Pourquoi WordPress est lent : diagnostic et correctifs

D’après web.dev, le site de Google dédié aux performances, une page se charge bien quand son plus grand élément s’affiche en 2,5 secondes au plus et quand le serveur répond en 0,8 seconde au plus. Si votre site dépasse ces deux seuils, la lenteur a une cause précise, et elle se cherche dans un ordre précis. Voici pourquoi WordPress est lent, comment le savoir avec des mesures plutôt qu’au ressenti, et quels correctifs passer en premier.

À partir de quelle lenteur faut-il s’inquiéter ?

Un site WordPress est considéré comme rapide quand les trois indicateurs des Core Web Vitals passent leurs seuils pour au moins 75 % des chargements, d’après web.dev. Le temps de réponse du serveur, le TTFB, vient en complément. Il est bon sous 0,8 seconde, à améliorer entre 0,8 et 1,8 seconde, mauvais au-delà.

Indicateur	Ce qu’il mesure	Seuil « bon »	Premier suspect si le seuil est dépassé
TTFB	Délai avant l’arrivée du premier octet de la réponse	0,8 s ou moins	Serveur, PHP, cache absent, base de données
LCP	Affichage du plus grand élément de la page	2,5 s ou moins	Image principale trop lourde, thème, scripts
INP	Délai de réaction après un clic ou une frappe	200 ms ou moins	Scripts de thème ou d’extensions
CLS	Déplacements de la mise en page pendant le chargement	0,1 ou moins	Éléments qui apparaissent sans place réservée

Ce tableau indique où regarder avant de toucher à quoi que ce soit. Les premiers suspects de la dernière colonne sont notre lecture des mesures, pas une règle de Google.

Quel outil pour mesurer ?

PageSpeed Insights réunit deux sources. Les données de terrain viennent du Chrome User Experience Report et couvrent les 28 derniers jours de visiteurs réels. Les données de laboratoire viennent de Lighthouse, qui simule un chargement dans des conditions fixes. Les deux peuvent diverger, d’après la documentation de Google. Les outils de développement de Chrome et de Firefox, cités par la documentation de WordPress, permettent de voir le détail de chaque requête.

Serveur ou navigateur : où se situe la lenteur ?

Regardez le TTFB. S’il dépasse 0,8 seconde, le temps se perd avant que la page ne parte vers le navigateur, côté serveur. S’il est bon et que le LCP reste long, le serveur répond vite mais la page est trop lourde à afficher.

Ce que vous observez	Zone probable	Où lire la suite
TTFB supérieur à 0,8 s, même sur une page simple	Hébergement, version de PHP, absence de cache, base de données	PHP, cache, base, hébergement
TTFB correct, LCP supérieur à 2,5 s	Image principale, thème, scripts qui bloquent l’affichage	Images, thème et extensions
Site rapide pour les visiteurs, administration lente	PHP, extensions, base de données : l’administration ne passe pas par le cache de page	Extensions, base
Lenteur apparue juste après une mise à jour ou un déménagement	Version de PHP, extension incompatible, adresses mal remplacées	PHP, extensions

La troisième ligne mérite une précision. Un cache de page conserve la version terminée d’une page pour la resservir aux visiteurs, d’après la documentation de WordPress. Votre administration, elle, repasse par PHP et par la base à chaque clic.

Si la lenteur est apparue juste après un déménagement, reprenez les vérifications de notre guide pour migrer un site WordPress local en ligne : la version de PHP de l’hébergeur et les adresses du site sont les deux premiers points à contrôler.

Les six correctifs, classés par effort et par gain

Commencez par ce qui demande peu d’effort et touche le serveur : PHP et cache. Les images et les extensions viennent ensuite, la base de données et l’hébergement en dernier, parce qu’ils demandent plus de précautions ou de budget.

Correctif	Effort	Ce qu’il améliore	À faire en priorité si
Version de PHP	Faible	Temps de réponse du serveur	Votre PHP est ancien ou proche de sa fin de support
Cache de page	Faible à moyen	TTFB, et tout le reste pour les visiteurs	Votre site est surtout du contenu à lire
Images	Moyen	LCP, poids de la page	Le LCP est long et le TTFB correct
Thème et extensions	Moyen à élevé	TTFB et INP	Une extension ajoute des requêtes ou des scripts
Base de données	Moyen, avec sauvegarde	TTFB, administration	Site ancien, beaucoup d’options chargées
Hébergement	Élevé	Tout, en dernier recours	Les cinq autres sont faits et le TTFB reste haut

Ce classement est le nôtre. Il reflète l’effort demandé et l’endroit du chargement que chaque correctif touche, pas un gain mesuré : celui de votre site se vérifie par un test avant et après.

La version de PHP, le réglage le plus rapide

Passez à une version de PHP encore supportée. WordPress recommande PHP 8.3 ou plus, d’après sa page des prérequis, et les versions plus anciennes peuvent exposer le site à des failles de sécurité. Sur le site de PHP, la branche 8.2 reçoit des correctifs de sécurité jusqu’au 31 décembre 2026, la 8.3 jusqu’au 31 décembre 2027, la 8.4 jusqu’au 31 décembre 2028.

Le changement se fait dans l’espace client. Chez Hostinger, il se trouve dans Configuration PHP, dans le menu du site, et la version choisie s’applique à tous les sites de l’offre. Ce réglage change aussi le comportement des extensions : faites d’abord une sauvegarde, puis passez sur le site et testez l’accueil, un article et l’administration.

Le gain varie selon le site et ses extensions. Aucune des sources officielles consultées ne donne de pourcentage universel, mesurez donc votre TTFB avant et après.

Le cache de page, le plus gros levier pour un site de contenu

Un cache de page enregistre chaque page terminée et la renvoie sans relancer PHP ni la base. La documentation de WordPress estime que le gain peut atteindre plusieurs centaines de fois pour des pages assez statiques. C’est le correctif qui agit le plus sur le TTFB d’un blog ou d’un site vitrine.

Une extension de cache suffit, pas deux. Le choix dépend de votre serveur : LiteSpeed Cache profite d’un hébergement LiteSpeed, WP Super Cache convient ailleurs. Les deux, leurs notes et leurs limites sont décrits dans notre guide des extensions WordPress indispensables.

Les images, souvent le premier poids d’une page

Si le LCP est long, regardez l’image principale. Depuis la version 5.3, WordPress réduit toute image envoyée dont un côté dépasse 2 560 pixels et conserve l’original, d’après l’équipe du noyau. Une photo d’appareil de 6 000 pixels de large est donc ramenée à 2 560, ce qui reste souvent plus grand que son emplacement dans l’article.

• Redimensionnez avant l’envoi à la taille réellement affichée dans l’article, plutôt qu’à la limite de WordPress.
• Passez au format WebP, que la documentation de WordPress cite comme format plus récent et plus compact que JPG et PNG. L’extension officielle Performance Lab gère WebP et AVIF, et l’équipe de WordPress qui la développe la présente comme un terrain d’essai pour de futures fonctions du noyau.
• Compressez l’existant avec l’extension d’images de votre choix, décrite dans le guide des extensions déjà cité.

Thème et extensions, trouver la coupable avec Query Monitor

Le nombre d’extensions ne dit rien en soi. Ce qui compte, ce sont les requêtes et les scripts que chacune ajoute à vos pages. Query Monitor les affiche, qu’il s’agisse de requêtes lentes ou en double, de l’extension ou du thème responsable, d’appels HTTP ou de scripts chargés. L’extension compte plus de 200 000 installations actives, et son affichage est réservé aux administrateurs par défaut.

1. Installez Query Monitor puis ouvrez la barre qu’il ajoute en haut de l’écran sur une page lente.
2. Triez les requêtes par temps et par composant, pour voir quelle extension ou quel thème se cache derrière les plus lentes.
3. Contrôlez les scripts chargés sur l’accueil : une extension de formulaire qui charge ses fichiers sur toutes les pages est un candidat classique.
4. Testez la suspecte sur une copie en la désactivant dans un site local plutôt qu’en production. Le guide pour installer WordPress en local décrit l’outil pour le faire.

Supprimez ce que vous n’utilisez pas, et gardez une extension par besoin, comme le recommande notre guide des extensions. Si le thème est en cause, le seul test fiable est de comparer avec un thème par défaut sur la copie locale.

La base de données, trois endroits où elle gonfle

Sauvegardez la base avant de la toucher, la méthode est dans notre guide de la sauvegarde. Trois endroits méritent un contrôle.

• Les options chargées automatiquement. WordPress charge ces options à chaque page. Depuis la version 6.6, son contrôle Site Health affiche une alerte critique quand elles dépassent 800 Ko, et les options de plus de 150 Ko ne sont plus chargées par défaut. Avec WP-CLI, wp option list --autoload=on --format=total_bytes donne le total, et wp option list --autoload=on --fields=option_name,size_bytes la taille de chacune. L’extension Performance Lab propose un audit détaillé.
• Les révisions d’articles. WordPress les active par défaut. La constante WP_POST_REVISIONS du fichier wp-config.php les limite, par exemple define( 'WP_POST_REVISIONS', 3 );, ou les désactive avec false.
• Les transients expirés, des données temporaires qui peuvent s’accumuler. wp transient delete --expired supprime uniquement ceux qui ont expiré.

Une option volumineuse appartient souvent à une extension. Repérez laquelle avant de supprimer quoi que ce soit : une option supprimée à l’aveugle peut casser son réglage.

L’hébergement, quand tout le reste est fait

Si le TTFB reste supérieur à 0,8 seconde avec un cache actif, un PHP à jour et un site léger, le serveur est le suspect restant. Un hébergement mutualisé partage ses ressources entre plusieurs sites, et un site qui grossit peut les saturer. Notre guide hébergement mutualisé, VPS ou dédié détaille les ressources, le contrôle et les prix d’entrée de chaque type, ce qui permet de savoir s’il faut monter en gamme ou seulement changer d’offre.

La documentation de WordPress cite aussi, comme dernière étape, la délocalisation du contenu : un CDN sert les fichiers statiques depuis des serveurs proches du visiteur. Il aide le LCP des visiteurs éloignés, il ne remplace ni le cache ni un serveur correct.

Quand le serveur répond vite, que corriger dans la page ?

Un TTFB correct ne garantit pas un LCP correct. web.dev décompose le LCP en quatre temps et fixe une répartition idéale : environ 40 % pour la réponse du serveur, moins de 10 % pour le délai avant que la ressource principale ne démarre, environ 40 % pour son transfert et moins de 10 % pour son affichage. Un TTFB qui prend une part plus grande explique pourquoi le serveur passe en premier dans notre ordre.

Indicateur	Causes les plus courantes, d’après web.dev	Correction	Côté WordPress
LCP	Ressource principale découverte tard, image lourde, feuilles de style qui bloquent l’affichage	Priorité haute sur l’image principale, aucun chargement différé dessus, compression, CDN	Depuis la version 6.3, WordPress ajoute fetchpriority="high" à l’image qu’il juge principale, au-delà de 50 000 pixels carrés
INP	Tâches longues du navigateur, exécution de JavaScript, page très volumineuse	Réduire les scripts, découper les tâches longues	Query Monitor liste les scripts chargés par chaque extension
CLS	Images, iframes et publicités sans dimensions, polices web qui changent à l’affichage	Dimensions ou ratio réservés, police de secours adaptée	Contrôlez ce qui apparaît après le chargement, bannière de cookies, vidéos intégrées, formulaires

Une ligne se lit à part. L’équipe de WordPress estime que la priorité automatique améliore le LCP de 5 à 10 % en général, et que la version 6.3 évite aussi le chargement différé des images du haut de page. Une extension de chargement différé peut néanmoins défaire ce réglage : si le LCP reste long, vérifiez que l’image principale ne porte pas loading="lazy" dans le code source de la page.

Un changement à la fois, une mesure à chaque fois

Le piège classique consiste à tout corriger d’un coup : le site devient plus rapide, et plus personne ne sait pourquoi. Procédez plutôt ainsi.

1. Relevez trois mesures de départ. TTFB, LCP et INP sur l’accueil et sur un article, avec PageSpeed Insights. Notez-les à côté de la date.
2. Appliquez un seul correctif. Suivez l’ordre du tableau, de PHP jusqu’à l’hébergement.
3. Mesurez à nouveau, sans cache de navigateur. Videz aussi le cache de l’extension. Gardez le correctif si l’indicateur visé s’améliore, annulez-le sinon.
4. Arrêtez-vous quand les seuils sont atteints. Un TTFB sous 0,8 s, un LCP sous 2,5 s et un INP sous 200 ms suffisent d’après web.dev. Au-delà, chaque gain coûte plus de temps qu’il ne rapporte de visiteurs.

Questions fréquentes

Combien d’extensions faut-il pour ralentir un site ?

Aucune source officielle ne donne de nombre. Une extension légère coûte peu, une extension qui charge ses scripts sur chaque page ou multiplie les requêtes coûte beaucoup. Query Monitor montre ce que chacune ajoute.

Mon site est rapide chez moi et lent chez les visiteurs, pourquoi ?

Parce que vous ne voyez pas ce qu’ils voient. Connecté, vous passez en général à côté du cache de page, et vos données de laboratoire ne reflètent pas leurs connexions. Consultez les données de terrain de PageSpeed Insights, qui portent sur les 28 derniers jours de visiteurs réels.

Faut-il viser un score de 100 sur PageSpeed Insights ?

Non. Pour Google, une page est bonne quand elle passe les seuils de LCP, d’INP et de CLS pour 75 % des chargements. Le score de laboratoire sert à repérer les causes, pas à fixer un objectif.

L’administration est lente mais pas le site, que faire ?

Le cache de page ne sert que les visiteurs. Vérifiez la version de PHP, la taille des options chargées automatiquement et les requêtes de vos extensions avec Query Monitor.

Notre verdict