Optimiser le Resource Load Delay du LCP

Ce guide fait partie du hub Largest Contentful Paint (LCP). Le Resource Load Delay est souvent le facteur qui contribue le plus à un mauvais score LCP. La plupart des équipes se concentrent sur la compression des images alors que le vrai problème est que le navigateur a trouvé l'image trop tard.

Optimiser le Resource Load Delay du LCP

Le Largest Contentful Paint (LCP) se compose de quatre phases : TTFB, Resource Load Delay, Resource Load Duration et Element Render Delay. Les efforts de développement se concentrent souvent sur la réduction du Load Duration via la compression des fichiers, mais cela néglige le Resource Load Delay, qui est souvent une source de latence plus importante. Ce délai avant le début du téléchargement peut ajouter des centaines de millisecondes à votre LCP, le faisant dépasser le seuil de 2,5 secondes pour être classé « Good ».

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

Définition précise : l'attente critique avant le téléchargement

Le Resource Load Delay est le temps entre le TTFB et le moment où le navigateur lance le téléchargement de la ressource LCP. Ce n'est pas le temps de téléchargement ; c'est la latence de découverte qui se produit avant que la requête ne commence. Une valeur élevée ici indique un problème architectural où le navigateur ne peut pas trouver l'URL de la ressource dans le payload HTML initial. Ce Resource Load Delay peut être considéré comme le temps que le navigateur passe à identifier que la ressource LCP est nécessaire et à décider de la récupérer.

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 nul car aucune ressource externe n'a besoin d'être récupérée. Des valeurs de Resource Load Delay plus élevées sont spécifiques aux éléments LCP qui dépendent d'une ressource réseau externe comme une image ou un fichier vidéo.

Le moteur de découverte : Preload Scanner vs. DOM Parser

Pour réduire le Resource Load Delay, vous devez comprendre comment les navigateurs découvrent les ressources. L'efficacité de ce processus de découverte est le facteur principal déterminant la latence. Les navigateurs utilisent deux mécanismes : un chemin rapide et un chemin lent.

• Le Preload Scanner (le chemin rapide) : C'est un parseur secondaire à haute vitesse qui scanne le HTML brut à la recherche d'URL de ressources, comme celles dans les balises <img> ou <link>. Il les met en file d'attente pour le téléchargement immédiatement, avant que le CSS ne soit analysé ou que JavaScript ne soit exécuté. C'est le chemin optimal pour toute ressource critique.
• Le DOM Parser (le chemin lent) : C'est le parseur principal qui construit le Document Object Model (DOM) complet et le CSS Object Model (CSSOM). Les ressources non trouvées dans le HTML initial, comme une CSS background-image ou un élément injecté par JavaScript, ne sont découvertes que par ce parseur. C'est le chemin lent car il dépend du téléchargement et de l'exécution préalables d'autres fichiers, créant une chaîne de dépendances qui introduit une latence élevée.

Toute la stratégie d'optimisation du Resource Load Delay repose sur un principe : s'assurer que l'URL de la ressource LCP est découvrable par le preload scanner. Tout pattern qui masque l'URL du document HTML initial force le navigateur à utiliser le chemin de découverte lent. Cette période d'attente se traduit directement en Resource Load Delay. Chaque optimisation efficace consiste à architecturer votre HTML pour placer la ressource LCP sur le chemin rapide. Pour un guide complet sur la priorisation des ressources par le navigateur, consultez notre article sur la priorisation des ressources.

Pourquoi le Load Delay est important

Une idée reçue courante est qu'un LCP lent est un problème de « taille de fichier ». Cela amène les équipes à se concentrer uniquement sur la compression d'images pour réduire le Resource Load Duration. Bien que l'optimisation des assets soit un facteur, l'analyse des données terrain réelles montre que pour de nombreux sites avec un mauvais LCP, le Resource Load Delay est le principal goulot d'étranglement des performances, pas le Resource Load Duration.

Les données terrain montrent que le site médian avec un mauvais score LCP a un Resource Load Delay de 1,3 seconde. Cela représente plus de la moitié du budget total de 2,5 secondes pour un score LCP « Good », entièrement consommé avant même que le téléchargement de la ressource LCP ne commence. Les données indiquent que ces sites passent près de quatre fois plus de temps à attendre le début du téléchargement que le téléchargement lui-même.

Ces données révèlent une mauvaise orientation fréquente des efforts de développement. Les équipes peuvent passer des semaines à retirer des kilo-octets des images pour raccourcir le Load Duration de quelques millisecondes, tandis qu'un problème architectural causant un Load Delay de 1,5 seconde reste non résolu. Le LCP est un processus séquentiel ; un retard dans une phase précoce ne peut pas être récupéré en optimisant une phase ultérieure. Si une requête est retardée de plus d'une seconde, une différence de 100 ms dans le temps de téléchargement est sans importance pour le score LCP final. Les optimisations à plus fort impact impliquent des changements architecturaux, comme l'amélioration de la découvrabilité des ressources, pas seulement la compression des assets. L'accent doit passer de rendre les assets plus petits à s'assurer qu'ils sont découverts plus tôt.

Comment détecter le Resource Load Delay

Pour corriger le Resource Load Delay, vous devez d'abord le mesurer avec précision. Le workflow professionnel consiste à d'abord définir le problème avec des données utilisateurs réelles (RUM), puis à passer à Chrome DevTools pour une analyse approfondie.

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

Les données terrain, ou Real User Monitoring (RUM), sont collectées à partir de sessions d'utilisateurs réels. Les outils RUM, comme le Chrome User Experience Report (CrUX) public ou mon propre outil, CoreDash, répondent à la question : que se passe-t-il dans le monde réel ? Un outil RUM complet fournira également une décomposition des sous-parties du LCP, vous montrant le Resource Load Delay médian parmi vos utilisateurs. Ces données valident qu'un problème de LCP existe, montrent quelles URL sont affectées et révèlent les éléments LCP courants que vos utilisateurs voient réellement. Vous devez commencer ici pour confirmer que vous résolvez un problème réel.

Étape 2 : Diagnostiquer avec DevTools

Une fois que vos données RUM ont identifié une page cible et un élément LCP, vous utilisez Chrome DevTools pour diagnostiquer la cause. L'objectif ici est de reproduire le problème et de mesurer les sous-parties du LCP pour obtenir une valeur précise du Resource Load Delay. DevTools est également l'endroit où vous effectuez une analyse du Main Thread pour voir exactement quelles tâches s'exécutent et bloquent potentiellement le processus de 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 Load Delay.

1. Configuration :

• 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).
• Naviguez vers l'onglet Performance.
• Assurez-vous que la case Web Vitals est cochée dans les paramètres de capture. Cela superposera les informations Core Web Vitals sur la timeline de performance.
• Pour simuler des conditions utilisateur réalistes, appliquez un throttling du CPU et du réseau. Un « ralentissement 4x » pour le CPU et un profil réseau « Fast 3G » ou « Slow 4G » sont des points de départ courants pour les tests mobile.

2. Enregistrement d'un profil de performance :

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

3. Analyse et interprétation :

• Piste Timings : Dans la vue principale de la timeline, localisez la piste Timings. Vous verrez un marqueur intitulé 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.
• Décomposition du LCP par phase : Cliquez sur le marqueur LCP dans la piste Timings. Dans l'onglet Summary en bas du panneau, vous trouverez une décomposition détaillée du timing LCP. Cette décomposition montre explicitement la durée de chacune des quatre sous-parties, y compris le Load delay, mesurée en millisecondes. Cette valeur est la mesure la plus directe et précise du Resource Load Delay pour ce chargement de page spécifique.
• Analyse du Main Thread : En examinant la timeline, regardez la piste Main pour les tâches longues (blocs d'activité signalés par un triangle rouge). Si ces tâches longues se produisent après que la ressource LCP a fini de se charger mais avant le marqueur LCP, elles contribuent probablement au Element Render Delay, un problème connexe mais distinct.

Causes courantes et solutions à fort impact

Un Resource Load Delay élevé est causé par l'une de ces deux choses : la ressource LCP est découverte tardivement, ou elle se voit attribuer 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 une CSS background-image, son URL est invisible pour ce scanner à haute vitesse. 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é 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 pattern, consultez notre guide sur le report des background images.

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 CSS.

Exemple d'implémentation :

Anti-Pattern (ne faites pas cela) :

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

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

Bonne pratique (faites plutôt cela) :

    <!-- HTML -->
    <div class="hero-container">
      <img
        src="hero-image.jpg"
        alt="Un texte alt 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; /* 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 au plus tôt, ce qui minimise son Load Delay.

Cause : Rendu côté client et injection JavaScript

Le problème : Les applications utilisant des frameworks de rendu côté client (CSR) comme React ou Vue servent souvent un shell HTML minimal. Le contenu réel, y compris la balise LCP <img>, n'est inséré dans le DOM que par JavaScript après que de gros bundles de framework ont été téléchargés, analysés et exécutés. Ce processus masque fondamentalement la ressource LCP du preload scanner, créant une latence de découverte élevée.

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

• Server-Side Rendering (SSR) ou Static Site Generation (SSG) : Les patterns architecturaux comme SSR ou SSG génèrent le HTML complet côté serveur. Le navigateur reçoit un document complet contenant la balise <img> et son attribut src, rendant la ressource LCP immédiatement découvrable par le preload scanner. C'est l'architecture requise pour toute page critique en termes de performances.
• Optimisations spécifiques aux frameworks : Les frameworks modernes fournissent également des optimisations intégrées. Par exemple, le composant <Image> de Next.js possède une propriété priority. La définir à true indique au framework d'ajouter automatiquement les attributs corrects <link rel="preload"> et fetchpriority="high", assurant 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" est une instruction directe au navigateur de retarder la récupération d'une image jusqu'à ce qu'elle soit proche du viewport. Bien que ce soit l'optimisation correcte pour les images sous la ligne de flottaison, 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 requiert de la rigueur.

• Supprimez 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", ce qui 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 les outils tiers. De nombreuses plateformes 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 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 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 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 pour le téléchargement 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 aussi poser problème ; si l'élément LCP n'est pas dans le premier bloc de données que le navigateur reçoit (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 : Quand c'est possible, assurez-vous que la balise <img> ou le bloc de texte pour l'élément LCP apparaît aussi tôt que 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 dans un en-tête), appliquez loading="lazy". Cela indique au preload scanner de les ignorer, préservant la file d'attente de téléchargement pour l'élément LCP.
• Différez les scripts non essentiels : Les scripts pour l'analytique, la publicité ou les 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 les empêche de bloquer le parseur ou de concurrencer la ressource LCP pour la bande passante réseau.

Priorisation avancée avec les Resource Hints

Une fois que la ressource LCP est découvrable dans le HTML, vous pouvez utiliser les 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 précoce avec <link rel="preload">

<link rel="preload"> n'est pas un hint ; c'est une directive. Elle force le navigateur à télécharger une ressource avec une haute priorité, même si elle n'est pas encore découvrable par le parseur principal. 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 CSS background images ou les images LCP situées profondément dans le DOM. Pour les 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 en file d'attente la ressource spécifiée pour le 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 LCP en CSS background-image (bien qu'utiliser une balise <img> soit préférable), ou une image LCP située profondément dans une structure DOM complexe.

Preloading responsive

Un détail d'implémentation critique est requis lors du préchargement d'images responsive. Pour s'assurer que le navigateur précharge l'image de la bonne taille pour le viewport de l'utilisateur et évite un double téléchargement inutile, la balise <link rel="preload"> doit inclure les attributs imagesrcset et imagesizes qui reflètent parfaitement les attributs de la balise <img> correspondante.

Exemple de preloading 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 alt descriptif"
     fetchpriority="high"
     width="1200" height="675">
    

Piège potentiel

Le preloading résout le timing de récupération (Load Delay et Load Duration) mais pas le timing de rendu. Si le main thread est bloqué par du JavaScript lourd ou du CSS bloquant le rendu lorsque l'image préchargée arrive, l'image devra quand même attendre pour être rendue, ce qui peut déplacer le goulot d'étranglement du Load Delay vers le Element Render Delay.

fetchpriority="high" et la file 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 à une priorité « Low » et sont ensuite promues à « High » une fois que le navigateur termine la mise en page et détermine qu'elles sont visibles. Cette promotion 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 à une priorité « High » dès le moment où elle est découverte. C'est particulièrement impactant pour les images LCP car cela élimine le délai de promotion de priorité.

preload vs. fetchpriority

Ces deux hints servent des objectifs 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 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à dans le HTML, fetchpriority seul peut suffire. Pour un guide complet sur leur interaction, consultez notre article sur la priorisation des ressources.

Bonne pratique pour le LCP

Pour l'image LCP, la stratégie optimale est de les utiliser ensemble. D'abord, assurez la découverte précoce soit en plaçant la balise <img> tôt dans le HTML, soit en utilisant preload. Ensuite, ajoutez fetchpriority="high" directement sur la balise <img> (et sur le lien preload, si utilisé). Cette combinaison garantit que la ressource est non seulement découverte tôt mais aussi reçoit la priorité la plus élevée possible pour gagner la compétition pour la bande passante réseau face aux autres ressources comme les feuilles de style ou les polices.

Exemple :

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

Quand utiliser fetchpriority="low"

L'attribut fetchpriority ne sert pas seulement à augmenter la priorité. Vous pouvez aussi utiliser fetchpriority="low" pour déprioriser les ressources non critiques qui rivalisent pour la bande passante avec l'image LCP. 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 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 créez plus de marge de bande passante pour l'image LCP.

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

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

Impact prouvé

Dans une étude de cas impliquant 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.

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 comme Google Fonts, le navigateur doit établir une nouvelle connexion réseau vers ce domaine. Ce processus implique une résolution DNS, un handshake TCP et une négociation TLS, qui doivent tous être terminés avant que le premier octet de la ressource puisse être téléchargé. Ce temps d'établissement de connexion est un contributeur direct au Resource Load Delay pour les assets cross-origin.

Les solutions

• preconnect : Ce hint indique au navigateur d'effectuer l'établissement complet de la connexion (DNS, TCP et TLS) pour une origine tierce spécifiée en arrière-plan, à l'avance. Lorsque la ressource est effectivement demandée, la connexion est déjà établie, éliminant la latence de configuration. C'est très efficace et recommandé pour les un ou 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 résolution DNS pour un domaine. Il fait gagner moins de temps que preconnect mais bénéficie d'un support navigateur plus large et est utile comme fallback ou pour les domaines tiers moins critiques.

Bonne pratique d'implémentation

Pour assurer une compatibilité maximale, fournissez les deux hints. Le navigateur utilisera preconnect s'il est supporté et se rabattra sur dns-prefetch dans le cas contraire. 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 LCP

Pour prévenir les mauvais usages 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 davantage le Resource Load Delay.

Le rôle d'un CDN moderne

Un Content Delivery Network (CDN) est une technologie fondamentale pour la performance web qui 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 à travers un réseau mondial de serveurs, un CDN place le contenu géographiquement plus près de l'utilisateur. Cela réduit intrinsèquement le temps d'aller-retour (RTT) requis pour la résolution DNS, le handshake TCP et la négociation TLS, qui sont tous des composantes du temps d'établissement de connexion. Pour une image LCP hébergée sur un CDN, cela réduit directement son Load Delay.
• CDN d'images : Les CDN d'images spécialisés offrent un double avantage. Ils fournissent l'avantage de proximité d'un CDN standard tout en automatisant de nombreuses optimisations complexes qui réduisent le Resource Load Duration, comme le redimensionnement d'images à la volée, la compression et la conversion vers des formats modernes comme AVIF et WebP.
• Protocoles avancés : De nombreux CDN modernes utilisent HTTP/3, qui utilise QUIC au lieu de TCP. HTTP/3 réduit le temps d'établissement de connexion et atténue le blocage en tête de file, conduisant à une livraison des ressources globalement plus rapide et plus efficace.

Éliminer entièrement le délai avec les Speculation Rules

L'API Speculation Rules peut éliminer entièrement le délai LCP pour les navigations suivantes.

Mécanisme

Cette API permet aux développeurs d'informer déclarativement le navigateur des URL vers lesquelles un utilisateur est susceptible de naviguer ensuite. Sur la base de ces règles, le navigateur peut choisir de prérestituer une page cible dans un onglet caché en arrière-plan 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érestituée, la navigation est virtuellement instantanée. La page a déjà été entièrement chargée et restituée en arrière-plan. Pour cette navigation, le TTFB, le Resource Load Delay, le Resource Load Duration et le Element Render Delay sont tous effectivement réduits à quasi-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 pourraient être utilisées pour prérestituer 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 : La puissance transformatrice du preloading : Une expérience menée par DebugBear sur une page avec un Load Delay élevé fournit un exemple spectaculaire. L'image LCP était cachée dans une chaîne de requêtes, faisant que le Resource Load Delay représentait 75 % du temps LCP total. En implémentant un simple <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 montre comment une simple correction architecturale peut résoudre un goulot d'étranglement massif.
• Cas 2 : L'anti-pattern loading="lazy" dans le monde réel : Un développeur sur Stack Overflow a signalé un LCP desktop avec un Load Delay de 1 430 ms déconcertant malgré un réseau rapide. La cause a été retracée à un plugin d'optimisation d'images qui appliquait incorrectement le lazy loading à l'image LCP en remplaçant son attribut src par un SVG transparent de placeholder. La solution définitive a été de désactiver ce comportement pour l'élément LCP, lui permettant d'être découvert et chargé en mode eager. Cela illustre comment les outils tiers peuvent introduire par inadvertance des Load Delays sévères.
• Cas 3 : Le boost de performance de 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 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 gagner 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 » et rechargez la page. Regardez 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 en retard par rapport aux autres éléments, il y a un problème de Resource Load Delay. Ci-dessous un exemple de site où le Resource Load Delay n'a pas été optimisé.

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

Comment améliorer le Load Delay

Un Resource Load Delay se produit lorsque l'ordre de téléchargement et le timing des ressources ne sont pas optimaux. Il y a, en substance, deux façons directes de corriger cela : prioriser la ressource LCP ou déprioriser les ressources non-LCP. Explorons quelques patterns courants :

Astuce LCP : Comprendre le Preload Scanner : Les navigateurs modernes utilisent un mécanisme appelé preload scanner, qui 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 par le preload scanner, elle devra attendre le DOM parser plus lent, entraînant des délais. S'assurer que vos ressources LCP sont découvrables par le preload scanner peut faire une grande différence dans la réduction du Load Delay.

1. Optimiser la structure HTML

Le navigateur (ou le preload scanner) traite votre HTML de haut en bas, mettant en file les ressources 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. Pour optimiser cela, supprimez ou différez les ressources inutiles du haut du HTML :

• Lazy-loadez les images non 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 bien moins importantes que l'élément LCP. En lazy-loadant ces images, elles sont ignorées par le preload scanner et mises en file un peu plus tard dans le processus de chargement.
• Déplacez les scripts non importants en bas de page : Déplacez les scripts qui ne sont absolument pas importants pour le chargement initial en bas de la page pour les empêcher de retarder les ressources critiques. Par exemple, 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. Évitez les background images

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

3. Utilisez 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é basse ou moyenne par défaut. Pendant la phase de mise en page, le navigateur promeut les éléments visibles en haute priorité. En définissant fetchpriority="high", le téléchargement commence immédiatement en haute priorité, 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émentez le preloading

Le preloading change 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 instruire le 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 le HTML (et donc mises en file plus tard) ou même pour précharger des ressources pas encore référencées dans le HTML (comme avec 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 avant la ressource LCP et c'est à juste titre. Sans feuilles de style, le navigateur ne saura pas à quoi la page ressemblera et ne peut pas démarrer la phase de rendu. Cependant, une taille de CSS excessive et un nombre excessif de feuilles de style entreront en compétition avec la ressource LCP pour la bande passante précoce.

6. Implémentez un lazy-loading efficace

L'attribut loading peut être une arme à 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.

• Chargement eager de l'élément LCP : Si l'élément LCP est en lazy-load, il ne sera pas mis en file par le preload scanner et se chargera beaucoup plus tard, impactant négativement les performances.
• Lazy-loadez les images du viewport : Pour les images qui sont dans le viewport visible mais ne sont pas des ressources LCP, utilisez loading="lazy" pour les mettre en file de téléchargement un peu plus tard. Cela réduit la compétition de 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 pas de téléchargement du tout, éliminant complètement la compétition de bande passante.

7. Cache navigateur

Le cache navigateur vous permet de sauter 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 visite, il améliorera les temps de chargement pour les visites suivantes et les visiteurs récurrents. Voici comment le cache navigateur aide avec le Resource Load Delay :

• Mettez en cache les ressources concurrentes : Bien que mettre en cache la ressource LCP elle-même soit une excellente stratégie, le cache navigateur améliore les Resource Load Delays 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 serveur : La mise en cache diminue le nombre de requêtes envoyées à votre serveur, ce qui peut améliorer les performances des 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 prefetcher ou prérestituer des pages web en fonction de la navigation prédite de l'utilisateur. Le prefetching élimine efficacement la sous-partie Time to First Byte du LCP et n'a aucun impact sur le Resource Load Delay. Le prerendering restitue la page suivante dans un onglet caché et télécharge toutes les ressources de la page. Cela élimine tous les Load Delays pour l'élément LCP comme le montre cet exemple de décomposition LCP d'une page prérestituée.

9. Évitez le rendu côté client

Prochaines étapes : continuer à 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 :

• Identifier et corriger les problèmes de LCP : La méthodologie de diagnostic complète pour trouver et corriger tous les problèmes de LCP.
• Optimiser l'image LCP : Sélection du format d'image, images responsive, preloading et erreurs courantes sur les images.
• Resource Load Duration : Après que le navigateur a découvert la ressource, réduisez le 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 peut l'afficher immédiatement en libérant le main thread.