Optimiser le délai de chargement des ressources du LCP

Optimiser le délai de chargement des ressources du LCP

Le Largest Contentful Paint (LCP) se compose de quatre phases : TTFB, Délai de chargement des ressources, Durée de chargement des ressources et Délai de rendu de l'élément. Les efforts de développement se concentrent souvent sur la réduction de la Durée de chargement via la compression de fichiers, mais cela néglige le Délai de chargement des ressources, qui est souvent une source de latence plus importante. Ce délai avant que le téléchargement ne commence peut ajouter des centaines de millisecondes à votre LCP, le faisant dépasser le seuil "Bon" de 2,5 secondes. 

Un conseil rapide : si votre LCP est une image, ce sera presque toujours pire que du texte. Vous devez suivre vos 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 Délai de chargement des ressources est le temps entre le TTFB et le moment où le navigateur initie 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 le début de la récupération. 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 délai de chargement des ressources peut être vu 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 à l'aide d'une police système, ce délai de chargement des ressources est généralement nul car aucune ressource externe n'a besoin d'être récupérée. Des valeurs de délai de chargement des ressources 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 la découverte : Scanner de préchargement vs Parseur DOM

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

• Le Scanner de préchargement (Le chemin rapide): Le Scanner de préchargement (Chemin rapide) : C'est un parseur secondaire à haute vitesse qui scanne le HTML brut à la recherche d'URLs 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 le JavaScript ne soit exécuté. C'est le chemin optimal pour toute ressource critique.
• Le Parseur DOM (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 background-image CSS 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 d'autres fichiers d'abord, créant une chaîne de dépendances qui introduit une latence élevée.

Toute la stratégie pour optimiser le Délai de chargement des ressources repose sur un principe : s'assurer que l'URL de la ressource LCP est découvrable par le scanner de préchargement. Tout modèle qui cache l'URL du document HTML initial force le navigateur à utiliser le chemin de découverte lent. Cette période d'attente se traduit directement par un Délai de chargement des ressources. Chaque optimisation efficace consiste à architecturer votre HTML pour placer la ressource LCP sur le chemin rapide

Pourquoi le Délai de chargement compte

Une idée fausse courante est qu'un LCP lent est un problème de "taille de fichier". Cela conduit les équipes à se concentrer uniquement sur la compression d'images pour réduire la Durée de chargement des ressources. Bien que l'optimisation des ressources soit un facteur, l'analyse des données de terrain (field data) du monde réel montre que pour de nombreux sites avec un mauvais LCP, le Délai de chargement des ressources est le principal goulot d'étranglement de performance, pas la Durée de chargement des ressources.

Les données de terrain montrent que le site médian avec un mauvais score LCP a un Délai de chargement des ressources de 1,3 seconde. C'est plus de la moitié du budget total de 2,5 secondes pour un score LCP 'Bon', tout cela 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 que le téléchargement commence qu'au téléchargement lui-même.

Ces données exposent une mauvaise orientation fréquente des efforts de développement. Les équipes peuvent passer des semaines à supprimer des kilo-octets des images pour raccourcir la Durée de chargement de quelques millisecondes, tandis qu'un problème architectural causant un Délai de chargement 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 récupération est retardée de plus d'une seconde, une différence de 100ms dans le temps de téléchargement est insignifiante 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 ressources. L'accent doit passer de la réduction de la taille des ressources à s'assurer qu'elles sont découvertes plus tôt..

Comment détecter le délai de chargement des ressources

Pour corriger le Délai de chargement des ressources, vous devez d'abord le mesurer avec précision. Le flux de travail professionnel consiste d'abord à définir le problème avec des données utilisateur réelles (RUM), et seulement ensuite à passer à Chrome DevTools pour une analyse approfondie.

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

Les données de terrain, ou Real User Monitoring (RUM), sont collectées à partir de sessions utilisateur réelles. Les outils RUM, comme le rapport public Chrome User Experience Report (CrUX) 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 ventilation des sous-parties du LCP, vous montrant le Délai de chargement des ressources médian parmi vos utilisateurs. Ces données valident qu'un problème LCP existe, montrent quelles URLs sont affectées, et révèlent les éléments LCP courants que vos utilisateurs voient réellement. Vous devez commencer par là pour confirmer que vous résolvez un vrai problème.

É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 Délai de chargement des ressources. 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.

Un guide étape par étape du panneau Performance de Chrome DevTools

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

1. Configuration et paramétrage :

• Ouvrez Chrome DevTools en cliquant avec le bouton 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 chronologie de performance.   
• Pour simuler des conditions utilisateur réalistes, appliquez une limitation CPU et 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 mobiles.   

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 démarrera 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 chronologie, localisez la piste Timings. Vous verrez un marqueur étiqueté LCP. Survoler ce marqueur mettra en évidence l'élément LCP correspondant dans la capture d'écran de la fenêtre principale et affichera le temps total LCP.   
• Ventilation du LCP par phase : Cliquez sur le marqueur LCP dans la piste Timings. Dans l'onglet Résumé en bas du panneau, vous trouverez une ventilation détaillée du timing LCP. Cette ventilation montre explicitement la durée de chacune des quatre sous-parties, y compris le délai de chargement, mesuré en millisecondes. Cette valeur est la mesure la plus directe et précise du Délai de chargement des ressources pour ce chargement de page spécifique.   
• Analyse du Main Thread : Tout en examinant la chronologie, regardez la piste Main pour toute tâche longue (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 charger mais avant le marqueur LCP, elles contribuent probablement au Délai de rendu de l'élément, un problème lié mais distinct.   

Causes courantes et solutions à fort impact

Un Délai de chargement des ressources élevé est causé par l'une des deux choses suivantes : la ressource LCP est découverte tardivement, ou elle reçoit 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 scanner de préchargement n'analyse pas les fichiers CSS. Lorsque votre image LCP est définie avec une background-image CSS, 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 du fichier CSS, téléchargé le fichier CSS, construit le CSSOM, et ensuite appliqué le style. Cette chaîne de dépendance cause directement un Délai de chargement des ressources élevé.

La solution : L'implémentation correcte est d'éviter d'utiliser background-image pour tout élément LCP critique. Utilisez une balise <img> standard à la place. Cela place l'URL de l'image directement dans le HTML où le scanner de préchargement peut la trouver immédiatement. Vous pouvez obtenir le même résultat visuel avec CSS.

Exemple d'implémentation :

Anti-modèle (Ne faites pas ça) :

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

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

Bonne pratique (Faites ceci à la place) :

    <!-- 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; /* É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 fournit le même résultat visuel mais rend l'image LCP découvrable au moment le plus précoce possible, ce qui minimise son délai de chargement.

Cause : Rendu côté client et injection JavaScript

Le problème : Les applications utilisant le rendu côté client (CSR) comme React ou Vue servent souvent une coquille HTML minimale. Le contenu réel, y compris la balise <img> LCP, n'est inséré dans le DOM par JavaScript qu'après que les gros paquets de framework soient téléchargés, analysés et exécutés. Ce processus cache fondamentalement la ressource LCP du scanner de préchargement, 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.

• Rendu côté serveur (SSR) ou Génération de site statique (SSG) : Les modèles architecturaux comme SSR ou 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, rendant la ressource LCP immédiatement découvrable par le scanner de préchargement. C'est l'architecture requise pour toute page critique pour la performance.
• Optimisations spécifiques aux frameworks : Les frameworks modernes fournissent également des optimisations intégrées. Par exemple, le composant <Image> de Next.js a une propriété priority. Mettre ceci à true instruit le framework d'ajouter automatiquement les attributs <link rel="preload"> et fetchpriority="high" corrects, 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 de la fenêtre d'affichage (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 scanner de préchargement 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 des ressources élevé.

La solution : La solution nécessite de la diligence.

• Supprimer 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 bon réglage 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 nombreuses plateformes CMS comme WordPress et divers plugins d'optimisation d'image appliquent automatiquement le chargement différé à 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 gros documents

Le problème : Le scanner de préchargement 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 gros document HTML peut aussi être un problème ; si l'élément LCP n'est pas dans le premier morceau 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 : Optimiser la structure et la priorité du contenu dans le HTML.

• Réorganiser 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 vous pouvez le placer à l'intérieur de la balise <body>.
• Dé-prioriser les images non critiques : Pour les images non essentielles qui doivent apparaître tôt dans la source HTML (comme les icônes dans un en-tête), appliquez loading="lazy". Cela dit au scanner de préchargement de les ignorer, préservant la file d'attente de téléchargement pour l'élément LCP.
• Différer les scripts non essentiels : Les scripts pour l'analyse, les publicités 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 des resource hints pour donner au navigateur des instructions plus explicites sur la façon de la récupérer. Ces indications fournissent un contrôle précis sur la découverte et la priorisation.

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

<link rel="preload"> n'est pas une suggestion ; c'est une directive. Elle force le navigateur à télécharger une ressource avec une priorité élevée, même si elle n'est pas encore découvrable par le parseur principal. La 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 situées profondément dans le DOM.

Mécanisme

Quand un lien preload est placé dans le <head> du document HTML, le scanner de préchargement 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 des ressources comme les polices chargées via @font-face dans une feuille de style externe, les LCP background-image CSS (bien que l'utilisation d'une balise <img> soit préférée), ou une image LCP située profondément dans une structure DOM complexe.[3]

Préchargement réactif

Un détail d'implémentation critique est requis lors du préchargement d'images réactives. Pour s'assurer que le navigateur précharge l'image correctement dimensionnée pour la fenêtre d'affichage 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 sur la balise <img> correspondante.[4]

Exemple de préchargement réactif :

<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 préchargement résout le timing de récupération (Délai de chargement et Durée de chargement) mais pas le *timing d'affichage*. 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 encore attendre d'être rendue, ce qui peut déplacer le goulot d'étranglement du Délai de chargement vers le Délai de rendu de l'élément.[5, 6]

Affinement avec fetchpriority="high" : Gagner la bataille de la bande passante

L'attribut fetchpriority est une indication 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.[7]

preload vs fetchpriority

Ces deux indications servent des objectifs différents mais complémentaires. preload affecte quand 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.

Bonne pratique pour le LCP

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

Exemple :

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

Impact prouvé

Dans une étude de cas impliquant Google Flights, l'ajout de fetchpriority="high" à l'image d'arrière-plan LCP de la page a joué un rôle déterminant dans l'amélioration du temps LCP de 2,6 secondes à 1,9 seconde, une amélioration de 700ms.[8]

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 recherche DNS, une poignée de main TCP et une négociation TLS, qui doivent toutes se terminer avant que le premier octet de la ressource puisse être téléchargé. Ce temps de configuration de connexion est un contributeur direct au Délai de chargement des ressources pour les actifs cross-origin.[9, 2, 10, 11]

Les solutions

• preconnect : Cette indication instruit le 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, éliminant la latence de configuration. C'est très efficace et recommandé pour le ou les deux domaines tiers les plus critiques qui servent des ressources LCP.[2]
• dns-prefetch : C'est une indication plus légère qui effectue uniquement la recherche DNS pour un domaine. Cela économise moins de temps que preconnect mais a un support navigateur plus large et est utile comme solution de repli ou pour des domaines tiers moins critiques.[2, 12]

Bonne pratique d'implémentation

Pour assurer une compatibilité maximale, fournissez les deux indications. Le navigateur utilisera preconnect s'il est supporté et se repliera sur dns-prefetch sinon. L'attribut crossorigin est essentiel pour les ressources récupérées en utilisant CORS, telles que 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 éviter les abus et clarifier les rôles distincts de ces puissantes indications, le tableau suivant fournit un résumé comparatif.

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

Au-delà des indications ciblées, des décisions architecturales plus larges et des fonctionnalités émergentes de la plateforme web peuvent fournir des solutions holistiques et puissantes au Délai de chargement des ressources.

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 Délai de chargement des ressources, en particulier pour les ressources LCP.

• Réduire la surcharge de connexion : En distribuant les actifs 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 temps d'aller-retour (RTT) requis pour la recherche DNS, la poignée de main TCP et la négociation TLS, qui sont toutes des composantes du temps de configuration de la connexion.[13, 14, 15] Pour une image LCP hébergée sur un CDN, cela réduit directement son délai de chargement.
• CDNs d'images : Les CDNs 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 la Durée de chargement des ressources, telles que le redimensionnement d'image à la volée, la compression et la conversion vers des formats modernes comme AVIF et WebP.[9, 1]
• Protocoles avancés : De nombreux CDNs modernes tirent parti de protocoles réseau supérieurs comme HTTP/3, qui utilise QUIC au lieu de 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), conduisant à une livraison de ressources plus rapide et plus efficace dans l'ensemble.[16]

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

L'API Speculation Rules est une fonctionnalité de pointe de la plateforme web qui offre le potentiel d'éliminer entièrement le délai LCP pour les navigations ultérieures.

Mécanisme

Cette API permet aux développeurs d'informer déclarativement le navigateur des URLs vers lesquelles un utilisateur est susceptible de naviguer ensuite. Sur la base de ces règles, le navigateur peut choisir de prérendre (prerender) une page cible dans un onglet caché, en arrière-plan, avant même que l'utilisateur ne clique sur le lien.[3, 1, 16]

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 Délai de chargement des ressources, la Durée de chargement des ressources et le Délai de rendu de l'élément sont tous effectivement réduits à presque zéro du point de vue de l'utilisateur.[3, 1, 16]

Exemple de cas d'utilisation

Sur une page de catégorie e-commerce, les règles de spéculation pourraient être utilisées pour prérendre les pages de détail des produits pour les quelques premiers articles de la liste. Lorsqu'un utilisateur clique sur l'un de ces produits, la page apparaît instantanément, offrant une expérience transparente et exceptionnellement rapide.

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

L'efficacité de ces stratégies d'optimisation n'est pas simplement théorique ; elle est démontrée par des données issues de tests et de scénarios du monde réel.

• Cas 1 : Le pouvoir transformateur du préchargement : Une expérience menée par DebugBear sur une page avec un délai de chargement élevé fournit un exemple spectaculaire. L'image LCP était cachée dans une chaîne de requêtes, faisant que le Délai de chargement des ressources représentait un stupéfiant 75% du temps LCP total. En implémentant une seule indication <link rel="preload"> pour rendre l'image découvrable tôt, le Délai de chargement des ressources a été réduit à seulement 2% du temps LCP.[17] Cela montre comment une simple correction architecturale peut résoudre un goulot d'étranglement de performance massif.
• Cas 2 : L'anti-modèle loading="lazy" du monde réel : Un développeur sur Stack Overflow a signalé un LCP de bureau avec un délai de chargement déconcertant de 1 430ms malgré un réseau rapide. La cause a été tracée jusqu'à un plugin d'optimisation d'image qui appliquait incorrectement le chargement différé à l'image LCP en remplaçant son attribut src par un SVG de remplacement transparent. La solution définitive a été de désactiver ce comportement pour l'élément LCP, lui permettant d'être découvert et chargé de manière "eager" (impatiente).[18] Cela illustre comment des outils tiers peuvent introduire par inadvertance des délais de chargement sévères.
• Cas 3 : Le boost de performance fetchpriority : L'étude de cas Google Flights fournit une preuve claire de l'impact de la 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 700ms, passant de 2,6 secondes à 1,9 seconde.[8] 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 traîne derrière d'autres éléments, il y a un problème de délai de chargement des ressources. Ci-dessous un exemple d'un site où le délai de chargement des ressources n'a pas été optimisé.

Tirer parti des 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 ventilation des sous-parties du LCP (au fil du temps ou par page), vous donnant 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 ventilation LCP globale avec le délai de chargement correspondant.

Comment améliorer le Délai de chargement

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

Conseil LCP : Comprendre le Scanner de préchargement : Les navigateurs modernes utilisent un mécanisme appelé scanner de préchargement, 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 d'attente par le scanner de préchargement, elle devra attendre le parseur DOM plus lent, résultant en des délais. S'assurer que vos ressources LCP sont découvrables par le scanner de préchargement peut faire une grande différence dans la réduction du délai de chargement.

1. Optimiser la structure HTML

Le navigateur (ou le scanner de préchargement) traite votre HTML de haut en bas, 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 tôt elle est mise en file d'attente. Pour optimiser cela, supprimez ou différez les ressources inutiles du haut du HTML :

• Charger en différé (Lazy-Load) les images non importantes ou cachées: Parfois, des images (par exemple des drapeaux pour des versions linguistiques spécifiques 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 chargeant ces images en différé, elles sont ignorées par le scanner de préchargement et mises en file d'attente un peu plus tard durant le processus de chargement.
  
• Déplacer les scripts non importants vers le bas de la page : Déplacez les scripts qui sont absolument non importants pour le chargement initial vers le 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. Éviter les images d'arrière-plan.

Les images d'arrière-plan sont invisibles pour le scanner de préchargement, 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 une balise <img> régulière à la place, combinée avec la propriété CSS object-fit: cover pour imiter l'apparence d'une image d'arrière-plan. De cette façon, le scanner de préchargement peut détecter et mettre en file d'attente l'image 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ébut. Normalement, les images chargent avec une priorité par défaut basse ou moyenne. Durant la phase de mise en page, 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 à haute priorité, assurant un LCP plus rapide. 

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

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

4. Implémenter le préchargement

Le préchargement change l'ordre dans lequel le scanner de préchargement 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, telles que l'image LCP, aussi tôt que possible. Les préchargements peuvent être utilisés pour précharger des ressources qui sont référencées plus tard dans le html (et donc mises en file d'attente plus tard) ou même pour précharger des ressources qui ne sont pas encore référencées dans le html (comme avec certains sliders). Pour une efficacité maximale, il est recommandé de placer les préchargements 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 c'est pour une bonne cause. Sans feuilles de style, le navigateur ne saura pas à quoi la page ressemblera et ne pourra pas commencer la phase de rendu. Cependant, une taille excessive de CSS et un nombre excessif de feuilles de style concurrenceront la ressource LCP pour la bande passante précoce.

6. Implémenter le chargement différé efficace

L'attribut loading peut être une arme à double tranchant. Utilisez loading="eager" (ou omettez simplement l'attribut puisque "eager" est la valeur 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 chargé en différé, il ne sera pas mis en file d'attente par le scanner de préchargement et chargera beaucoup plus tard, impactant négativement la performance.
• Chargement différé des images de la fenêtre d'affichage : Pour les images qui sont dans la fenêtre d'affichage visible mais ne sont pas des ressources LCP, utilisez loading="lazy" pour les mettre en file d'attente pour le téléchargement légèrement plus tard. Cela réduit la compétition de bande passante avec la ressource LCP.
• Éviter le chargement différé des images hors écran : Les images qui ne sont pas dans la fenêtre d'affichage visible ne déclencheront pas de téléchargement du tout, éliminant complètement la compétition de bande passante.

7. Cache du navigateur

Le cache du navigateur vous permet de sauter les requêtes réseau pour des ressources qui ont déjà été stockées localement sur l'appareil de l'utilisateur. Bien que cela n'accélérera pas la première page vue, cela améliorera les temps de chargement pour les pages vues suivantes et les visiteurs récurrents. Voici comment le cache du navigateur aide avec le délai de chargement des ressources :

• 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 cache du navigateur améliore les délais de chargement des ressources LCP en stockant les ressources réseau qui pourraient concurrencer ou retarder la ressource LCP, telles que les scripts, les feuilles de style et les images.
  
• Réduire la charge du serveur : La mise en cache diminue le nombre de requêtes envoyées à votre serveur, ce qui peut améliorer la performance d'autres ressources en libérant de la bande passante et en réduisant les cycles CPU du serveur.
  

8. Utiliser les règles de spéculation

Les Speculation Rules permettent aux navigateurs de pré-récupérer (prefetch) ou de prérendre (prerender) des pages web basées sur la navigation utilisateur prédite. Le prefetching élimine efficacement la sous-partie Time to First Byte du LCP et n'a aucun impact sur le délai de chargement des ressources. Le prerendering rend la page suivante dans un onglet caché et télécharge toutes les ressources de la page.  Cela élimine tous les délais de chargement pour l'élément LCP comme montré dans cet exemple de ventilation LCP d'une page prérendue.

9. Éviter le rendu côté client