Pour améliorer Largest Contentful Paint, identifiez l’élément qui détermine LCP et mesurez ce qui retarde son apparition. Pour une image, séparez l’attente du HTML, le délai avant la requête, le téléchargement et l’attente restante avant affichage. Corrigez ensuite la phase réellement lente au lieu d’appliquer simultanément toutes les optimisations d’images.
Un LCP est bon lorsqu’il ne dépasse pas 2,5 secondes au 75e centile. Cet objectif décrit un résultat pour les visiteurs. Il n’indique pas si le problème vient du serveur, d’une photo découverte tardivement ou d’un contenu déjà téléchargé mais caché jusqu’à la fin de JavaScript.
Trouvez l’élément avant de modifier sa livraison
Enregistrez un chargement dans Chrome DevTools à la taille de fenêtre pertinente. Examinez l’événement LCP et l’élément associé. Comparez avec le contenu visible de l’enregistrement : le navigateur peut retenir un candidat plus grand à mesure que le chargement avance.
Les candidats comprennent images et blocs de texte, avec des règles supplémentaires pour les fonds et les vidéos. LCP n’est pas simplement le plus grand nœud DOM ou la dernière requête. Un grand conteneur vide ne devient pas un contenu significatif par ses seules dimensions.
Répétez l’examen sur les modèles et appareils pertinents. Un titre peut déterminer LCP sur mobile, une photo de produit sur ordinateur. Une expérimentation ou le consentement peuvent également changer ce qui est visible. Notez les conditions avec l’élément pour rejouer le même scénario.
Dans un projet utilisant la version d’attribution de web-vitals, ce module de diagnostic journalise l’URL de l’image et les durées disponibles.
import { onLCP } from 'web-vitals/attribution';
onLCP(({ value, attribution }) => {
console.table({
lcp: value,
resource: attribution.url ?? 'Text or no image resource',
ttfb: attribution.timeToFirstByte,
loadDelay: attribution.resourceLoadDelay,
loadDuration: attribution.resourceLoadDuration,
renderDelay: attribution.elementRenderDelay
});
});Il s’agit d’une aide à l’observation, pas d’un service complet de surveillance. Le paquet compatible doit être installé et les imports résolus par la compilation. La collecte réelle exige aussi un point de réception et une agrégation soigneusement conçus. Vérifiez la version et son interface d’attribution lors de l’intégration.
Utilisez les quatre phases pour choisir le premier correctif
Le guide d’optimisation LCP de Google décompose le LCP fondé sur une image selon les traitements concernés. Un LCP textuel peut ne comporter aucun téléchargement d’image : n’en inventez pas pour faire correspondre le cas au modèle.
| Phase | Question de diagnostic | Investigation probable |
|---|---|---|
| Time to First Byte | Quand le navigateur reçoit-il le HTML ? | Redirections, origine et cache |
| Délai de chargement de la ressource | Quand la requête d’image peut-elle commencer ? | HTML initial, découverte CSS et priorité |
| Durée de chargement de la ressource | Combien de temps dure le transfert ? | Dimensions, encodage et livraison |
| Délai de rendu de l’élément | Pourquoi le contenu reçu reste-t-il invisible ? | CSS, polices, thread principal et états cachés |
Une modification utile raccourcit tout le parcours jusqu’au contenu visible. Si l’image termine plus tôt mais attend la même longue tâche de rendu, le téléchargement diminue tandis que le délai de rendu augmente. Le LCP final change peu. C’est un diagnostic précis, pas une preuve que la compression serait inutile.
Conservez la trace initiale. La comparaison doit montrer la phase modifiée et confirmer que le même élément détermine encore LCP. Si le candidat change, examinez cette transition plutôt que de comparer sans explication des ressources différentes.
Réduisez l’attente avant l’arrivée du HTML
Le navigateur ne découvre les ressources documentaires ordinaires qu’après réception d’une quantité suffisante de HTML. Suivez navigation, redirections, connexion et réponse finale. Une chaîne de redirections retarde la découverte même si l’application est rapide.
Comparez les réponses avec et sans cache. Un accueil déjà stocké peut masquer l’exécution lente de pages moins populaires. Vérifiez si le CDN conserve le HTML ou uniquement les fichiers statiques et si des cookies contournent involontairement le cache public.
Ne rendez pas publiques des pages personnelles pour améliorer un temps. Le cache doit préserver sessions, autorisations et exactitude du contenu. Le guide du temps de réponse serveur explique comment distinguer ces contraintes et mesurer le travail évité par un succès du cache.
Le rendu serveur demande aussi du contexte. Fournir du HTML utile réduit le travail de découverte côté client, mais une chaîne de rendu coûteuse augmente TTFB. Mesurez réponse et affichage final. Une structure vide rapide n’est pas l’objectif.
Rendez l’image importante immédiatement découvrable
Une URL d’image dans le HTML initial est accessible au mécanisme de découverte du navigateur. Une image créée après JavaScript hérite de cette dépendance. Un fond CSS peut attendre l’arrivée et le traitement de la feuille de style avant que son URL soit découverte.
Préférez un élément image normal pour un contenu significatif lorsque conception et sémantique le permettent. Donnez-lui des dimensions et un texte alternatif précis. N’ajoutez pas loading="lazy" à l’image de la première fenêtre uniquement parce que les autres médias utilisent le chargement différé.
Cet exemple suppose une image affichée jusqu’à 960 pixels CSS, avec un affichage mobile plus étroit. Les fichiers cités sont des ressources illustratives que votre compilation doit fournir.
<img
src="/images/guide-960.webp"
srcset="/images/guide-640.webp 640w,
/images/guide-960.webp 960w,
/images/guide-1600.webp 1600w"
sizes="(max-width: 960px) 100vw, 960px"
width="1600"
height="900"
fetchpriority="high"
alt="A browser displaying a highlighted content panel"
>Le navigateur choisit selon sizes, les largeurs candidates et l’appareil. sizes décrit la disposition réelle ; il ne fixe pas la largeur CSS. Déclarer une largeur de fenêtre complète pour une image occupant une demi-colonne peut entraîner un transfert inutilement important.
fetchpriority="high" signale une requête particulièrement importante. Il ne rend pas découvrable une ressource cachée. L’appliquer à de nombreuses images concurrentes affaiblit l’intention de priorité. Commencez par le candidat LCP mesuré, puis examinez la cascade.
Préchargez uniquement pour résoudre une découverte tardive
Le préchargement convient à une ressource critique qui serait sinon découverte trop tard. Il ne demande pas de récupérer tous les éléments visibles avant que le navigateur organise leur chargement.
Pour un fond CSS réellement critique, le préchargement d’image peut lancer la requête avant sa découverte dans la feuille de style. Ces deux éléments utilisent la même URL afin de réutiliser la requête prévue.
<link rel="preload" as="image" href="/images/banner.webp"
fetchpriority="high">.banner {
min-height: 18rem;
background-image: url('/images/banner.webp');
background-size: cover;
background-position: center;
}Les dimensions sont des choix de conception, pas des seuils de performance. Utilisez plutôt un élément image sémantique si le visuel transmet une information nécessitant un texte alternatif.
Les images adaptatives demandent une sélection cohérente dans le préchargement. Une URL fixe peut gaspiller de la bande passante si l’élément choisit un autre candidat. Vérifiez URL, types de ressources et comportement des identifiants, sans supposer que deux références proches constituent un seul transfert.
Après ajout d’une indication, vérifiez que la requête utile commence avant et qu’elle ne déplace pas un autre travail critique. Un avertissement de préchargement inutilisé doit conduire à examiner l’implémentation, pas à masquer le message.
Réduisez les octets sans dégrader le contenu
Une fois la découverte correctement placée, examinez les dimensions sélectionnées et le volume transféré. Exportez des variantes adaptées à l’emplacement et à la densité de pixels souhaitée. Un écran dense peut légitimement exiger plus de pixels d’image que de pixels CSS ; les deux nombres ne doivent pas toujours être identiques.
Comparez formats et compression sur l’image réelle. AVIF ou WebP peuvent convenir, mais contenu, qualité nécessaire et encodage influencent le résultat. Texte fin, diagrammes et photos ne réagissent pas forcément de la même façon.
Contrôlez l’image à sa taille d’affichage. Des détails de produit flous, des lettres endommagées ou des artefacts ne deviennent pas acceptables parce que le fichier est plus petit. Conservez l’original et des réglages reproductibles pour éviter qu’une édition ultérieure annule l’optimisation.
Un CDN d’images ou une chaîne de transformation du CMS peut automatiser les variantes. Vérifiez néanmoins le balisage produit et la requête sélectionnée. Une fonction dite adaptative ne prouve pas que sizes correspond au thème. Consultez le guide d’optimisation des images pour les formats et le balisage.
Utilisez le calculateur d’économies sur les images pour comparer les octets. Il estime un gain de transfert à partir de vos données, pas des millisecondes de LCP. Chargements parallèles, cache et autres phases restent déterminants.
Examinez l’intervalle entre téléchargement et affichage
Si l’image est reçue mais apparaît bien plus tard, cherchez ce qui bloque le rendu. Des styles peuvent manquer, JavaScript peut occuper le thread principal ou une animation, une initialisation ou un état client peut garder le composant caché.
Supprimez les dépendances de visibilité inutiles. Une image essentielle ne devrait pas attendre une logique de carrousel indépendante si sa première diapositive tient dans du HTML ordinaire. Vérifiez les écrans de chargement couvrant du contenu prêt et les animations d’entrée retardant la mesure sans aider le visiteur.
Examinez soigneusement le CSS bloquant. Le but n’est ni de supprimer toutes les feuilles ni de différer tous les styles. La première fenêtre nécessite des règles correctes pour éviter clignotements et déplacements. Isolez les ressources inutilisées ou secondaires tout en conservant les styles indispensables.
Le thread principal peut retarder le rendu après la fin du réseau. Cherchez gros scripts, hydratation et initialisation synchrone autour du moment concerné. Le guide des ressources bloquant le rendu distingue les dépendances de découverte et d’exécution souvent confondues.
Pour un LCP textuel, étudiez les polices et la visibilité. Une requête de police peut affecter l’apparition du titre, et les métriques de remplacement le layout. Précharger toutes les polices n’est pas automatiquement la solution : elles concurrencent parfois des ressources plus urgentes.
Testez les variantes mobiles et éditoriales réellement servies
Testez un titre long et un court, un article avec image principale et un sans. Incluez les états réels de consentement, publicité et langue lorsqu’ils modifient la disposition. Le même code peut produire des candidats LCP différents selon le contenu.
Une fenêtre étroite peut masquer ou recadrer l’image de bureau alors qu’elle est encore téléchargée à cause d’un désaccord entre HTML et CSS. À l’inverse, une image mobile peut être demandée trop tard si un script la choisit après le démarrage. Examinez les requêtes, pas seulement la page finale.
Sur les versions localisées, couverture des polices et retours à la ligne peuvent modifier candidat et dépendances. Appliquez le même diagnostic dans chaque langue, sans considérer un progrès en anglais comme preuve pour toutes les éditions.
Vérifiez une hypothèse avec un enregistrement comparable
Écrivez l’hypothèse avant modification : par exemple, un composant insère l’image LCP après initialisation, d’où sa découverte tardive. Faites le plus petit changement qui teste cette explication, puis rejouez le même scénario.
Comparez début de requête, fin de transfert, affichage et LCP complet. Gardez mêmes fenêtre, limitation des ressources et cache. Conservez essais échoués et erreurs visibles : une fonction importante qui ne charge plus peut donner un faux progrès.
Après déploiement, examinez les utilisateurs réels sur leur fenêtre de collecte. Le LCP de terrain peut différer à cause du matériel, des connexions, des régions et des navigations. Le progrès de laboratoire est utile, mais ne remplace pas le résultat réel.
Rendez le résultat durable
Documentez l’élément important, son mode de découverte et l’optimisation intentionnelle. Une courte note peut empêcher un plugin de rétablir le chargement différé ou une refonte de changer l’emplacement sans adapter sizes.
Conservez dans la routine de vérification une page représentative, le candidat attendu, son parcours de découverte et une trace sauvegardée. Les guides de référence Core Web Vitals aident lorsqu’une autre métrique devient limitante. La prochaine tâche doit venir du prochain délai mesuré, pas d’un nouveau réglage générique.
