Optimiser la LCP Resource Load Duration

Ce guide fait partie de la section Largest Contentful Paint (LCP) de notre centre de ressources Core Web Vitals. La Resource Load Duration (durée de chargement de la ressource) est la troisième des quatre phases séquentielles du LCP, mesurant le temps nécessaire pour télécharger la ressource LCP sur le réseau. Bien que le Resource Load Delay (délai de chargement de la ressource) représente souvent une part plus importante du temps LCP, l'optimisation de la durée de téléchargement reste essentielle pour obtenir un bon score LCP.

Optimiser la LCP Resource Load Duration

Le Largest Contentful Paint (LCP) est l'une des trois mesures de performance des Core Web Vitals qui évaluent votre user experience en ligne. Le LCP capture le temps nécessaire pour que le plus grand élément de contenu (une image, une vidéo ou un bloc de texte) devienne visible dans la fenêtre d'affichage (viewport). La Resource Load Duration est une sous-partie du LCP qui indique combien de temps est consacré à la récupération de la ressource réseau pour l'élément LCP.

Qu'est-ce que la Resource Load Duration dans le LCP ?

La Resource Load Duration, souvent appelée Load Duration, fait référence au temps requis par le navigateur pour télécharger la ressource réseau (par exemple, une image) qui finira par devenir l'élément LCP. Pour les images et les vidéos, cette durée s'étend du moment où l'image commence à se télécharger jusqu'à ce que le navigateur termine le téléchargement. Pour les éléments LCP basés sur du texte, la durée de chargement est généralement nulle. Le guide d'optimisation LCP de Google décompose le LCP en quatre sous-parties séquentielles, la Resource Load Duration étant le temps passé à télécharger réellement les octets de la ressource.

La Resource Load Duration est mesurée à partir du moment où le navigateur commence à télécharger la ressource LCP jusqu'à ce qu'il ait terminé de la télécharger. Quatre facteurs principaux déterminent la durée de chargement des ressources :

• Taille du fichier : Les fichiers plus volumineux nécessitent des temps de téléchargement plus longs.
• Vitesse du réseau : Des connexions plus lentes prolongent naturellement la durée de chargement.
• Réactivité du serveur : Les retards dans la réponse du serveur ralentissent la récupération des ressources.
• Téléchargements simultanés : Les ressources téléchargées en même temps se font concurrence pour la bande passante, ce qui peut augmenter les temps de chargement.

Comment détecter la Resource Load Duration

Il existe deux moyens efficaces d'identifier et de mesurer la durée de chargement d'une ressource :

Inspection du réseau dans Chrome DevTools : Utilisez le raccourci Ctrl + Shift + I pour ouvrir les outils de développement (Developer Tools) de Chrome, puis sélectionnez l'onglet "Network" et rechargez la page. Recherchez l'élément LCP dans les requêtes réseau (si vous souhaitez connaître l'élément LCP, essayez le Core Web Vitals Visualizer). L'inspecteur de réseau vous montrera combien de temps il a fallu pour télécharger la ressource.

Astuce de pro : Activez les grandes lignes de requête (large request rows) pour voir des détails supplémentaires tels que la latence LCP, la taille transférée et la taille réelle.

Utiliser les données Real User Monitoring (RUM) :

Les outils RUM enregistrent souvent des données d'attribution LCP. Les données d'attribution pour le Largest Contentful Paint contiennent des informations sur la Resource Load Duration. Avec ces données, vous pouvez tracer les tendances de durée de chargement au fil du temps ou par page, et repérer les pages ou les éléments qui ralentissent les choses.

Comment améliorer la durée de chargement du LCP

Les problèmes de durée de chargement des ressources surviennent lorsque les ressources sont trop volumineuses ou diffusées sur des chemins réseau sous-optimaux. Deux approches principales permettent de résoudre ce problème : réduire la taille des données ou optimiser la diffusion des données.

1. Optimiser la taille du fichier

L'optimisation de la taille du fichier réduit le nombre d'octets à envoyer sur le réseau. Moins de données signifie moins de temps de téléchargement. Pour un guide complet sur l'optimisation des images, consultez notre article expliquant comment optimiser les images.

Utiliser des formats d'image modernes

AVIF et WebP sont les meilleures options pour la compression d'images. L'AVIF permet une compression jusqu'à 50 % inférieure à celle du WebP pour des photos complexes, sans perte de qualité visible. Le WebP bénéficie d'un support navigateur plus large et fonctionne bien pour des images plus simples. Selon le Web Almanac 2025, le WebP est désormais utilisé dans plus de 40 % des requêtes d'images, tandis que l'adoption de l'AVIF a environ doublé d'une année sur l'autre mais reste inférieure à 10 %.

Choisir le bon réglage de qualité

Les formats d'image modernes tels que le WebP et l'AVIF permettent une réduction significative de la qualité avant qu'une dégradation visuelle ne devienne perceptible. En règle générale, un paramètre de qualité compris entre 75 et 85 pour le WebP, et entre 60 et 75 pour l'AVIF, semblera identique à l'original à des distances de visionnage normales, mais pour une fraction de la taille du fichier. Testez toujours avec vos propres images, car la qualité optimale dépend du type de contenu (photographies par rapport aux illustrations ou aux images contenant beaucoup de texte).

Automatiser la compression d'image avec Sharp

Pour l'optimisation des images lors de la phase de build, la bibliothèque sharp est l'un des outils les plus rapides et les plus largement utilisés dans l'écosystème Node.js. L'exemple suivant montre comment convertir et compresser une image aux formats WebP et AVIF avec des paramètres de qualité optimisés :

const sharp = require('sharp');

// Convertir en WebP avec une qualité optimisée
await sharp('input.jpg')
  .resize(1200)  // Redimensionner à la largeur maximale requise
  .webp({ quality: 80, effort: 6 })
  .toFile('output.webp');

// Convertir en AVIF avec une qualité optimisée
await sharp('input.jpg')
  .resize(1200)
  .avif({ quality: 65, effort: 6 })
  .toFile('output.avif');

// Générer plusieurs tailles pour des images responsives
const widths = [400, 800, 1200];
for (const width of widths) {
  await sharp('input.jpg')
    .resize(width)
    .webp({ quality: 80 })
    .toFile(`output-${width}w.webp`);
}

Cette approche génère toutes les variantes dont vous avez besoin pour un élément <picture> responsive (adaptatif) prenant en charge les formats modernes. Pour les sites WordPress, des plugins comme ShortPixel ou Imagify gèrent automatiquement cette conversion lors du téléchargement.

Images responsives

L'élément <picture> et l'attribut srcset servent des tailles d'image différentes en fonction de l'écran : des versions plus petites pour mobile, une résolution plus élevée pour les écrans plus grands. Voici un exemple de configuration :

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" alt="Description" width="800" height="450">
</picture>

Dimensions d'image correctes

Les images responsives ne sont qu'une partie de la solution, car "responsive" ne signifie pas "à la bonne taille". Faire correspondre les dimensions de l'image à leur taille d'affichage est l'une des erreurs les plus fréquentes que je vois. Servir une image de 2000 pixels de large pour une zone d'affichage de 500 pixels gaspille de la bande passante et peut ralentir considérablement les temps de chargement.

Optimisation des fichiers de police

Lorsque l'élément LCP est un texte affiché avec une police web personnalisée, le fichier de police devient la ressource LCP. Optimisez la durée de chargement de la police de la manière suivante :

• Utilisez le format WOFF2 : Le WOFF2 offre la meilleure compression pour les polices web, il est généralement 30 % plus petit que le WOFF et nettement plus petit que les fichiers TTF ou OTF.
• Réduisez vos polices (subsetting) : Si votre site n'utilise que des caractères latins, créez un sous-ensemble de la police pour supprimer les jeux de caractères inutilisés (cyrillique, grec, CJK). Des outils comme glyphhanger ou pyftsubset peuvent automatiser cela, réduisant souvent la taille du fichier de police de 50 % ou plus.
• Limitez les variations de police : Chaque graisse et style (régulier, gras, italique) constitue un téléchargement de fichier distinct. N'incluez que les graisses que votre design utilise réellement.

2. Améliorer les performances du réseau

Une fois les tailles de ressources optimisées, l'étape suivante consiste à maximiser la vitesse du réseau, ou même à contourner complètement le réseau.

Contourner les besoins réseau avec la mise en cache du navigateur

Il n'y a pas de connexion réseau plus rapide qu'une connexion réseau ignorée. Les navigateurs peuvent servir du contenu statique (images, scripts, feuilles de style) directement depuis le cache local. Configurez le serveur pour qu'il envoie des instructions de mise en cache correctes au navigateur.

La configuration la plus efficace consiste à envoyer un en-tête Cache-Control de cette façon :

Cache-Control: public, max-age=31536000, immutable

• public : Permet à la ressource d'être mise en cache à la fois par les navigateurs et les caches intermédiaires.
• max-age=31536000 : Définit le temps maximum pendant lequel la ressource est considérée comme fraîche à un an (31 536 000 secondes).
• immutable : Indique que la ressource ne changera pas au fil du temps, évitant ainsi les requêtes de revalidation inutiles.

Pour que cette stratégie fonctionne en toute sécurité, utilisez des noms de fichiers contenant un hash du contenu (par exemple, hero-abc123.webp) de sorte que lorsque l'image change, le nom du fichier change également, purgeant ainsi le cache automatiquement.

Compression Brotli vs. Gzip

Pour les ressources basées sur du texte (HTML, CSS, JavaScript, SVG), la compression côté serveur est essentielle. Le Brotli, développé par Google, surpasse systématiquement le Gzip en termes de taux de compression tout en maintenant des vitesses de décompression comparables. La comparaison suivante illustre la différence :

La configuration idéale consiste à pré-compresser les ressources statiques avec Brotli à un niveau de compression élevé (par exemple, niveau 11) lors de votre processus de build, et à utiliser Gzip comme option de secours (fallback) pour les clients qui ne prennent pas en charge le Brotli. La plupart des CDN, y compris Cloudflare, gèrent cela automatiquement. Pour plus de détails sur la configuration du CDN, consultez notre guide sur la configuration de Cloudflare pour les performances.

HTTP/2 et HTTP/3 : Les avantages des protocoles modernes

Le protocole de distribution est très important lorsque le navigateur télécharge plusieurs ressources en même temps.

• HTTP/2 a introduit le multiplexage, permettant d'envoyer simultanément plusieurs requêtes et réponses sur une seule connexion TCP. Cela élimine le problème de blocage de la tête de file (head-of-line blocking) du HTTP/1.1, où une ressource lente pouvait retarder toutes les autres. Le HTTP/2 prend également en charge la compression des en-têtes (HPACK) et le push serveur.
• HTTP/3 va encore plus loin en remplaçant TCP par QUIC, un protocole basé sur UDP. Le HTTP/3 élimine le blocage de tête de file au niveau TCP (où un seul paquet perdu bloque tous les flux), permet un établissement de connexion plus rapide grâce au 0-RTT (Zero Round Trip Time pour les visiteurs connus), et gère la perte de paquets de manière plus élégante. Ces améliorations accélèrent principalement le Time to First Byte, mais elles réduisent également la durée de chargement des ressources.

Pour vérifier si le HTTP/3 est activé, inspectez simplement votre réseau avec le raccourci Ctrl+Shift+I. Sélectionnez l'onglet Network, faites un clic droit sur les en-têtes de colonnes du réseau et assurez-vous que 'protocol' est activé. Rechargez la page et vérifiez le protocole. Pour HTTP/3, le protocole doit indiquer 'h3'.

Réseaux de diffusion de contenu (CDN)

Un CDN est un réseau de serveurs distribués qui mettent en cache et diffusent des ressources statiques telles que des images, du CSS et du JavaScript à partir d'emplacements plus proches de l'utilisateur. Cela réduit le temps de trajet des données (le temps aller-retour), ce qui affecte directement la Resource Load Duration.

Au-delà de la proximité, les CDN modernes offrent plusieurs avantages en matière de performances qui réduisent la durée de chargement :

• Optimisation automatique des images : De nombreux CDN peuvent compresser, redimensionner et convertir des images à la volée. Par exemple, Cloudflare Polish, Imgix et Cloudinary peuvent fournir du WebP ou de l'AVIF automatiquement en fonction de l'en-tête Accept du navigateur.
• Mise en cache en périphérie (Edge caching) : Les ressources statiques sont mises en cache sur des nœuds périphériques dans le monde entier, éliminant ainsi le besoin d'aller les chercher sur le serveur d'origine.
• Optimisation des protocoles : Les CDN activent généralement HTTP/2 et HTTP/3 par défaut, ainsi que la compression Brotli, sans nécessiter de modifications de configuration côté serveur.
• Réutilisation de la connexion : Étant donné que le CDN diffuse toutes les ressources à partir d'un domaine unique, le navigateur réutilise une seule connexion, éliminant ainsi la surcharge causée par les multiples recherches DNS et poignées de main (handshakes) TLS.

Les CDN spécialisés dans les images peuvent aller plus loin en proposant des optimisations automatiques en temps réel telles que la conversion de format, le redimensionnement et la compression.

Auto-hébergement des ressources

Les ressources réseau importantes et précoces doivent, par défaut, toujours être hébergées sur le serveur d'origine. L'auto-hébergement évite d'avoir à se connecter à des serveurs tiers, ce qui peut causer des retards considérables en raison de recherches DNS supplémentaires, de négociations SSL et de configurations de connexion. L'auto-hébergement garantit la réutilisation d'une connexion unique déjà ouverte et réduit la surcharge liée à l'établissement de connexions distinctes. Les ressources auto-hébergées permettent également un contrôle total sur les politiques de compression et de cache.

3. Optimiser la priorisation des ressources

Après avoir réduit la taille des ressources et optimisé le réseau, se pose également le problème de la concurrence sur le réseau. Lorsque le navigateur demande plusieurs ressources en même temps sur une connexion lente, celles-ci sont en concurrence pour la bande passante. Minimisez cette concurrence en planifiant les téléchargements de ressources.

Prioriser les ressources critiques

Marquez les ressources essentielles, telles que les images de héros (hero images) ou le CSS de la partie visible de la page (above-the-fold), avec fetchpriority="high". Cela indique au navigateur de télécharger ces ressources en premier, en évitant qu'elles ne s'enlisent à cause de scripts, de widgets ou d'éléments tiers qui n'ont pas besoin d'un chargement instantané. La priorisation de ces ressources critiques réduit le temps de chargement du contenu qui importe le plus à vos utilisateurs. La combinaison du préchargement (pour pallier la découverte tardive) et de fetchpriority="high" (pour résoudre les conflits sur le réseau) est la technique la plus puissante pour s'assurer que la ressource LCP est récupérée le plus tôt et le plus rapidement possible.

<!-- Pour les images LCP visibles dans le HTML initial -->
<img src="hero-image.webp" fetchpriority="high" alt="...">

<!-- Pour améliorer la découverte  -->
<link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">

Réduire la contention du réseau

Rationalisez les téléchargements initiaux en différant ou en chargeant en différé (lazy-loading) les ressources non essentielles. Repoussez le chargement des images ou des vidéos qui ne sont pas immédiatement visibles, ainsi que des éléments d'arrière-plan ou secondaires. L'utilisation de loading="lazy" pour les médias hors écran est un bon point de départ. Le fait de différer davantage d'autres scripts et ressources non essentiels libérera de la bande passante et réduira toute concurrence avec vos ressources critiques, ce qui permettra au contenu principal de votre page de se charger et de s'afficher rapidement. N'appliquez jamais loading="lazy" à votre image LCP ; c'est un anti-pattern critique qui nuira à votre score.

4. Configurer les Speculation Rules

Les Speculation Rules permettent aux navigateurs de pré-récupérer (prefetch) ou de pré-afficher (prerender) des pages web en fonction de la navigation prévue de l'utilisateur. Le préchargement (prefetching) élimine efficacement la sous-partie Time to First Byte du LCP et n'a aucun impact sur la Resource Load Duration. Le pré-rendu (prerendering) affiche la page suivante dans un onglet masqué et télécharge toutes les ressources de la page. Cela élimine la majeure partie de la durée de chargement de l'élément LCP, comme le montre cet exemple de décomposition du LCP d'une page pré-rendue.

Prochaines étapes : Continuer à optimiser le LCP

La Resource Load Duration n'est que l'une des quatre phases du LCP. Après avoir optimisé le temps de téléchargement, poursuivez avec les autres phases du LCP :

• Corriger et identifier les problèmes LCP : La méthodologie de diagnostic complète pour trouver et corriger tous les problèmes LCP à l'aide des données de terrain et des outils de laboratoire.
• Optimiser l'image LCP : Sélection du format d'image, images responsives, préchargement et erreurs courantes d'optimisation d'image.
• Resource Load Delay : Assurez-vous que le navigateur découvre la ressource LCP le plus tôt possible. C'est souvent un goulot d'étranglement plus important que la durée de chargement elle-même.
• Element Render Delay : Une fois la ressource téléchargée, assurez-vous que le navigateur puisse l'afficher (paint) immédiatement en libérant le thread principal.