Optimisez le délai de chargement de la ressource LCP

Ce guide fait partie du hub Largest Contentful Paint (LCP). Le Resource Load Delay est souvent la cause principale d'un mauvais score LCP, surtout sur les sites SPA ! 

Optimisez le Resource Load Delay du LCP

Le Largest Contentful Paint (LCP) compte quatre sous-phases : TTFB, Resource Load Delay, Resource Load Duration, et Element Render Delay. 

Un conseil rapide : si votre LCP est une image, il sera presque toujours pire que s'il s'agit de texte. Vous devez suivre les types d'éléments LCP dans vos données RUM, sinon vous naviguez à l'aveugle.

Qu'est-ce que le Resource Load Delay ?

Le Resource Load Delay est le temps écoulé entre le TTFB et le moment où le navigateur lance le téléchargement de la ressource LCP. En principe, un navigateur doit mettre en file d'attente une ressource LCP (l'image LCP par exemple)  dès que possible. Si elle n'est pas mise en file d'attente immédiatement, c'est très probablement parce que le navigateur ne peut pas la découvrir tout de suite ou ne la considère pas comme suffisamment importante.

Une valeur élevée ici indique un problème d'architecture (où le navigateur ne trouve pas l'URL de la ressource dans le payload HTML initial). Ce Resource Load Delay correspond au temps passé par le navigateur à identifier que la ressource LCP est nécessaire et à décider de la récupérer.

Il faut également comprendre que le Resource Load Delay se produit avant le chargement effectif de la ressource. C'est pourquoi il n'a rien à voir avec les images responsive ou les nouveaux formats d'image comme le WebP ou l'AVIF.

Pour les éléments LCP basés sur du texte et rendus avec une police système, ce Resource Load Delay est généralement de zéro car aucune ressource externe ne doit être récupérée. Les valeurs élevées de Resource Load Delay sont spécifiques aux éléments LCP qui dépendent d'une ressource réseau externe comme une image ou un fichier vidéo.

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

Pour réduire le Resource Load Delay, 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 dans la voie rapide.

• L'analyseur DOM (Voie lente) : C'est l'analyseur principal du navigateur et c'est un monstre. Il construit la page complète  en lisant le HTML, les feuilles de style et en interagissant avec le JavaScript. C'est la voie lente car elle peut être retardée et interrompue par d'autres fichiers qui se téléchargent et s'exécutent en premier. Cela crée une chaîne de dépendances qui introduit du retard.
• Le preload scanner (Voie rapide) : Comme l'analyseur DOM est (relativement) lent, les navigateurs disposent d'un second scanner ultra-rapide. Il scanne la page très rapidement pour trouver les ressources téléchargeables et rien ne l'arrêtera.  S'il trouve des balises <script>, <link> ou des <img> sans lazy loading, il les place immédiatement en file d'attente pour le téléchargement. Cela se fait avant l'analyse du CSS ou l'exécution du JavaScript. C'est la voie optimale pour toute ressource critique.

Toute la stratégie d'optimisation du Resource Load Delay repose sur un seul principe : assurez-vous que le preload scanner puisse découvrir l'URL de la ressource LCP le plus tôt possible.

Cela implique 2 choses pour un élément LCP :

1. Assurez-vous que le preload scanner puisse le trouver en utilisant une balise image classique qui ne possède pas l'attribut loading="lazy".
2. Assurez-vous que le preload scanner ne priorise pas trop de ressources moins importantes.

Pourquoi le Load Delay compte pour les Core Web Vitals

Les développeurs débutants pensent souvent que le LCP est un problème de « poids de fichier ». Cela pousse les équipes à se concentrer sur la compression des images, les formats modernes et les images responsive. C'est une erreur. Notre propre recherche sur les Core Web Vitals montre que le plus gros goulot d'étranglement du LCP est le TTFB (48 %), suivi par le Load Delay (24 %). Le temps de chargement ne représente que 10 %, suivi par le Render Delay à 17 %.

La subtilité est que le Load Delay peut être presque entièrement corrigé, tandis que le TTFB existera toujours. Cela fait du Load Delay l'élément avec le plus fort potentiel d'optimisation.

Comment détecter le Resource Load Delay

Pour corriger le Resource Load Delay, vous devez d'abord le mesurer précisément. Le workflow est toujours le même : vérifiez avec CrUX pour définir le problème avec des données d'utilisateurs réels (RUM), puis passez aux Chrome DevTools pour une analyse approfondie.

Étape 1 : Vérifiez avec CrUX.

CrUX correspond aux field data d'utilisateurs réels rendus publics par Google. Ces données proviennent d'utilisateurs Chrome éligibles. Elles fournissent une vue glissante sur 28 jours de vos Core Web Vitals au 75e centile. Elles vous disent si un chiffre est bon ou mauvais, mais pas qui, quoi ou pourquoi. Puisque Google s'appuie sur les données CrUX, c'est votre meilleure source de vérité pour commencer.

Allez sur cruxvis.withgoogle.com, entrez votre site web, naviguez vers Loading Performance et cliquez sur  Largest Contentful Paint (LCP) image subparts

Étape 2 : Analysez les field data (RUM)

Le RUM collecte les Core Web Vitals de tous vos utilisateurs réels. Il vous donne une vue beaucoup plus spécifique et détaillée. Il vous dit qui et quoi, segmenté comme vous le souhaitez (et cette information vaut de l'or), mais il ne vous dit pas pourquoi.

Cette capture d'écran de CoreDash vous indique par exemple quelles URL souffrent de Resource Load Delay (en vert).

Étape 3 : Diagnostiquez avec les DevTools

Une fois que vos données RUM ont identifié une page cible et un élément LCP, utilisez les Chrome DevTools pour 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 Resource Load Delay. C'est également dans les DevTools que vous effectuez l'analyse du main thread pour voir exactement quelles tâches s'exécutent et bloquent potentiellement le rendu.

Guide étape par étape : nous avons rédigé un tutoriel complet sur ce workflow : Diagnostiquez le LCP avec le panneau Performance des Chrome DevTools. Il couvre la configuration du throttling, l'enregistrement d'une trace et la lecture de la valeur exacte du Resource Load Delay depuis l'insight de décomposition du LCP.

Causes communes et solutions à fort impact

Un Resource Load Delay élevé a deux causes possibles : la ressource LCP est découverte tardivement, ou on lui a attribué une faible priorité de récupération. Voici les erreurs architecturales les plus courantes 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 un background-image en CSS, 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 du fichier CSS, téléchargé le fichier CSS, construit le CSSOM, puis appliqué le style. Cette chaîne de dépendances cause directement un Resource Load Delay élevé. Pour en savoir plus sur ce motif, consultez notre guide sur le report des images d'arrière-plan.

La solution : L'implémentation correcte consiste à éviter d'utiliser background-image pour tout élément LCP critique. 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 avec du CSS.

Exemple d'implémentation :

Anti-pattern (À ne pas faire) :

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

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

Bonne pratique (Faites plutôt ceci) :

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="A descriptive alt text for the hero image"
        fetchpriority="high"
        class="hero-background-img"
        width="1200"
        height="500"
      />
      <div class="hero-content">
        <h1>Page Title</h1>
      </div>
    </div>

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

   .hero-background-img {
      position: absolute;
      inset: 0; /* Equivalent to top: 0; right: 0; bottom: 0; left: 0; */
      width: 100%;
      height: 100%;
      object-fit: cover; /* This property mimics background-size: cover */
      z-index: -1; /* Places the image behind other content */
    }
    

Cette implémentation offre le même résultat visuel mais rend l'image LCP découvrable le plus tôt possible, ce qui minimise son Load Delay.

Cause : Rendu côté client et injection JavaScript

Le problème : Les applications utilisant des frameworks avec rendu côté client (CSR) comme React ou Vue servent souvent une coquille HTML minimale. Le contenu réel, dont 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 des gros bundles du framework. Ce processus masque fondamentalement la ressource LCP au preload scanner. Cela 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.

• Server-Side Rendering (SSR) ou Static Site Generation (SSG) : Les architectures comme le SSR ou le SSG génèrent le HTML complet sur le serveur. Le navigateur reçoit un document complet contenant la balise <img> et son attribut src. La ressource LCP est immédiatement découvrable par le preload scanner. C'est l'architecture requise pour toute page dont la performance est critique.
• Optimisations spécifiques aux frameworks : Les frameworks modernes fournissent des optimisations intégrées. Par exemple, le composant <Image> de Next.js possède une propriété priority. Si vous la définissez sur true, le framework ajoute automatiquement les bons attributs <link rel="preload"> et fetchpriority="high". Cela garantit que l'image est 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 à fort impact. L'attribut loading="lazy" donne au navigateur l'ordre direct de retarder la récupération d'une image jusqu'à ce qu'elle soit proche du viewport. C'est la bonne optimisation pour les images sous la ligne de flottaison, mais l'appliquer à un élément LCP au-dessus de la ligne de flottaison 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 Resource Load Delay élevé.

La solution : La solution demande de la rigueur.

• Retirez loading="lazy" de l'image LCP : Toute image susceptible d'être l'élément LCP ne doit pas avoir l'attribut loading="lazy". Le comportement par défaut du navigateur est loading="eager". C'est le réglage correct pour le contenu critique au-dessus de la ligne de flottaison. Omettre complètement l'attribut loading a le même effet.
• Auditez et configurez les outils tiers : Vous devez également auditer vos outils tiers. De nombreux CMS comme WordPress et 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. Cela implique souvent de créer une règle d'exclusion pour la ou les deux premières images de la page.

Cause : Structure HTML sous-optimale et documents volumineux

Le problème : Le preload scanner traite le document HTML de haut en bas. Si des ressources non critiques mais gourmandes en bande passante, comme des icônes d'en-tête ou des scripts 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 la bande passante réseau initiale et peut retarder le téléchargement de la ressource LCP. Un document HTML volumineux peut également poser problème. Si l'élément LCP ne figure 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 : Optimisez la structure et la priorité du contenu dans le HTML.

• Réorganisez le 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é-priorisez les images non critiques : Pour les images non essentielles qui doivent apparaître 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. Vous préservez ainsi la file d'attente pour l'élément LCP.
• Reportez les scripts non essentiels : Les scripts d'analytics, de publicités ou 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 les empêche de bloquer l'analyseur ou d'entrer 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 le 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 hints offrent un contrôle fin sur la découverte et la priorisation.

Forcer la découverte anticipée avec <link rel="preload">

<link rel="preload"> n'est pas un hint ; c'est une directive. Il force le navigateur à télécharger une ressource avec une priorité élevée, même si l'analyseur principal ne l'a pas encore découverte. Le placer dans le <head> de votre HTML est le moyen le plus direct de corriger les problèmes de découverte tardive pour des ressources comme les polices, les images d'arrière-plan CSS, ou les images LCP enfouies profondément dans le DOM. Pour des détails complets d'implémentation 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 le téléchargement. C'est idéal pour des ressources comme les polices chargées via @font-face dans une feuille de style externe, les LCP en background-image CSS (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 critique est nécessaire lors du préchargement d'images responsive. Pour garantir que le navigateur précharge l'image à la bonne taille pour le viewport de l'utilisateur et éviter un double téléchargement inutile, la balise <link rel="preload"> doit inclure les attributs imagesrcset et imagesizes. Ces attributs doivent refléter parfaitement ceux de la balise <img> correspondante.

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="A descriptive alt text"
     fetchpriority="high"
     width="1200" height="675">
    

Piège potentiel

Le préchargement résout le timing de récupération (Load Delay et Load Duration) mais pas le timing d'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, l'image devra toujours attendre pour être affichée. Cela peut déplacer le goulot d'étranglement du Load Delay vers l'Element Render Delay.

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'influencer la priorité d'une 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 de la page, il attribue à chacune un niveau de priorité interne. Par défaut, les images dans le viewport commencent à la priorité « Low » et passent ensuite à « High » une fois que le navigateur termine la mise en page et détermine qu'elles sont visibles. Cette mise à niveau exige que le navigateur télécharge et analyse d'abord le CSS, ce qui crée un retard. L'attribut fetchpriority="high" contourne entièrement ce processus en définissant l'image à la priorité « High » dès le moment de sa découverte. C'est particulièrement percutant pour les images LCP car cela élimine le délai de mise à niveau de la priorité.

preload vs. fetchpriority

Ces deux hints ont des rôles différents mais complémentaires. preload affecte le moment où une ressource est découverte et ajoutée à la file d'attente. fetchpriority affecte son niveau de priorité une fois qu'elle est dans la file d'attente. Comprendre cette distinction est critique : preload résout la découverte tardive, tandis que fetchpriority résout la faible priorisation. Pour de nombreuses images LCP déjà présentes dans le HTML, fetchpriority seul peut suffire. Pour un guide complet sur la façon dont ils interagissent, 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 anticipée en plaçant la balise <img> tôt dans le HTML ou en utilisant preload. Ensuite, ajoutez fetchpriority="high" directement sur la balise <img> (et sur le lien preload, s'il est utilisé). Cette combinaison garantit que la ressource est non seulement découverte tôt, mais qu'elle reçoit également la priorité la plus élevée possible. Elle remporte ainsi la compétition pour la bande passante réseau contre d'autres ressources comme les feuilles de style ou les polices.

Exemple :

<img src="lcp-image.jpg" fetchpriority="high" alt="A critical hero image">

Quand utiliser fetchpriority="low"

L'attribut fetchpriority ne sert pas qu'à augmenter la priorité. Vous pouvez aussi utiliser fetchpriority="low" pour dé-prioriser les ressources non critiques qui concurrencent l'image LCP pour la bande passante. Les candidats courants incluent les images au-dessus de la ligne de flottaison qui ne sont pas l'élément LCP (comme les petites icônes ou les avatars dans l'en-tête), et 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.

<!-- LCP image: high priority -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image" width="1200" height="600">

<!-- Non-critical above-fold image: low priority -->
<img src="avatar.jpg" fetchpriority="low" alt="Author avatar" width="48" height="48">

Impact prouvé

Dans une étude de cas sur Google Flights, l'ajout de fetchpriority="high" à l'image d'arrière-plan LCP a amélioré le temps LCP de 2,6 secondes à 1,9 seconde, soit une amélioration de 700 ms.

Optimisation des connexions tierces : preconnect et dns-prefetch

Le problème

Si votre ressource LCP est hébergée sur un domaine tiers, tel qu'un CDN d'images ou un fournisseur de polices comme Google Fonts, le navigateur doit établir une nouvelle connexion réseau vers ce domaine. Ce processus implique une recherche DNS, un handshake TCP et une négociation TLS. Tout cela doit se terminer avant le téléchargement du premier octet de la ressource. Ce temps d'établissement de connexion contribue directement au Resource Load Delay pour les assets cross-origin.

Les solutions

• preconnect : Ce hint indique 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à chaude, ce qui élimine la latence de configuration. C'est très efficace. Nous le recommandons pour le ou les deux domaines tiers les plus critiques qui servent des ressources LCP.
• dns-prefetch : C'est un hint plus léger qui n'effectue que la recherche DNS pour un domaine. Il fait gagner moins de temps que preconnect, mais il bénéficie d'un support navigateur plus large. Il est utile comme fallback ou pour des domaines tiers moins critiques.

Bonne pratique d'implémentation

Pour garantir une compatibilité maximale, fournissez les deux hints. Le navigateur utilisera preconnect s'il est pris en charge, et se rabattra sur dns-prefetch sinon. L'attribut crossorigin est essentiel 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 : Comparaison des resource hints pour l'optimisation du LCP

Pour éviter les erreurs d'utilisation et clarifier les rôles distincts de ces hints puissants, le tableau suivant fournit un résumé comparatif.

Stratégies holistiques et tournées vers l'avenir

Au-delà des resource hints, des décisions architecturales plus larges peuvent réduire encore davantage le Resource Load Delay.

Le rôle d'un CDN moderne

Un Content Delivery Network (CDN) est une technologie fondatrice de la web performance. Il réduit indirectement mais significativement le Resource Load Delay, en particulier pour les ressources LCP.

• Réduction de la surcharge de connexion : En distribuant les assets sur un réseau mondial de serveurs, un CDN place le contenu géographiquement plus près de l'utilisateur. Cela réduit de manière inhérente le round-trip time (RTT) requis pour la recherche DNS, le handshake TCP et la négociation TLS. Ce sont tous des composants du temps de configuration de la connexion. Pour une image LCP hébergée sur un CDN, cela réduit directement son Load Delay.
• CDN d'images : Les CDN spécialisés en images offrent un double avantage. Ils fournissent l'avantage de proximité d'un CDN standard tout en automatisant de nombreuses optimisations complexes qui réduisent la Resource Load Duration. C'est le cas du redimensionnement d'image à la volée, de la compression et de la conversion vers des formats modernes comme l'AVIF et le WebP.
• Protocoles avancés : De nombreux CDN modernes utilisent HTTP/3, qui s'appuie sur QUIC au lieu de TCP. HTTP/3 réduit le temps de configuration de la connexion et atténue le head-of-line blocking. Cela conduit à une distribution des ressources globalement plus rapide et plus efficace.

Éliminer totalement le délai avec les Speculation Rules

La Speculation Rules API peut éliminer entièrement le délai du LCP pour les navigations ultérieures.

Mécanisme

Cette API permet aux développeurs d'informer le navigateur de manière déclarative sur les URL vers lesquelles un utilisateur naviguera probablement ensuite. En fonction de ces règles, le navigateur peut choisir de préréaliser le rendu (prerender) d'une page cible dans un onglet masqué en arrière-plan. Il le fait avant même que l'utilisateur ne clique sur le lien.

Impact sur le LCP

Lorsque l'utilisateur clique sur un lien vers une page pré-rendue, la navigation est virtuellement instantanée. La page a déjà été entièrement chargée et rendue en arrière-plan. Pour cette navigation, le TTFB, le Resource Load Delay, la Resource Load Duration et l'Element Render Delay sont tous effectivement réduits à presque zéro du point de vue de l'utilisateur.

Exemple de cas d'usage

Sur une page de catégorie e-commerce, des Speculation Rules pourraient être utilisées pour pré-rendre les pages de détails produits des premiers articles de la liste. Lorsqu'un utilisateur clique sur l'un de ces produits, la page apparaît instantanément.

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

Ces optimisations ont un impact mesurable dans le monde réel.

• Cas 1 : Le pouvoir transformateur du préchargement : Une expérience menée par DebugBear sur une page avec un Load Delay élevé fournit un exemple frappant. L'image LCP était cachée dans une chaîne de requêtes. Le Resource Load Delay représentait un pourcentage astronomique de 75 % du temps LCP total. En implémentant un simple hint <link rel="preload"> pour rendre l'image découvrable tôt, le Resource Load Delay a été réduit à seulement 2 % du temps LCP. Cela démontre comment une correction architecturale simple peut résoudre un goulot d'étranglement de performance massif.
• Cas 2 : L'anti-pattern loading="lazy" dans la réalité : Un développeur sur Stack Overflow a signalé un LCP sur desktop avec un Load Delay déconcertant de 1 430 ms malgré un réseau rapide. La cause a été tracée jusqu'à un plugin d'optimisation d'image. Il appliquait à tort le lazy loading à l'image LCP en remplaçant son attribut src par un SVG de substitution transparent. La solution définitive a consisté à désactiver ce comportement pour l'élément LCP. Cela a permis sa découverte et son chargement anticipé (eager). Cela illustre comment les outils tiers peuvent introduire par inadvertance de sévères Load Delays.
• Cas 3 : Le boost de performance de fetchpriority : L'étude de cas de Google Flights fournit une preuve évidente de l'impact d'une priorisation explicite. En ajoutant simplement fetchpriority="high" à l'image d'arrière-plan LCP de la page, le score LCP s'est 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 critique pour remporter la course à la bande passante réseau.

Inspection réseau dans les Chrome DevTools : Utilisez le raccourci Ctrl + Maj + I pour ouvrir les outils de développement de Chrome, puis sélectionnez l'onglet « Network » et rechargez la page. Observez la séquence de chargement. Votre ressource LCP devrait être l'un des premiers éléments mis en file d'attente pour le téléchargement. Si elle est à la traîne derrière d'autres éléments, il y a un problème de Resource Load Delay. Vous trouverez ci-dessous un exemple de site où le Resource Load Delay n'a pas été optimisé.

Utilisez les données de Real User Monitoring (RUM) : Les outils de Real User Monitoring enregistrent souvent les données d'attribution du LCP. Avec le RUM, vous pouvez visualiser la décomposition des sous-parties du LCP (dans le temps ou par page). Cela vous donne une image claire du Load Delay des éléments LCP sur l'ensemble de votre site ou par page. L'exemple ci-dessous montre une décomposition globale du LCP avec le Load Delay correspondant.

Comment améliorer le Load Delay

Un Resource Load Delay se produit lorsque l'ordre et le timing de téléchargement des ressources ne sont pas optimaux. Il existe fondamentalement deux moyens directs de corriger cela : priorisez la ressource LCP ou dé-priorisez les ressources non-LCP. Explorons quelques motifs courants :

Astuce LCP : Comprenez le preload scanner : Les navigateurs modernes utilisent un mécanisme appelé le preload scanner. Il scanne rapidement le HTML et met les ressources en file d'attente pour le téléchargement. Si une ressource ne peut pas être mise en file d'attente par le preload scanner, elle devra attendre l'analyseur DOM plus lent. Cela entraînera des retards. Veiller à ce que vos ressources LCP soient découvrables par le preload scanner peut faire une énorme différence pour réduire le Load Delay.

1. Optimisez 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 l'ordre où elles apparaissent. Cela signifie que plus la ressource LCP apparaît haut dans le HTML, plus vite elle est mise en file d'attente. Pour optimiser cela, supprimez ou reportez les ressources inutiles en haut du HTML :

• Appliquez le lazy loading aux images peu importantes ou cachées : Parfois, des images (par exemple, des drapeaux pour les versions linguistiques de votre site ou des images dans le menu) se trouvent tout en haut du HTML de votre site. 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 pendant le processus de chargement.
• Déplacez les scripts peu importants en bas de page : Déplacez les scripts absolument inutiles au chargement initial vers le bas de la page. Cela évite qu'ils ne retardent les ressources critiques. Par exemple, un widget de chat. Personne dans l'histoire de l'internet n'a jamais eu besoin de discuter avant que la page ne soit visible !

2. Évitez les images d'arrière-plan

Les images d'arrière-plan sont invisibles pour le preload scanner. Elles seront donc toujours mises en file d'attente par l'analyseur DOM beaucoup plus lent. Pour éviter ce retard, utilisez plutôt une balise <img> classique, combinée à la propriété CSS object-fit: cover pour imiter l'apparence d'une image d'arrière-plan. De cette façon, le preload scanner peut détecter et mettre l'image en file d'attente immédiatement.

3. Utilisez la Fetch Priority

Ajoutez l'attribut fetchpriority="high" à votre élément LCP. Cela indique au navigateur qu'il doit prioriser cette ressource dès le départ. Normalement, les images se chargent avec une priorité par défaut faible ou moyenne. Pendant la phase de layout, le navigateur fait passer les éléments visibles en priorité élevée. En définissant fetchpriority="high", le téléchargement commence immédiatement en priorité élevée. Cela garantit un LCP plus rapide.

La Fetch Priority est généralement moins intrusive (et moins efficace) que le préchargement. Elle 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="Hero Image" fetchpriority="high">

4. Implémentez 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. Cela ordonne 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 loin dans le HTML (et donc mises en file d'attente plus tard). Ils servent même à précharger des ressources qui ne sont pas encore référencées dans le HTML (comme 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. Optimisez 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 saura pas à quoi ressemblera la page et ne pourra pas démarrer la phase de rendu. Cependant, une taille excessive du CSS et un trop grand nombre de feuilles de style concurrenceront la ressource LCP pour la bande passante initiale.

6. Implémentez un lazy loading efficace

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

• Chargez l'élément LCP en mode Eager : Si l'élément LCP est en lazy loading, il ne sera pas mis en file d'attente par le preload scanner et se chargera beaucoup plus tard. Cela impactera négativement les performances.
• Appliquez le lazy loading aux images du viewport : Pour les images qui se trouvent dans le viewport visible mais qui ne sont pas des ressources LCP, utilisez loading="lazy". Cela les met en file d'attente pour un téléchargement légèrement différé. Cela réduit la concurrence pour la bande passante avec la ressource LCP.
• Évitez le lazy loading des images hors écran : Les images qui ne sont pas dans le viewport visible ne déclencheront aucun téléchargement, ce qui élimine complètement la concurrence pour la bande passante.

7. Mise en cache du navigateur

La mise en cache du navigateur vous permet d'ignorer les requêtes réseau pour les ressources qui ont déjà été stockées localement sur l'appareil de l'utilisateur. Bien qu'elle n'accélère pas la première vue de page, elle améliorera les temps de chargement pour les vues de page ultérieures et les visiteurs réguliers. Voici comment la mise en cache du navigateur aide à réduire le Resource Load Delay :

• Mettez en cache les ressources concurrentes : Bien que la mise en cache de la ressource LCP elle-même soit une excellente stratégie, la mise en cache du navigateur améliore le Resource Load Delay du LCP en stockant les ressources réseau qui pourraient concurrencer ou retarder la ressource LCP, comme les scripts, les feuilles de style et les images.
• Réduisez la charge du serveur : La mise en cache diminue le nombre de requêtes envoyées à votre serveur. Cela peut améliorer les performances d'autres ressources en libérant de la bande passante et en réduisant les cycles CPU du serveur.

8. Utilisez les Speculation Rules

Les Speculation Rules permettent aux navigateurs de pré-récupérer (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 du LCP et n'a aucun impact sur le Resource Load Delay. Le prerendering affiche la page suivante dans un onglet masqué et télécharge toutes les ressources de la page. Cela élimine tous les retards de chargement pour l'élément LCP, comme le montre cet exemple de décomposition du LCP d'une page pré-rendue.

9. Évitez le rendu côté client

Prochaines étapes : continuez à optimiser le LCP

Le Resource Load Delay est l'une des quatre phases du LCP. Une fois que vous avez minimisé la latence de découverte, poursuivez avec ces guides :

• Corrigez et identifiez les problèmes LCP : La méthodologie de diagnostic complète pour trouver et corriger tous les problèmes LCP.
• Optimisez l'image LCP : Choix du format d'image, images responsive, préchargement et erreurs d'image courantes.
• Resource Load Duration : 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.
• Element Render Delay : 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.