Optimisez le délai de chargement de la ressource LCP

Ce guide fait partie du hub Largest Contentful Paint (LCP). Le délai de chargement de la ressource (Resource Load Delay) est souvent le principal facteur d'un mauvais score LCP, en particulier sur les sites SPA ! 

Optimiser le délai de chargement de la ressource LCP

Le Largest Contentful Paint (LCP) se divise en quatre sous-phases : TTFB, délai de chargement de la ressource, durée de chargement de la ressource et délai de rendu de l'élément. 

Astuce : si votre LCP est une image, il sera presque toujours moins bon que s'il s'agissait de texte. Vous devez suivre les types d'éléments LCP dans vos données RUM, sinon vous naviguez à vue.

Qu'est-ce que le délai de chargement de la ressource ?

Le délai de chargement de la ressource est le temps écoulé entre le TTFB et le moment où le navigateur lance le téléchargement de la ressource LCP. En clair, le navigateur devrait mettre en file d'attente la ressource LCP (l'image LCP par exemple)  le plus tôt possible. Si ce n'est pas le cas, c'est probablement parce que le navigateur ne la découvre pas immédiatement ou ne la juge pas assez prioritaire.

Une valeur élevée indique un problème d'architecture : le navigateur ne trouve pas l'URL de la ressource dans le payload HTML initial. Ce délai correspond au temps que met le navigateur à identifier la ressource LCP et à décider de la récupérer.

Il est également important de comprendre que ce délai intervient avant le chargement effectif de la ressource. C'est pourquoi il n'a aucun rapport avec les images responsives ou les nouveaux formats comme WebP ou AVIF.

Pour les éléments LCP textuels affichés avec une police système, ce délai est généralement nul car aucune ressource externe n'est requise. Les valeurs élevées concernent uniquement les éléments LCP qui dépendent d'une ressource réseau externe, comme une image ou une vidéo.

Comment le navigateur trouve-t-il l'élément LCP ?

Pour réduire le délai de chargement de la ressource, vous devez comprendre comment les navigateurs découvrent les ressources (ou du moins l'élément LCP). Les navigateurs utilisent deux mécanismes : une voie rapide et une voie lente. Vous devez d'abord vous assurer que l'élément LCP se trouve sur la « voie rapide ».

• Le parseur DOM (voie lente) : c'est le parseur principal du navigateur, et c'est un monstre. Il construit la page complète  en lisant l'HTML, les feuilles de style et en interagissant avec le JavaScript. C'est la voie lente car elle peut être ralentie et bloquée par le téléchargement et l'exécution d'autres fichiers, créant ainsi une chaîne de dépendances qui génère du retard.
• Le Preload Scanner (voie rapide) : le parseur DOM étant (relativement) lent, les navigateurs utilisent un second scanner ultra-rapide qui parcourt la page pour trouver les ressources téléchargeables sans jamais se laisser bloquer. S'il trouve des balises <script>, <link> ou des balises <img> sans lazy loading, il les met immédiatement en file d'attente de téléchargement, avant même l'analyse du CSS ou l'exécution du JavaScript. C'est la voie idéale pour toute ressource critique.

Toute la stratégie d'optimisation du délai de chargement de la ressource repose sur un principe unique : s'assurer que l'URL de la ressource LCP soit découvrable le plus tôt possible par le preload scanner.

Pour un élément LCP, cela implique deux choses :

1. S'assurer que le preload scanner puisse le trouver en utilisant une balise image classique qui ne possède pas l'attribut loading="lazy".
2. Veiller à ce que le preload scanner ne donne pas la priorité à trop de ressources moins importantes.

Pourquoi le délai de chargement est important pour les Core Web Vitals

Les développeurs débutants pensent souvent que le LCP est un problème de taille de fichier. Cela pousse les équipes à se focaliser sur la compression d'image, les formats d'image modernes et les images responsives. C'est une erreur. Notre propre recherche sur les Core Web Vitals montre que le principal goulot d'étranglement du LCP est le TTFB (48 %), suivi du délai de chargement (Load delay) qui représente 24 %, tandis que le temps de chargement (Load time) ne prend que 10 %, et enfin le délai de rendu (Render delay) qui s'élève à 17 %.

L'avantage, c'est que le délai de chargement est presque entièrement corrigible, alors que le TTFB existera toujours. Cela fait du délai de chargement l'élément ayant le plus fort potentiel d'optimisation.

Comment détecter le délai de chargement de la ressource

Pour corriger le délai de chargement de la ressource, vous devez d'abord le mesurer avec précision. Le flux de travail reste le même : vérifier avec CrUX, définir le problème avec les données d'utilisateurs réels (RUM), puis passer à Chrome DevTools pour une analyse approfondie.

Étape 1 : Vérifier avec CrUX

CrUX correspond aux field data publiques de Google, issues d'utilisateurs réels de Chrome éligibles. Elles offrent une vue glissante sur 28 jours de vos Core Web Vitals au 75e percentile. CrUX indique si un chiffre est bon ou mauvais, mais ne précise ni qui, ni quoi, ni pourquoi. Puisque Google s'appuie sur ces données, c'est votre meilleure source de vérité de départ.

Rendez-vous sur cruxvis.withgoogle.com, saisissez votre site web, accédez à « Loading Performance » et cliquez sur   « Largest Contentful Paint (LCP) image subparts ».

Étape 2 : Analyser les données de terrain (RUM)

Le RUM collecte les Core Web Vitals de tous vos utilisateurs réels et offre une vue beaucoup plus précise et détaillée. Il vous indique qui et quoi, segmenté comme vous le souhaitez (une mine d'informations), mais pas pourquoi.

Étape 3 : Diagnostiquer avec DevTools

Une fois que vos données RUM ont identifié la page cible et son élément LCP, utilisez Chrome DevTools pour en diagnostiquer la cause. L'objectif est de reproduire le problème et de mesurer les sous-parties du LCP pour obtenir une valeur précise du délai de chargement de la ressource. DevTools permet également d'effectuer une analyse du main thread pour identifier les tâches en cours d'exécution qui pourraient bloquer le rendu.

Guide étape par étape du panneau Performance de Chrome DevTools

Le panneau Performance de Chrome DevTools est un outil indispensable pour disséquer le LCP et quantifier le délai de chargement.

1. Configuration initiale :

• Ouvrez Chrome DevTools en faisant un clic droit sur la page et en sélectionnant « Inspecter », ou en utilisant le raccourci Ctrl+Shift+I (Windows/Linux) ou Cmd+Option+I (Mac).
• Accédez à l'onglet Performance.
• Assurez-vous que la case Web Vitals est cochée dans les paramètres de capture. Cela affichera les informations des Core Web Vitals sur la timeline de performance.
• Pour simuler des conditions réelles d'utilisation, appliquez un bridage CPU et réseau. Un ralentissement CPU « 4x » et un profil réseau « Fast 3G » ou « Slow 4G » sont de bons points de départ pour les tests sur mobile.

2. Enregistrer un profil de performance :

• Cliquez sur le bouton « Enregistrer et recharger la page » (l'icône de flèche circulaire) dans le panneau Performance. Cela lancera l'enregistrement, rechargera la page, puis l'arrêtera une fois la page entièrement chargée.

3. Analyse et interprétation :

• Piste Timings : dans la timeline principale, localisez la piste Timings. Vous y trouverez un marqueur nommé LCP. Survoler ce marqueur mettra en surbrillance l'élément LCP correspondant dans la capture d'écran du viewport principal et affichera le temps LCP total.
• Répartition du LCP par phase : cliquez sur le marqueur LCP dans la piste Timings. Dans l'onglet Summary en bas du panneau, vous trouverez une répartition détaillée du temps LCP. Elle indique explicitement la durée de chacune des quatre sous-parties, y compris le délai de chargement (Load delay), mesurée en millisecondes. Cette valeur est la mesure la plus directe et la plus précise du délai de chargement de la ressource pour ce chargement de page spécifique.
• Analyse du main thread : tout en examinant la timeline, observez la piste Main à la recherche de long tasks (blocs d'activité signalés par un triangle rouge). Si ces long tasks surviennent après le chargement de la ressource LCP mais avant le marqueur LCP, elles contribuent probablement au délai de rendu de l'élément (Element Render Delay), un problème connexe mais distinct.

Causes communes et solutions à fort impact

Un délai de chargement de la ressource élevé est dû à deux causes possibles : la ressource LCP est découverte trop tard, ou elle reçoit une priorité de récupération trop basse. Voici les erreurs d'architecture les plus fréquentes et leurs solutions.

Cause : LCP chargé via CSS

Le problème : le preload scanner n'analyse pas les fichiers CSS. Lorsque votre image LCP est définie avec la propriété CSS background-image, son URL est invisible pour ce scanner ultra-rapide. Le navigateur ne peut découvrir l'image qu'après avoir téléchargé le HTML, trouvé le lien vers le fichier CSS, téléchargé ce fichier CSS, construit le CSSOM, puis appliqué le style. Cette chaîne de dépendances provoque directement un délai de chargement de la ressource élevé. Pour en savoir plus sur ce comportement, consultez notre guide sur le chargement différé des images de fond.

La solution : la bonne pratique consiste à éviter d'utiliser background-image for any critical LCP element. Utilisez plutôt une balise <img> standard. Cela place l'URL de l'image directement dans le HTML, où le preload scanner peut la trouver immédiatement. Vous pouvez obtenir le même résultat visuel grâce au CSS.

Exemple d'implémentation :

Anti-pattern (à éviter) :

    <!-- CSS -->
   .hero {
      background-image: url('hero-image.jpg');
      height: 500px;
      width: 100%;
    }

    <!-- HTML -->
    <div class="hero"></div>
    

Bonne pratique (à faire) :

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Texte alternatif descriptif pour l'image hero"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Titre de la page</h1>
      </div>
    </div>

    <!-- CSS -->
   .hero-container {
      position: relative;
      height: 500px;
      width: 100%;
    }

   .hero-background-img {
      position: absolute;
      inset: 0; /* Équivalent à top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* Cette propriété imite background-size: cover */
      z-index: -1; /* Place l'image derrière le reste du contenu */
    }
    

Cette implémentation offre le même rendu visuel tout en rendant l'image LCP découvrable le plus tôt possible, ce qui réduit son délai de chargement au minimum.

Cause : Rendu côté client (Client-Side Rendering) et injection de JavaScript

Le problème : les applications qui utilisent des frameworks de rendu côté client (CSR) comme React ou Vue servent souvent une coquille HTML minimale. Le contenu réel, y compris la balise LCP <img>, n'est inséré dans le DOM par JavaScript qu'après le téléchargement, l'analyse et l'exécution de lourds bundles de framework. Ce processus masque la ressource LCP au preload scanner, ce qui crée une forte latence de découverte.

La solution : la solution la plus efficace consiste à déplacer le rendu initial du client vers le serveur.

• Rendu côté serveur (SSR) ou génération de site statique (SSG) : ces architectures génèrent l'HTML complet sur le serveur. Le navigateur reçoit un document complet contenant la balise <img> et son attribut src, ce qui rend la ressource LCP immédiatement découvrable par le preload scanner. C'est l'architecture indispensable pour toute page où la performance est critique.
• Optimisations propres aux frameworks : les frameworks modernes proposent également des optimisations intégrées. Par exemple, le composant <Image> de Next.js possède une propriété priority. L'activer (la définir à true) indique au framework d'ajouter automatiquement les attributs requis <link rel="preload"> et fetchpriority="high", garantissant que l'image soit découverte et récupérée avec la bonne priorité.

Cause : Utilisation de loading="lazy" sur l'image LCP

Le problème : c'est une erreur fréquente et très pénalisante. L'attribut loading="lazy" indique directement au navigateur de retarder la récupération de l'image jusqu'à ce qu'elle soit proche du viewport. Bien que ce soit la bonne optimisation pour les images situées sous la ligne de flottaison, l'appliquer à un élément LCP situé au-dessus est contre-productif. Le preload scanner du navigateur est conçu pour ignorer les images avec loading="lazy", ce qui garantit une découverte tardive et un délai de chargement de la ressource élevé.

La solution : cela demande de la rigueur.

• Supprimer loading="lazy" de l'image LCP : toute image susceptible d'être l'élément LCP ne doit pas porter l'attribut loading="lazy". Le comportement par défaut du navigateur est loading="eager", ce qui est le réglage approprié pour le contenu critique au-dessus de la ligne de flottaison. Omettre complètement l'attribut loading a le même effet.
• Auditer et configurer les outils tiers : vous devez également auditer les outils tiers. De nombreux CMS, comme WordPress, ainsi que divers plugins d'optimisation d'images appliquent automatiquement le lazy loading à toutes les images. Il est essentiel de configurer ces outils pour exclure l'image LCP de ce comportement, souvent en créant une règle d'exclusion pour la première ou les deux premières images de la page.

Cause : Structure HTML sous-optimale et documents volumineux

Le problème : le preload scanner parcourt le document HTML de haut en bas. Si des ressources non critiques mais gourmandes en bande passante (comme les icônes de l'en-tête ou les scripts de widget de chat) sont placées plus haut dans le <body> que l'élément LCP, elles sont découvertes et mises en file d'attente en premier. Cela consomme de la bande passante réseau au démarrage et peut retarder le téléchargement de la ressource LCP. Un document HTML volumineux pose également problème : si l'élément LCP ne se trouve pas dans le premier bloc de données reçu par le navigateur (environ 14 Ko), sa découverte est retardée d'au moins un aller-retour réseau.

La solution : optimiser la structure et la priorité du contenu au sein du code HTML.

• Réordonner l'HTML : dans la mesure du possible, assurez-vous que la balise <img> ou le bloc de texte de l'élément LCP apparaisse le plus tôt possible dans la balise <body>.
• Dé-prioriser les images non critiques : pour les images non essentielles qui doivent figurer tôt dans le code source HTML (comme les icônes d'un en-tête), appliquez loading="lazy". Cela indique au preload scanner de les ignorer, préservant ainsi la file d'attente de téléchargement pour l'élément LCP.
• Différer les scripts non essentiels : les scripts d'analyse, de publicité ou de widgets de réseaux sociaux sont rarement critiques pour le rendu initial. Déplacez leurs balises <script> à la fin du <body> ou utilisez l'attribut defer. Cela évite qu'ils ne bloquent le parseur ou n'entrent en concurrence avec la ressource LCP pour la bande passante réseau.

Priorisation avancée avec les Resource Hints

Une fois la ressource LCP découvrable dans l'HTML, vous pouvez utiliser des resource hints pour donner au navigateur des instructions plus explicites sur la façon de la récupérer. Ces indicateurs permettent un contrôle précis de la découverte et de la priorisation.

Forcer une découverte précoce avec <link rel="preload">

<link rel="preload"> n'est pas un simple hint (indice), c'est une directive. Il force le navigateur à télécharger une ressource avec une priorité élevée, même si le parseur principal ne peut pas encore la découvrir. Le placer dans le <head> de votre code HTML est le moyen le plus direct de résoudre les problèmes de découverte tardive pour les ressources comme les polices, les images de fond CSS ou les images LCP enfouies profondément dans le DOM. Pour des détails d'implémentation complets et des exemples, consultez notre guide dédié sur comment précharger l'image LCP.

Mécanisme

Lorsqu'un lien preload est placé dans le <head> du document HTML, le preload scanner l'identifie et met immédiatement la ressource spécifiée en file d'attente pour téléchargement. C'est idéal pour les ressources comme les polices chargées via @font-face dans une feuille de style externe, les images de fond CSS faisant office de LCP (bien qu'il soit préférable d'utiliser une balise <img>), ou une image LCP située profondément dans une structure DOM complexe.

Préchargement responsive

Un détail d'implémentation crucial est nécessaire lors du préchargement d'images responsives. Pour s'assurer que le navigateur précharge l'image à la bonne dimension pour le viewport de l'utilisateur et d'éviter un double téléchargement inutile, la balise <link rel="preload"> doit inclure les attributs imagesrcset et imagesizes qui correspondent parfaitement à ceux de la balise <img> associée.

Exemple de préchargement responsive :

<link rel="preload" as="image"
      href="lcp-image-large.jpg"
      imagesrcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
      imagesizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
      fetchpriority="high">

<img src="lcp-image-large.jpg"
     srcset="lcp-image-small.jpg 400w, lcp-image-medium.jpg 800w, lcp-image-large.jpg 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
     alt="Un texte alternatif descriptif"
     fetchpriority="high"
     width="1200" height="675">
    

Piège potentiel

Le préchargement résout le moment de la récupération (le délai et la durée de chargement) mais pas le moment de l'affichage. Si le main thread est bloqué par du JavaScript lourd ou du CSS render blocking à l'arrivée de l'image préchargée, celle-ci devra tout de même attendre d'être affichée, ce qui déplace le goulot d'étranglement du délai de chargement vers le délai de rendu de l'élément.

fetchpriority="high" et la file d'attente de priorité du navigateur

L'attribut fetchpriority est un hint qui signale l'importance relative du téléchargement d'une ressource. Il vous permet d'influer sur la priorité de cette ressource dans la file d'attente de téléchargement du navigateur.

Comment fonctionne la priorité du navigateur

Lorsque le navigateur découvre des ressources pendant le chargement d'une page, il attribue à chacune un niveau de priorité interne. Par défaut, les images situées dans le viewport commencent avec une priorité « basse » (Low) et sont ensuite reclassées en priorité « haute » (High) dès que le navigateur termine la mise en page (layout) et détermine qu'elles sont visibles. Cette mise à niveau nécessite que le navigateur télécharge et analyse d'abord le CSS, ce qui crée un délai. L'attribut fetchpriority="high" contourne entièrement ce processus en définissant l'image en priorité « haute » dès qu'elle est découverte. C'est particulièrement efficace pour les images LCP, car cela supprime le délai lié à la mise à niveau de priorité.

preload ou fetchpriority

Ces deux indicateurs répondent à des objectifs différents mais complémentaires. Le preload influe sur le moment où une ressource est découverte et ajoutée à la file d'attente. L'attribut fetchpriority influe sur son niveau de priorité une fois dans la file d'attente. Comprendre cette distinction est crucial : le préchargement résout le problème de découverte tardive, tandis que fetchpriority résout celui d'une priorité trop basse. Pour de nombreuses images LCP déjà présentes dans le code HTML, le seul attribut fetchpriority peut s'avérer suffisant. Pour un guide complet sur leurs interactions, consultez notre article sur la priorisation des ressources.

Bonne pratique pour le LCP

Pour l'image LCP, la stratégie optimale consiste à les utiliser ensemble. D'abord, garantissez une découverte précoce en plaçant la balise <img> au début de l'HTML ou en utilisant le preload. Ensuite, ajoutez fetchpriority="high" directement sur la balise <img> (et sur le lien de preload, si utilisé). Cette combinaison garantit que la ressource soit non seulement découverte tôt, mais qu'elle reçoive également la plus haute priorité possible pour l'emporter face aux autres ressources concurrentes, telles que les feuilles de style ou les polices.

Exemple :

<img src="lcp-image.jpg" fetchpriority="high" alt="Image hero critique">

Quand utiliser fetchpriority="low"

L'attribut fetchpriority ne sert pas uniquement à augmenter la priorité. Vous pouvez aussi utiliser fetchpriority="low" pour dé-prioriser les ressources non critiques qui entrent en concurrence de bande passante avec l'image LCP. Les candidats idéaux sont notamment les images situées au-dessus de la ligne de flottaison mais qui ne correspondent pas à l'élément LCP (comme les petites icônes ou les avatars dans l'en-tête), ainsi que les ressources préchargées nécessaires mais non urgentes. En abaissant explicitement la priorité de ces ressources concurrentes, vous libérez de la bande passante pour l'image LCP.

<!-- Image LCP : haute priorité -->
<img src="hero.jpg" fetchpriority="high" alt="Image hero" width="1200" height="600">

<!-- Image au-dessus de la ligne de flottaison non critique : basse priorité -->
<img src="avatar.jpg" fetchpriority="low" alt="Avatar de l'auteur" width="48" height="48">

Impact prouvé

Dans une étude de cas portant sur Google Flights, l'ajout de fetchpriority="high" à l'image de fond LCP a permis d'améliorer le temps LCP de 2,6 secondes à 1,9 seconde, soit un gain de 700 ms.

Optimiser les connexions tierces : preconnect et dns-prefetch

Le problème

Si votre ressource LCP est hébergée sur un domaine tiers, comme un CDN d'images ou un fournisseur de polices tel que Google Fonts, le navigateur doit établir une nouvelle connexion réseau avec ce domaine. Ce processus implique une résolution DNS, une négociation TCP (TCP handshake) et une négociation TLS, étapes qui doivent toutes se terminer avant le téléchargement du premier octet de la ressource. Ce temps d'établissement de la connexion contribue directement au délai de chargement de la ressource pour les ressources cross-origin.

Les solutions

• preconnect : cet indicateur demande au navigateur d'effectuer la configuration complète de la connexion (DNS, TCP et TLS) pour une origine tierce spécifiée en arrière-plan, à l'avance. Lorsque la ressource est réellement demandée, la connexion est déjà établie, ce qui élimine la latence de configuration. Cette technique est très efficace et recommandée pour les un ou deux domaines tiers les plus critiques qui hébergent des ressources LCP.
• dns-prefetch : il s'agit d'un indicateur plus léger qui n'effectue que la résolution DNS pour un domaine. Il permet de gagner moins de temps que le preconnect, mais bénéficie d'une compatibilité de navigateur plus large. Il s'avère utile en solution de repli (fallback) ou pour des domaines tiers moins critiques.

Bonne pratique d'implémentation

Pour garantir une compatibilité maximale, fournissez les deux indicateurs. Le navigateur utilisera le preconnect s'il est pris en charge et se rabattra sur le dns-prefetch dans le cas contraire. L'attribut crossorigin est indispensable pour les ressources récupérées via CORS, comme les polices.

<link rel="preconnect" href="https://my-image-cdn.com" crossorigin>
<link rel="dns-prefetch" href="https://my-image-cdn.com">

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>    

Tableau : Comparatif des Resource Hints pour l'optimisation du LCP

Pour éviter toute mauvaise utilisation et clarifier les rôles respectifs de ces puissants indicateurs, le tableau suivant en propose un résumé comparatif.

Stratégies globales et prospectives

Au-delà des resource hints, des choix architecturaux plus larges permettent de réduire encore davantage le délai de chargement de la ressource.

Le rôle d'un CDN moderne

Un réseau de diffusion de contenu (CDN) est une technologie fondamentale pour les performances web. Elle réduit de manière indirecte mais significative le délai de chargement de la ressource, surtout pour les ressources LCP.

• Réduire le surcoût de connexion : en répartissant les ressources sur un réseau mondial de serveurs, un CDN place le contenu géographiquement plus près de l'utilisateur. Cela réduit naturellement le temps de trajet aller-retour (RTT) requis pour la résolution DNS, le handshake TCP et la négociation TLS, qui sont tous des composants du temps d'établissement de la connexion. Pour une image LCP hébergée sur un CDN, cela diminue directement son délai de chargement.
• CDN d'images : les CDN d'images spécialisés offrent un double avantage. Ils apportent la proximité géographique d'un CDN standard tout en automatisant de nombreuses optimisations complexes qui réduisent la durée de chargement de la ressource (Resource Load Duration), telles que le redimensionnement d'image à la volée, la compression et la conversion vers des formats modernes comme AVIF et WebP.
• Protocoles avancés : de nombreux CDN modernes exploitent HTTP/3, qui s'appuie sur QUIC plutôt que sur TCP. HTTP/3 réduit le temps de configuration de la connexion et atténue le blocage en tête de ligne (head-of-line blocking), ce qui permet une livraison globale des ressources plus rapide et plus efficace.

Éliminer complètement le délai grâce aux Speculation Rules

L'API Speculation Rules peut éliminer totalement le délai du LCP pour les navigations suivantes.

Mécanisme

Cette API permet aux développeurs d'indiquer de manière déclarative au navigateur les URL vers lesquelles l'utilisateur est susceptible de naviguer ensuite. Sur la base de ces règles, le navigateur peut choisir de pré-rendre (prerender) la page cible dans un onglet d'arrière-plan masqué avant même que l'utilisateur ne clique sur le lien.

Impact sur le LCP

Lorsque l'utilisateur clique sur le lien d'une page ayant fait l'objet d'un pré-rendu (prerendered), la navigation est quasi instantanée. La page a déjà été entièrement chargée et rendue en arrière-plan. Pour cette navigation, le TTFB, le délai de chargement de la ressource, la durée de chargement de la ressource et le délai de rendu de l'élément sont tous ramenés à près de zéro du point de vue de l'utilisateur.

Exemple de cas d'usage

Sur une page de catégorie e-commerce, les speculation rules peuvent servir à pré-rendre les pages de détails des premiers produits de la liste. Quand un utilisateur clique sur l'un de ces produits, la page s'affiche instantanément.

Synthèse d'études de cas : de la théorie à la pratique

Ces optimisations ont un impact concret et mesurable.

• Cas 1 : Le pouvoir de transformation du préchargement : une expérience menée par DebugBear sur une page présentant un délai de chargement élevé en fournit un exemple frappant. L'image LCP était masquée dans une chaîne de requêtes, ce qui faisait que le délai de chargement de la ressource représentait le chiffre impressionnant de 75 % du temps LCP total. En implémentant un simple indicateur <link rel="preload"> pour rendre l'image découvrable plus tôt, le délai de chargement de la ressource a été ramené à seulement 2 % du temps LCP. Cela montre comment un correctif architectural simple peut résoudre un goulot d'étranglement de performance massif.
• Cas 2 : L'anti-pattern loading="lazy" en conditions réelles : un développeur sur Stack Overflow a signalé un LCP sur ordinateur présentant un délai de chargement déconcertant de 1 430 ms malgré un réseau rapide. La cause venait d'un plugin d'optimisation d'images qui appliquait à tort le lazy loading à l'image LCP en remplaçant son attribut src par un SVG de remplacement (placeholder) transparent. La solution définitive a consisté à désactiver ce comportement pour l'élément LCP, lui permettant d'être découvert et chargé de manière active (eager). Cela montre comment les outils tiers peuvent involontairement introduire de lourds délais de chargement.
• Cas 3 : Le gain de performance grâce à fetchpriority : l'étude de cas de Google Flights fournit une preuve claire de l'impact d'une priorisation explicite. En ajoutant simplement fetchpriority="high" à l'image de fond LCP de la page, le score LCP a été amélioré de 700 ms, passant de 2,6 secondes à 1,9 seconde. Cela démontre que même lorsqu'une ressource est découvrable, signaler sa haute importance au navigateur est une étape clé pour remporter la course à la bande passante réseau.

Inspection réseau dans Chrome DevTools : utilisez le raccourci Ctrl + Shift + I pour ouvrir les outils de développement de Chrome, puis sélectionnez l'onglet « Network » (Réseau) et rechargez la page. Observez la séquence de chargement. Votre ressource LCP devrait figurer parmi les premiers éléments mis en file d'attente pour le téléchargement. Si elle est devancée par d'autres éléments, il y a un problème de délai de chargement de la ressource. Vous trouverez ci-dessous l'exemple d'un site sur lequel le délai de chargement de la ressource n'a pas été optimisé.

Utiliser des données de RUM (Real User Monitoring) : les outils de Real User Monitoring enregistrent souvent des données d'attribution du LCP. Grâce au RUM, vous pouvez visualiser la répartition des sous-parties du LCP (au fil du temps ou par page), ce qui vous donne une image claire du délai de chargement pour les éléments LCP sur l'ensemble de votre site ou par page. L'exemple ci-dessous montre une répartition globale du LCP accompagnée du délai de chargement correspondant.

Comment améliorer le délai de chargement

Un délai de chargement de la ressource survient lorsque l'ordre et le moment du téléchargement des ressources ne sont pas optimaux. Il existe, en substance, deux manières directes d'y remédier : prioriser la ressource LCP ou dé-prioriser les ressources non-LCP. Explorons quelques approches courantes :

Astuce LCP : comprendre le Preload Scanner : les navigateurs modernes utilisent un mécanisme appelé preload scanner, qui parcourt rapidement le HTML et met en file d'attente les ressources à télécharger. Si une ressource ne peut pas être mise en file d'attente par le preload scanner, elle devra attendre le parseur DOM, plus lent, ce qui génère des délais. S'assurer que vos ressources LCP soient découvrables par le preload scanner peut faire une grande différence dans la réduction du délai de chargement.

1. Optimiser la structure HTML

Le navigateur (ou le preload scanner) traite votre HTML de haut en bas, en mettant les ressources en file d'attente dans leur ordre d'apparition. Cela signifie que plus la ressource LCP apparaît haut dans le code HTML, plus elle est mise en file d'attente tôt. Pour optimiser cela, supprimez ou différez les ressources inutiles en haut du HTML :

• Utiliser le lazy loading pour les images non importantes ou masquées : parfois, des images (par exemple les drapeaux pour les versions linguistiques de votre site ou les images du menu) se trouvent tout en haut du code HTML. Ces images sont loin d'être aussi importantes que l'élément LCP. En appliquant le lazy loading à ces images, elles sont ignorées par le preload scanner et mises en file d'attente un peu plus tard dans le processus de chargement.
• Déplacer les scripts secondaires en bas de page : déplacez les scripts qui ne sont absolument pas indispensables pour le chargement initial en bas de page afin d'éviter qu'ils ne retardent les ressources critiques. C'est le cas, par exemple, d'un widget de chat. Personne dans l'histoire d'Internet n'a jamais eu besoin de chatter avant que la page ne soit visible !

2. Éviter les images de fond

Les images de fond sont invisibles pour le preload scanner, ce qui signifie qu'elles seront toujours mises en file d'attente par le parseur DOM, beaucoup plus lent. Pour éviter ce délai, utilisez plutôt une balise <img> classique, combinée à la propriété CSS object-fit: cover pour imiter l'apparence d'une image de fond. De cette façon, le preload scanner peut détecter et mettre l'image en file d'attente immédiatement.

3. Utiliser Fetch Priority

Ajoutez l'attribut fetchpriority="high" à votre élément LCP pour indiquer au navigateur qu'il doit prioriser cette ressource dès le départ. Normalement, les images se chargent avec une priorité par défaut basse ou moyenne. Pendant la phase de mise en page (layout), le navigateur met à niveau les éléments visibles vers une priorité élevée. En définissant fetchpriority="high", le téléchargement commence immédiatement à une priorité élevée, assurant un LCP plus rapide.

Fetchpriority est généralement moins intrusif (et moins efficace) que le preloading car il définit la priorité relative d'un élément (dans ce cas, l'image est relativement plus importante que les autres images) mais ne la rend pas plus importante que, par exemple, les feuilles de style ou les scripts non bloquants.

<img src="hero-image.jpg" alt="Image hero" fetchpriority="high">

4. Implémenter le préchargement

Le préchargement modifie l'ordre dans lequel le preload scanner met les fichiers en file d'attente. Placez la balise <link rel="preload"> dans le head de la page pour demander au navigateur de récupérer les ressources critiques, comme l'image LCP, le plus tôt possible. Les preloads peuvent être utilisés pour précharger des ressources référencées plus tard dans l'HTML (et donc mises en file d'attente plus tard) ou même des ressources qui ne sont pas encore référencées dans l'HTML (comme c'est le cas pour certains sliders). Pour une efficacité maximale, il est recommandé de placer les preloads après les feuilles de style et avant les scripts dans le head de la page.

<link rel="preload" as="image" href="hero-image.jpg">

5. Optimiser les styles

Les feuilles de style sont normalement mises en file d'attente avant la ressource LCP, et ce pour une bonne raison. Sans feuilles de style, le navigateur ne sait pas comment afficher la page et ne peut pas démarrer la phase de rendu. Cependant, un CSS trop volumineux et un nombre excessif de feuilles de style entreront en concurrence avec la ressource LCP pour la bande passante initiale.

6. Implémenter un lazy loading efficace

L'attribut loading peut être une arme à double tranchant. Utilisez loading="eager" (ou omettez simplement l'attribut, car « eager » est le comportement par défaut du navigateur) pour votre ressource LCP, tout en appliquant loading="lazy" pour les images hors écran (offscreen).

• Charger l'élément LCP en mode eager (immédiat) : si l'élément LCP fait l'objet d'un lazy loading, il ne sera pas mis en file d'attente par le preload scanner et se chargera beaucoup plus tard, ce qui nuira aux performances.
• Appliquer le lazy loading aux images du viewport : pour les images qui se trouvent dans le viewport visible mais ne sont pas des ressources LCP, utilisez loading="lazy" pour les mettre en file d'attente de téléchargement un peu plus tard. Cela réduit la concurrence de bande passante avec la ressource LCP.
• Éviter le lazy loading des images hors écran : les images qui ne sont pas dans le viewport visible ne déclencheront pas de téléchargement du tout, éliminant ainsi toute concurrence de bande passante.

7. Caching du navigateur

Le caching du navigateur permet d'éviter les requêtes réseau pour les ressources déjà stockées localement sur l'appareil de l'utilisateur. Bien qu'il n'accélère pas la première consultation de la page, il améliore les temps de chargement lors des visites suivantes et pour les visiteurs récurrents. Voici comment le caching du navigateur aide à réduire le délai de chargement de la ressource :

• Mettre en cache les ressources concurrentes : bien que la mise en cache de la ressource LCP elle-même soit une excellente stratégie, le caching du navigateur améliore les délais de chargement de la ressource LCP en stockant les ressources réseau qui pourraient entrer en concurrence avec elle ou la retarder, telles que les scripts, les feuilles de style et les images.
• Réduire la charge du serveur : le caching diminue le nombre de requêtes envoyées à votre serveur, ce qui peut améliorer la livraison des autres ressources en libérant de la bande passante et en réduisant l'utilisation du processeur du serveur.

8. Utiliser les Speculation Rules

Les Speculation Rules permettent aux navigateurs de précharger (prefetch) ou de pré-rendre (prerender) des pages web en fonction de la navigation prévue de l'utilisateur. Le prefetching élimine efficacement la sous-partie TTFB (Time to First Byte) du LCP et n'a aucun impact sur le délai de chargement de la ressource. Le prerendering génère la page suivante dans un onglet masqué et télécharge toutes les ressources de la page. Cela élimine tous les délais de chargement pour l'élément LCP, comme le montre cet exemple de répartition du LCP d'une page ayant fait l'objet d'un pré-rendu.

9. Éviter le rendu côté client (Client-Side Rendering)

Prochaines étapes : continuer à optimiser le LCP

Le délai de chargement de la ressource est l'une des quatre phases du LCP. Une fois la latence de découverte réduite, poursuivez avec ces guides :

• Identifier et corriger les problèmes de LCP : la méthodologie de diagnostic complète pour identifier et corriger tous les problèmes de LCP.
• Optimiser l'image LCP : choix du format d'image, images responsives, préchargement et erreurs d'image courantes.
• Durée de chargement de la ressource : après la découverte de la ressource par le navigateur, réduisez son temps de téléchargement grâce à la compression, aux formats modernes et à l'optimisation CDN.
• Délai de rendu de l'élément : après le téléchargement de la ressource, assurez-vous que le navigateur puisse l'afficher immédiatement en libérant le main thread.