L'essentiel à retenir : un score PageSpeed Insights faible sur WordPress vient presque toujours des mêmes causes — images non optimisées, scripts bloquant le rendu et absence de cache. Corrigez-les dans cet ordre, retestez après chaque changement, et la plupart des sites passent du rouge au vert sans mise à niveau d'hébergement ni réécriture de thème.
Pourquoi les sites WordPress obtiennent de mauvais scores sur PageSpeed Insights
WordPress facilite l'ajout de plugins, de constructeurs de pages et de scripts tiers — chacun apportant son propre CSS, JavaScript, et parfois des requêtes externes. Une installation par défaut avec un constructeur de pages, quelques plugins marketing et des médias non optimisés peut facilement livrer 3-4 Mo de ressources pour une seule page.
PageSpeed Insights exécute deux analyses distinctes sur chaque URL testée :
- Données de laboratoire : un audit Lighthouse simulé, exécuté instantanément sur les serveurs de Google dans des conditions de réseau et d'appareil fixes. Utile pour repérer des problèmes précis, mais c'est un instantané, pas un comportement d'utilisateur réel.
- Données de terrain : mesures réelles provenant de véritables utilisateurs Chrome ayant visité votre site au cours des 28 derniers jours, issues du Chrome User Experience Report (CrUX). Elles n'apparaissent que si votre site a suffisamment de trafic Chrome.
Un site peut obtenir 95 en laboratoire et pourtant afficher une note "poor" dans les données de terrain — généralement parce que les utilisateurs réels ont des connexions plus lentes ou des appareils plus anciens que ne le suppose la simulation en laboratoire. Les deux chiffres comptent, mais le rapport Core Web Vitals de Search Console utilise les données de terrain — c'est donc celui-là qui est lié aux signaux de classement.
L'ordre qui change vraiment le score
Traitez ces points dans l'ordre — chacun a généralement un effet plus important que le suivant, donc les traiter dans le désordre fait perdre du temps sur de petits gains d'abord.
1. Corrigez d'abord vos images
Sur une page WordPress moyenne, les images représentent 50 à 80 % du poids total de la page. C'est presque toujours la correction la plus rentable, et c'est généralement ce qui déclenche un score Largest Contentful Paint (LCP) rouge, car l'élément LCP sur la plupart des pages est une image hero, une image mise en avant, ou une photo produit au-dessus de la ligne de flottaison.
Trois choses à vérifier sur chaque image au-dessus de la ligne de flottaison :
- Format — est-elle encore en JPEG ou PNG brut ? WebP est environ 25-35 % plus léger à qualité équivalente, et AVIF réduit souvent la taille de moitié par rapport au JPEG.
- Dimensions — une photo de 4000px de large est-elle compressée dans un conteneur de 800px ? Le navigateur télécharge quand même le fichier complet avant de le redimensionner.
- Priorité de chargement — l'image LCP est-elle accidentellement marquée
loading="lazy"? C'est l'une des erreurs les plus fréquentes : un plugin de "vitesse" applique le lazy loading à toutes les images de la page, y compris celle dont le navigateur a besoin en premier.
Nous détaillons cela dans notre checklist images Core Web Vitals et notre guide de conversion WebP. Erdo Image Optimizer gère automatiquement la conversion de format et la correction du lazy loading, en utilisant la bibliothèque GD ou Imagick de votre propre serveur — sans API externe ni quota mensuel.
2. Éliminez le CSS et le JavaScript bloquant le rendu
Chaque <script> et <link rel="stylesheet"> dans votre <head> sans async, defer ou une media query bloque le rendu de la page jusqu'à son téléchargement et (pour les scripts) son exécution. Les constructeurs de pages et thèmes multi-usages sont des coupables fréquents ici, chargeant souvent une bibliothèque d'icônes ou un framework d'animation complet, même sur des pages qui ne les utilisent pas.
La solution n'est pas toujours "supprimer le plugin" — souvent, il suffit de différer les scripts non critiques et d'intégrer en ligne le peu de CSS nécessaire au premier écran. La plupart des plugins de cache et de performance ont un réglage pour cela ; testez soigneusement après activation, car un report agressif peut occasionnellement casser un script dépendant de l'ordre de chargement.
3. Activez le cache côté serveur et navigateur
Une page qui doit être reconstruite par PHP et MySQL à chaque requête ajoute plusieurs centaines de millisecondes au Time to First Byte (TTFB), ce qui retarde tout ce qui suit, y compris le LCP. Le cache de page (servir un fichier HTML statique pré-généré aux visiteurs récurrents) et le cache d'objets (éviter les requêtes de base de données répétées) sont tous deux utiles, et la plupart des plugins de cache configurent les deux avec des valeurs par défaut raisonnables.
Cette étape compte, mais c'est rarement le principal facteur de score — une page bien mise en cache avec une image hero non compressée de 2 Mo échouera quand même au LCP.
4. Auditez le nombre et la qualité des plugins
Le nombre de plugins en soi n'est pas intrinsèquement un problème de performance — un plugin bien codé qui ne charge ses ressources que là où c'est nécessaire coûte très peu. Le vrai problème vient des plugins qui chargent du CSS/JS sur tout le site, que la page actuelle les utilise ou non. Dix plugins légers et bien délimités posent moins de problèmes que deux plugins mal codés.
Un audit pratique : ouvrez Chrome DevTools → onglet Network, rechargez une page lente et triez par taille. Tout ce qui est étonnamment volumineux mérite une investigation — remontez jusqu'au plugin ou composant de thème qui le charge.
Référence rapide : seuils des Core Web Vitals
| Métrique | Bon | À améliorer | Faible |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Sous 2,5s | 2,5s – 4s | Plus de 4s |
| INP (Interaction to Next Paint) | Sous 200ms | 200ms – 500ms | Plus de 500ms |
| CLS (Cumulative Layout Shift) | Sous 0,1 | 0,1 – 0,25 | Plus de 0,25 |
Ce sont les seuils publiés par Google, mesurés au 75e percentile des visites réelles — ce qui signifie que trois de vos visiteurs sur quatre doivent se situer dans la plage "Bon" pour que la métrique passe.
Un exemple chiffré
Lors d'un audit récent d'une boutique WooCommerce à la configuration assez typique (constructeur de pages, 3 plugins marketing, photographie produit non optimisée), voici la répartition avant/après avoir traité les images et les scripts bloquant le rendu :
| Changement | LCP avant | LCP après |
|---|---|---|
| Conversion des images hero + produit en WebP | 4,8s | 3,6s |
| Correction des dimensions d'images trop grandes | 3,6s | 2,9s |
Suppression de loading="lazy" sur l'image hero |
2,9s | 2,1s |
Aucun de ces trois changements n'a touché à l'hébergement, à la configuration du cache ou au code du thème — ils ont fait passer le LCP de "faible" à "bon" uniquement grâce au traitement des images. C'est cohérent avec ce que nous observons dans la plupart des audits WordPress : les images sont le premier endroit à vérifier, pas le dernier.
L'erreur à éviter
Un réflexe courant quand PageSpeed Insights affiche du rouge est de commencer à désactiver les plugins un par un, en espérant trouver "le" coupable. C'est lent et souvent peu concluant, car le vrai goulot d'étranglement est fréquemment une seule image trop volumineuse, pas un plugin du tout. Regardez d'abord la section "Diagnostics" du rapport PageSpeed Insights — elle nomme l'élément LCP réel et liste les ressources précises qui bloquent le rendu, ce qui constitue un point de départ bien plus rapide que la désactivation par essais-erreurs.
Pour conclure
Un score PageSpeed Insights rouge sur WordPress donne l'impression de nécessiter une mise à niveau d'hébergement ou une refonte complète du thème, mais en pratique, la solution est presque toujours plus ciblée : passer les images dans un format moderne à la bonne taille, arrêter de bloquer le rendu avec des scripts inutiles, mettre en cache ce qui peut l'être, et élaguer les plugins qui chargent des ressources dont ils n'ont pas besoin. Traitez ces quatre points dans l'ordre et retestez après chacun — vous saurez généralement dès la première ou la deuxième étape quelle correction fait le vrai travail.
Si les images s'avèrent être votre plus gros problème (c'est souvent le cas), Erdo Image Optimizer automatise la conversion de format, les alertes de dimensions et l'audit du lazy loading décrits ci-dessus, transformant ainsi une vérification manuelle récurrente en une configuration unique.