Identifiez d’abord l’image qui est réellement l’élément LCP
Largest Contentful Paint mesure le moment où le plus grand contenu pertinent de la zone visible est rendu. Si une image est l’élément LCP, le correctif doit viser la chaîne qui retarde cette ressource : découverte tardive, priorité faible, fichier trop lourd, réponse serveur lente ou rendu bloqué par d’autres dépendances.
Ne préchargez pas toutes les images et n’ajoutez pas `fetchpriority="high"` partout. Ces techniques servent à améliorer la priorité d’une ressource réellement critique ; les appliquer à de nombreuses images peut créer de la concurrence. Commencez par confirmer l’élément LCP avec vos outils de mesure.
Comparez les données de terrain et un test de laboratoire reproductible
Les données réelles permettent de voir si le LCP pose problème aux utilisateurs, tandis qu’un outil de laboratoire aide à analyser une page dans des conditions contrôlées. Le même élément n’est pas forcément LCP sur mobile et sur desktop : la taille de la fenêtre et le contenu visible peuvent changer le candidat.
Notez l’URL, le viewport, l’élément LCP, son URL de ressource et les principales étapes temporelles. Si l’image n’est pas toujours le LCP, évitez de généraliser une optimisation à tout le template sans vérifier les autres cas.
Rendez l’image LCP découvrable le plus tôt possible
Une image présente directement dans le HTML peut être découverte tôt par le navigateur. Une image chargée uniquement après l’exécution d’un script ou injectée comme ressource tardive peut attendre plusieurs étapes avant que la requête démarre. Cette attente réduit le temps disponible pour télécharger et afficher l’image.
Lorsque c’est possible, rendez la ressource critique détectable depuis le document initial. Pour les cas où cela n’est pas possible, un preload peut être pertinent, mais seulement après avoir confirmé que la découverte tardive est réellement le goulot. Sinon, vous ajoutez une priorité sans résoudre la cause principale.
Utilisez la priorité de chargement avec parcimonie
`fetchpriority="high"` peut aider le navigateur à prioriser une image LCP identifiée. Il ne doit pas devenir un attribut ajouté à toutes les images visibles. Plusieurs ressources marquées comme hautement prioritaires se concurrencent et rendent le signal moins utile. Conservez la priorité élevée pour les candidats réellement critiques.
Évitez aussi le lazy-loading sur une image qui doit être chargée immédiatement pour le LCP. Le chargement différé est utile pour les contenus hors écran, mais il est contre-productif lorsqu’il retarde précisément l’image principale que l’utilisateur attend au-dessus de la ligne de flottaison.
Réduisez le poids transféré sans dégrader inutilement la qualité
Une image correctement priorisée restera lente si elle est beaucoup plus grande que nécessaire. Servez des dimensions adaptées à l’affichage, utilisez des formats efficaces et compressez raisonnablement. Les images responsives permettent au navigateur de choisir une ressource adaptée au viewport plutôt que de télécharger systématiquement la plus grande version.
Vérifiez aussi les dimensions intrinsèques pour limiter les changements de mise en page. L’objectif n’est pas de rechercher le fichier le plus petit à tout prix mais un compromis stable entre qualité visuelle, résolution réellement nécessaire et coût de transfert.
N’oubliez pas le temps avant même que l’image puisse commencer à charger
Le LCP inclut des étapes qui dépendent de la réponse du document et de la chaîne critique. Si le serveur met longtemps à renvoyer le HTML, accélérer uniquement l’image ne peut pas récupérer tout le temps perdu. De même, un CSS ou un script bloquant peut retarder l’affichage final même si la ressource image arrive rapidement.
Analysez donc le délai avant la requête de l’image, la durée de téléchargement et le délai avant son rendu. Cette décomposition empêche de compresser encore un fichier déjà léger alors que le vrai problème est un TTFB élevé ou une découverte tardive.
Exemple : une hero image injectée après un script
Une page peut afficher une grande image de hero seulement après qu’un composant JavaScript a calculé le contenu. Le navigateur découvre alors la ressource tardivement. Le premier test consiste à voir si l’image peut être présente directement dans le HTML ou rendue côté serveur. Si ce n’est pas possible, un preload ciblé peut être évalué.
Après ce changement, vérifiez si la requête commence plus tôt et si le LCP baisse réellement. Si le téléchargement reste long, travaillez ensuite sur la taille et le format. Cette progression évite d’empiler plusieurs optimisations sans savoir laquelle a eu un effet.
Validez l’effet réel plutôt que la présence des optimisations
Après correction, répétez la mesure dans les mêmes conditions et observez ensuite les données de terrain lorsqu’elles sont disponibles. Une balise preload ou un attribut de priorité n’est pas une réussite en soi : le résultat attendu est une ressource critique découverte et affichée plus tôt sans ralentir d’autres éléments essentiels.
Limpi peut aider à relier problèmes techniques et contrôles de performance. Lancer un audit Limpi permet de repérer les ressources et signaux à examiner, tandis que notre méthode évite les recettes automatiques. Une optimisation LCP ne garantit ni classement ni valeur précise pour tous les utilisateurs.
Références utilisées pour cette page
Continuer à comprendre votre visibilité
À lire ensuite