WordPress fait tourner 43 % du web. Parmi ces sites, certains chargent en moins d’une seconde, d’autres mettent 6 secondes à afficher quoi que ce soit. Le logiciel est le même. Ce qui change, c’est tout ce qui l’entoure.
Selon les données CrUX, seulement 32 % des sites WordPress atteignent un bon TTFB. Et 53 % des utilisateurs mobiles quittent un site qui prend plus de 3 secondes à charger (Google, The Need for Mobile Speed). Ces deux chiffres pointent vers les mêmes dix problèmes, qui reviennent sur presque tous les sites sous-performants.
Voici ces dix causes, dans l’ordre où elles pèsent sur vos métriques, avec la correction concrète pour chacune.
Un hébergement mutualisé sans ressources dédiées
Sur un hébergement mutualisé standard, votre site WordPress partage le CPU, la RAM et les I/O disque avec des dizaines ou centaines d’autres sites. Quand un voisin reçoit un pic de trafic, vos temps de réponse augmentent sans que vous puissiez rien y faire.
Cela se lit directement dans le TTFB : les hébergements mutualisés budget livrent couramment des TTFB entre 400 ms et 800 ms. Sur un hébergement WordPress managé, la médiane se situe entre 350 ms et 450 ms selon les hébergeurs (données Hostingstep Benchmark 2025).
Correction : Migrez vers un hébergeur managé WordPress (Kinsta, WP Engine, Rocket.net, Templ) ou un VPS avec configuration dédiée. Le seul critère utile : le TTFB médian mesuré en conditions réelles, pas la RAM annoncée sur la fiche produit.
Absence de cache de page
Par défaut, chaque requête vers un site WordPress déclenche une exécution PHP complète : connexion à la base de données, chargement de l’environnement, exécution des hooks, génération du HTML, envoi au navigateur. Pour une page qui ne change pas entre deux visites, c’est du calcul inutile à chaque fois.
Un cache de page stocke le HTML généré et le sert directement, sans toucher à PHP ni à MySQL. D’après le rapport WordPress Performance 2025 de DebugHawk (5,7 millions de pages vues), activer le cache de page produit un TTFB 7 fois plus rapide en médiane.
Correction : Installez WP Rocket, LiteSpeed Cache (si votre hébergeur utilise LiteSpeed) ou W3 Total Cache. Activez le cache de page, le cache du navigateur et le cache des objets. Vérifiez l’en-tête de réponse X-Cache: HIT sur les pages statiques pour confirmer que le cache fonctionne.
Absence de cache objet (Redis ou Memcached)
Le cache de page gère les pages complètes. Le cache objet gère les requêtes répétées à la base de données pour les données dynamiques : sessions utilisateurs, requêtes WooCommerce, données de navigation, options WordPress. Sans lui, chaque requête recalcule des données déjà connues.
Un cache objet persistant (Redis ou Memcached) réduit le temps d’exécution PHP médian de 67 % (DebugHawk, 2025). Sur les sites e-commerce ou les sites avec utilisateurs connectés où le cache de page ne s’applique pas, c’est le levier le plus direct.
Correction : Vérifiez que votre hébergeur propose Redis ou Memcached (la plupart des hébergeurs managés l’incluent). Installez le plugin Redis Object Cache de Till Krüss. Allez dans Réglages > Redis pour vérifier le statut de connexion. Sur Kinsta ou WP Engine, l’activation se fait depuis le tableau de bord hébergeur sans plugin.
Images non optimisées
Sur les sites qui ont déjà un bon TTFB, les images non optimisées sont souvent la première cause de lenteur côté chargement. Le problème prend plusieurs formes : format JPEG ou PNG là où WebP ou AVIF réduirait le poids de 25 à 50 %, images redimensionnées par le navigateur au lieu d’être servies à la bonne taille, attribut loading="lazy" absent, images au-dessus de la ligne de flottaison sans préchargement.
Une image JPEG full-width non compressée dépasse couramment 1 à 2 Mo. La même image en WebP correctement dimensionnée pèse 80 à 200 Ko.
Correction : Installez Imagify, ShortPixel ou Smush. Activez la conversion automatique en WebP. Dans Réglages > Médias, vérifiez que WordPress génère les bonnes tailles d’image. Ajoutez l’attribut fetchpriority="high" sur l’image LCP (le plus grand élément visible au chargement). Pour les images sous la ligne de flottaison, loading="lazy" est suffisant.
Plugins mal codés ou non utilisés
Chaque plugin actif ajoute du code PHP qui s’exécute à chaque requête. Le nombre de plugins n’est pas le problème en soi : un site peut en avoir 30 et charger en 800 ms. Ce qui compte, c’est la qualité du code. Un plugin mal écrit peut ajouter 300 à 500 ms à lui seul, en exécutant des requêtes SQL non optimisées ou en chargeant des scripts sur toutes les pages sans condition.
Correction : Installez Query Monitor (plugin gratuit). Ouvrez l’onglet Database Queries et triez par durée. Si une requête dépasse 50 ms, identifiez le plugin responsable dans la colonne « Caller ». Désactivez les plugins inutilisés : un plugin désactivé ne consomme pas de ressources, un plugin actif non utilisé si. Supprimez les plugins dormants plutôt que de les laisser installés.
Scripts JavaScript et CSS chargés sur toutes les pages
WordPress charge par défaut les scripts de chaque plugin sur toutes les pages, même quand ils ne sont pas nécessaires. Un formulaire de contact qui charge jQuery UI partout, un plugin de popup qui injecte ses assets en dehors des pages où il s’affiche, un plugin de slider présent uniquement sur la page d’accueil mais actif sur tout le site : chaque script supplémentaire est une requête HTTP et un temps de parsing JavaScript.
Correction : Dans WP Rocket, activez Charger le JS de manière différée et Charger les CSS de manière asynchrone. Dans le module Exclure, listez les scripts critiques qui ne doivent pas être différés (scripts de paiement Stripe, scripts d’analytics first-party). Vérifiez ensuite dans PageSpeed Insights > Opportunités > Éliminer les ressources bloquant le rendu quels scripts subsistent.
Absence de CDN
Si votre serveur est en Europe et votre visiteur en Asie-Pacifique, la latence réseau seule dépasse 150 ms avant que la première réponse soit envoyée. Un CDN (Content Delivery Network) sert les ressources statiques depuis le datacenter le plus proche du visiteur. Avec un CDN qui fait du edge caching, il sert même les pages HTML depuis le bord du réseau.
La moitié des sites WordPress qui échouent aux Core Web Vitals le font en partie à cause d’un serveur sans CDN (données make.wordpress.org, 2024).
Correction : Activez Cloudflare (l’offre gratuite suffit pour commencer). Dans le tableau de bord Cloudflare, allez dans Speed > Optimization et activez Auto Minify (HTML, CSS, JS). Activez Rocket Loader pour les scripts JavaScript. Pour les sites avec fort trafic international, passez sur l’offre Pro pour le cache HTML en edge.
Base de données surchargée
La table wp_options de WordPress est conçue pour stocker les options du site. Avec le temps, les plugins y accumulent des données transitoires (transients), des logs, des données de cache expirées qui ne se nettoient pas seules. Une table wp_options qui dépasse 50 000 lignes ralentit le chargement de WordPress, surtout si l’option autoload = yes est activée sur des données volumineuses.
Correction : Installez WP-Optimize ou Advanced Database Cleaner. Lancez un nettoyage des révisions de posts (gardez 3 révisions maximum), des transients expirés, des commentaires spam et des tables orphelines laissées par des plugins désinstallés. Dans Query Monitor > Options Chargées, vérifiez que la taille totale des options autoload ne dépasse pas 1 Mo.
Thème surchargé ou page builder lourd
Certains thèmes et page builders (Divi, Elementor en configuration par défaut, Avada) génèrent un HTML inutilement gonflé et chargent plusieurs Mo de CSS et JS qui ne servent pas la page affichée. Elementor par défaut charge son CSS global sur chaque page, quelle que soit la mise en page utilisée.
Correction : Mesurez d’abord avec PageSpeed Insights la taille du CSS inutilisé (Opportunités > Supprimer les CSS inutilisés). Si vous êtes sur Elementor, allez dans Elementor > Réglages > Avancé et activez Improved CSS Loading pour charger uniquement le CSS de chaque widget utilisé. Pour isoler la responsabilité du thème, testez avec Twenty Twenty-Four en désactivant temporairement le vôtre : si le score remonte de 20 points, le thème est coupable.
INP : le remplacement de FID en mars 2024
En mars 2024, Google a remplacé FID (First Input Delay) par INP (Interaction to Next Paint) dans le calcul des Core Web Vitals. L’INP mesure la réactivité de toutes les interactions sur la page, pas seulement la première. Au moment du changement, 600 000 sites qui passaient les Core Web Vitals ont basculé en échec (NitroPack, 2024). L’INP échoue principalement sur les sites avec du JavaScript lourd qui bloque le thread principal lors des interactions.
Correction : Dans PageSpeed Insights, vérifiez votre score INP (objectif : sous 200 ms). Dans Chrome DevTools > Performance, enregistrez une session d’interaction et cherchez les Long Tasks (tâches qui bloquent le thread plus de 50 ms). Les suspects habituels : scripts analytics tiers (consentement, A/B testing), événements scroll sans debounce, calculs CSS complexes au hover. Différez ces scripts ou isolez-les dans un Web Worker.
Les 10 causes et leurs correctifs
| Cause | Impact principal | Correctif prioritaire | Outil recommandé |
|---|---|---|---|
| Hébergement mutualisé | TTFB 400-800 ms | Migrer vers hébergeur managé | Kinsta, Rocket.net, WP Engine |
| Pas de cache de page | TTFB 7× plus lent | Activer le cache de page | WP Rocket, LiteSpeed Cache |
| Pas de cache objet | +67 % temps PHP | Activer Redis ou Memcached | Redis Object Cache |
| Images non optimisées | Pages 1-2 Mo inutilement | Convertir en WebP + lazy load | Imagify, ShortPixel |
| Plugins mal codés | +300-500 ms par plugin | Auditer avec Query Monitor | Query Monitor |
| Scripts chargés partout | Requêtes HTTP inutiles | Différer JS, async CSS | WP Rocket, Asset CleanUp |
| Pas de CDN | +150 ms latence réseau | Activer Cloudflare | Cloudflare (offre Free) |
| Base de données surchargée | Requêtes lentes wp_options | Nettoyer transients + révisions | WP-Optimize |
| Thème / page builder lourd | CSS inutilisé > 200 Ko | Activer CSS sélectif Elementor | PageSpeed Insights + DevTools |
| INP échoué (post-mars 2024) | Core Web Vitals échec | Auditer Long Tasks JS | Chrome DevTools Performance |
Par où commencer
Dans cet ordre :
- Mesurez l’état actuel avec PageSpeed Insights (mobile et desktop). Notez votre TTFB, LCP, CLS et INP.
- Regardez le TTFB en premier. S’il dépasse 600 ms, l’hébergement est le problème. Les autres optimisations ne compenseront pas un serveur lent.
- Activez le cache de page et le cache objet avant de toucher à autre chose.
- Optimisez vos images : installez un plugin de compression, convertissez en WebP, ajoutez
fetchpriority="high"sur l’image LCP. - Auditez vos plugins avec Query Monitor. Supprimez ceux qui ne servent plus.
- Activez Cloudflare si ce n’est pas déjà fait.
- Nettoyez la base de données avec WP-Optimize, puis planifiez ce nettoyage une fois par mois.
- Vérifiez votre score INP et cherchez les Long Tasks dans Chrome DevTools.
- Mesurez à nouveau. Si le LCP reste au-dessus de 2,5 s ou l’INP au-dessus de 200 ms, revenez aux étapes 5 à 8.
- Planifiez un audit trimestriel : les mises à jour de plugins réintroduisent régulièrement des régressions de performance.
Un audit PageSpeed Insights prend cinq minutes. Il indique exactement ce qui bloque et dans quel ordre s’y attaquer. C’est par là que ça commence.
