Pourquoi le LCP est la métrique qui pénalise vraiment le classement
Parmi les trois Core Web Vitals — LCP, INP et CLS —, le Largest Contentful Paint est celui que la plupart des sites WordPress ratent, et celui le plus directement lié à une cause unique : les images.
Le LCP mesure le temps nécessaire pour que le plus grand élément visible de la page s'affiche. Sur la grande majorité des sites WordPress — blogs, pages produit, portfolios d'agences — cet élément est une image : une bannière hero, une image mise en avant, une photo produit au-dessus de la ligne de flottaison.
Si votre score LCP est rouge dans PageSpeed Insights ou Search Console, il y a de fortes chances que la solution ne soit pas un nouvel hébergeur ou un plugin de cache. C'est l'image elle-même.
La checklist
Suivez ces étapes dans l'ordre. Chacune cible une façon précise dont les images ralentissent le LCP.
1. Identifiez votre élément LCP réel
Avant de corriger quoi que ce soit, confirmez ce qui est réellement mesuré. Ouvrez Chrome DevTools → onglet Performance → enregistrez un chargement de page → repérez le marqueur « LCP » dans la timeline. Il pointera vers l'élément exact.
Vous pouvez aussi passer la page dans PageSpeed Insights — le rapport nomme directement l'élément LCP sous « Diagnostics ».
Ne devinez pas. Optimiser la mauvaise image fait perdre du temps sans améliorer le score.
2. Vérifiez le format de fichier
JPEG et PNG sont des formats des années 1990 encore servis sur bien trop de sites. À qualité équivalente, le WebP est environ 25 à 35 % plus léger que le JPEG, et l'AVIF va plus loin encore — souvent 50 % plus léger que le JPEG.
Si votre image LCP est encore un JPEG ou un PNG brut, c'est presque toujours la correction la plus efficace disponible. Consultez notre guide complet de conversion des images WordPress en WebP pour les détails techniques — en résumé, Erdo Image Optimizer le fait automatiquement, en utilisant la bibliothèque GD ou Imagick de votre propre serveur, sans clé API.
3. Vérifiez les dimensions réellement affichées
Une photo de 4000×3000px affichée dans un conteneur hero de 800px de large gaspille environ 90 % des octets téléchargés. Le navigateur doit télécharger le fichier complet avant de pouvoir le redimensionner.
Vérifiez cela en faisant un clic droit sur l'image → Inspecter → comparez la taille naturelle à la width/height rendue dans les styles calculés. Si la taille naturelle dépasse environ 1,5 fois la taille rendue, l'image a besoin d'être redimensionnée — pas seulement compressée.
4. Définissez des attributs width et height explicites
L'absence d'attributs width/height ne nuit pas directement au LCP, mais elle nuit au CLS (la métrique de décalage de mise en page), et une page dont la mise en page se décale pendant le chargement retarde souvent aussi la mesure du LCP. Chaque balise <img> devrait avoir des dimensions explicites pour que le navigateur puisse réserver l'espace avant le téléchargement du fichier.
5. Ne mettez jamais en lazy loading le candidat LCP
C'est l'erreur la plus fréquente que nous observons : un plugin « performance » ajoute loading="lazy" à toutes les images de la page, y compris l'image hero. Le lazy loading indique au navigateur d'attendre que l'image soit proche du viewport avant de la récupérer — exactement l'inverse de ce qu'il faut pour l'image qui déterminé votre score LCP.
La solution : les images au-dessus de la ligne de flottaison doivent se charger immédiatement (sans attribut loading="lazy", ou explicitement avec loading="eager"), idéalement avec fetchpriority="high". Seules les images sous la ligne de flottaison doivent être en lazy loading.
6. Préchargez l'image LCP si elle n'est pas la première chose que voit le navigateur
Si votre image LCP est chargée via un background-image CSS, ou cachée dans un slider/carrousel que JavaScript rend après le chargement de la page, le navigateur ne la découvre que tardivement dans le processus de chargement. Ajouter une balise <link rel="preload" as="image"> pour cette image précise dans le <head> indique au navigateur de la récupérer immédiatement, en parallèle de tout le reste.
7. Vérifiez le temps de réponse serveur pour l'image elle-même
Une image WebP correctement dimensionnée et au bon format ne se chargera toujours pas rapidement si elle est servie depuis une origine non optimisée sans en-têtes de cache. Vérifiez que vos images sont servies avec une longue durée de cache (Cache-Control: max-age=31536000 pour les ressources statiques) et envisagez un CDN si vous avez un trafic significatif depuis plusieurs régions.
8. Retestez après chaque changement
Ne regroupez pas les huit étapes pour ne tester qu'une seule fois à la fin. Corrigez le format, retestez. Corrigez les dimensions, retestez. Cela vous indique quel changement a réellement fait bouger le score — utile quand plusieurs choses sont en cause en même temps sur un site.
Faire cela à grande échelle
Auditer manuellement chaque image d'un site de 50 pages n'est pas réaliste. C'est exactement le vide que comble l'audit SEO intégré d'Erdo Image Optimizer — il scanne chaque image de votre site et signale les fichiers trop lourds, les attributs de lazy loading manquants (et l'erreur inverse — le lazy loading appliqué à des images au-dessus de la ligne de flottaison), les mauvais formats et le texte alternatif manquant, tout dans un seul rapport.
Combiné à la conversion automatique en WebP/AVIF lors de l'upload, l'essentiel de cette checklist devient une configuration ponctuelle plutôt qu'un audit manuel récurrent.
En résumé
Les problèmes de LCP donnent l'impression d'être un problème d'hébergement ou de cache parce que c'est ce que suppose la plupart des conseils génériques « accélérez votre site ». En pratique, sur un site WordPress typique, la solution est presque toujours : servir le bon format, à la bonne taille, avec la bonne priorité de chargement. Parcourez la checklist ci-dessus avant de passer à un hébergeur plus coûteux ou à une couche de cache côté serveur — le problème ne se situe généralement pas là.