Optimisez la durée de chargement de la ressource LCP

Ce guide fait partie de la section Largest Contentful Paint (LCP) de notre centre de ressources Core Web Vitals. La durée de chargement de la ressource est la troisième des quatre phases séquentielles du LCP. Elle mesure le temps de téléchargement réseau de la ressource LCP. Le délai de chargement de la ressource (Resource Load Delay) occupe souvent une plus grande part du temps LCP. Optimiser la durée de téléchargement reste toutefois essentiel pour un bon score LCP.

Optimiser la durée de chargement de la ressource LCP

Le Largest Contentful Paint (LCP) est l'une des trois métriques de performance Core Web Vitals. Elles mesurent l'expérience utilisateur 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 le viewport. La durée de chargement de la ressource est une sous-partie du LCP. Elle indique le temps passé à récupérer la ressource réseau pour l'élément LCP.

Qu'est-ce que la durée de chargement de la ressource dans le LCP ?

La durée de chargement de la ressource, souvent appelée Load Duration, désigne le temps nécessaire au navigateur pour télécharger la ressource réseau (par exemple, une image) qui deviendra l'élément LCP. Pour les images et les vidéos, cette durée s'étend du début à la fin du téléchargement par le navigateur. Pour les éléments LCP textuels, la durée de chargement est généralement nulle. Le guide d'optimisation du LCP de Google divise le LCP en quatre sous-parties séquentielles. La durée de chargement de la ressource correspond au temps réellement passé à télécharger les octets de la ressource.

La durée de chargement de la ressource se mesure à partir du moment où le navigateur commence à télécharger la ressource LCP jusqu'à la fin du téléchargement. Quatre facteurs principaux déterminent cette durée :

• Taille du fichier : Les gros fichiers nécessitent des temps de téléchargement plus longs.
• Vitesse du réseau : Les connexions lentes allongent naturellement la durée de chargement.
• Réactivité du serveur : Les retards de 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 disputent la bande passante. Cela peut augmenter les temps de chargement.

Comment détecter la durée de chargement de la ressource

Il existe deux méthodes efficaces pour identifier et mesurer la durée de chargement de la ressource :

Inspection du réseau dans Chrome DevTools : Utilisez le raccourci Ctrl + Maj + I pour ouvrir les outils de développement de Chrome. Sélectionnez l'onglet « Network » et rechargez la page. Cherchez l'élément LCP dans les requêtes réseau (pour identifier l'élément LCP, essayez Core Web Vitals Visualizer). L'inspecteur réseau vous montrera combien de temps a pris le téléchargement de la ressource.

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

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

Les outils RUM enregistrent souvent les données d'attribution LCP. Ces données pour le Largest Contentful Paint contiennent des informations sur la durée de chargement de la ressource. Grâce à ces données, vous pouvez tracer l'évolution de la durée de chargement dans le temps ou par page. Vous repérez ainsi les pages ou les éléments qui ralentissent l'affichage.

Guide étape par étape : pour une mesure de laboratoire précise, enregistrez une trace dans le panneau Performance. L'analyse détaillée du LCP (LCP breakdown) affiche la durée de chargement de la ressource à côté des trois autres sous-parties. Tutoriel complet : Diagnostiquer le LCP avec le panneau Performance de Chrome DevTools.

Comment améliorer la durée de chargement LCP

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

1. Optimiser la taille du fichier

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

Utiliser des formats d'image modernes

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

Choisir le bon niveau de qualité

Les formats d'image modernes comme WebP et AVIF permettent une réduction significative de la qualité avant qu'une dégradation visuelle ne soit perceptible. En règle générale, un réglage de qualité entre 75 et 85 pour WebP, et entre 60 et 75 pour AVIF, paraîtra identique à l'original à des distances de visionnage normales. Tout cela pour une fraction de la taille du fichier. Testez toujours avec vos propres images. La qualité optimale dépend du type de contenu (photographies, illustrations, images contenant beaucoup de texte).

Automatiser la compression d'image avec Sharp

Pour l'optimisation des images lors du build, la bibliothèque sharp est l'un des outils les plus rapides et les plus utilisés de l'écosystème Node.js. L'exemple suivant montre comment convertir et compresser une image aux formats WebP et AVIF avec des réglages 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 les 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 nécessaires pour un élément <picture> responsive supportant les formats modernes. Pour les sites WordPress, des plugins comme ShortPixel ou Imagify gèrent cette conversion automatiquement lors de l'upload.

Images responsives

L'élément <picture> et l'attribut srcset servent différentes tailles d'image selon l'écran : des versions plus petites pour mobile, une résolution plus élevée pour les grands écrans. 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 veut pas dire à la bonne taille. Ne pas adapter les dimensions de l'image à sa taille d'affichage est l'une des erreurs les plus fréquentes que je rencontre. Servir une image de 2000 px de large pour une zone d'affichage de 500 px gaspille de la bande passante et ralentit considérablement les temps de chargement.

Optimisation des fichiers de police

Lorsque l'élément LCP est du texte rendu avec une police web personnalisée, le fichier de police devient la ressource LCP. Optimisez la durée de chargement de la police de ces manières :

• Utilisez le format WOFF2 : WOFF2 offre la meilleure compression pour les polices web. Il est généralement 30 % plus petit que WOFF et nettement plus léger que les fichiers TTF ou OTF.
• Créez des subsets de vos polices : Si votre site n'utilise que des caractères latins, créez un subset de la police pour supprimer les jeux de caractères inutilisés (Cyrillique, Grec, CJK). Des outils comme glyphhanger ou pyftsubset automatisent cela. Ils réduisent souvent la taille du fichier de police de 50 % ou plus.
• Limitez les variations de police : Chaque graisse et style (régulier, gras, italique) déclenche un téléchargement de fichier distinct. N'incluez que les graisses que votre design utilise réellement.

2. Améliorer la performance réseau

Une fois la taille des ressources optimisée, l'étape suivante consiste à maximiser la vitesse du réseau, voire à contourner complètement le réseau.

Contourner le réseau avec le cache du navigateur

La connexion réseau la plus rapide est celle qui n'a pas lieu. Les navigateurs peuvent servir du contenu statique (images, scripts, feuilles de style) directement depuis le cache local. Configurez le serveur pour qu'il envoie les bonnes instructions de mise en cache au navigateur.

La configuration la plus efficace consiste à envoyer un en-tête Cache-Control comme ceci :

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

• public : Permet à la ressource d'être mise en cache par les navigateurs et les caches intermédiaires.
• max-age=31536000 : Définit la durée maximale de validité de la ressource à un an (31 536 000 secondes).
• immutable : Indique que la ressource ne changera pas dans le temps. Cela évite les requêtes de revalidation inutiles.

Pour que cette stratégie fonctionne sans risque, utilisez des noms de fichiers contenant un hash (par exemple, hero-abc123.webp). Ainsi, lorsque l'image change, le nom du fichier change aussi. Cela invalide automatiquement le cache.

Compression Brotli vs Gzip

Pour les ressources textuelles (HTML, CSS, JavaScript, SVG), la compression côté serveur est essentielle. Brotli, développé par Google, surpasse systématiquement Gzip en termes de taux de compression. Ses vitesses de décompression restent comparables. La comparaison suivante illustre la différence :

La configuration idéale consiste à précompresser les assets statiques avec Brotli à un niveau de compression élevé (par exemple, le niveau 11) pendant votre processus de build. Utilisez Gzip comme fallback pour les clients qui ne supportent pas Brotli. La plupart des CDN, y compris Cloudflare, gèrent cela automatiquement. Pour plus de détails sur la configuration CDN, consultez notre guide sur la configuration de Cloudflare pour la performance.

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

Le protocole de livraison est particulièrement important lorsque le navigateur télécharge plusieurs ressources en même temps.

• HTTP/2 a introduit le multiplexage. Il permet d'envoyer simultanément plusieurs requêtes et réponses sur une seule connexion TCP. Cela élimine le problème de blocage en tête de file (head-of-line blocking) de HTTP/1.1, où une ressource lente retardait toutes les autres. HTTP/2 supporte également la compression des en-têtes (HPACK) et le server push.
• HTTP/3 va plus loin en remplaçant TCP par QUIC, un protocole basé sur UDP. HTTP/3 élimine le blocage en tête de file au niveau TCP (où la perte d'un seul paquet bloque tous les flux). Il offre un établissement de connexion plus rapide via 0-RTT (reprise sans délai de transmission pour les visiteurs de retour). Il gère plus efficacement la perte de paquets. Ces améliorations accélèrent principalement le Time to First Byte, mais elles réduisent aussi la durée de chargement de la ressource.

Pour vérifier si HTTP/3 est activé, inspectez votre réseau avec le raccourci Ctrl+Maj+I. Sélectionnez l'onglet réseau (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 ».

Content Delivery Networks (CDN)

Un CDN est un réseau de serveurs distribués. Ils mettent en cache et servent des ressources statiques comme des images, du CSS et du JavaScript depuis des emplacements plus proches de l'utilisateur. Cela réduit le temps de trajet des données (le round-trip time), ce qui impacte directement la durée de chargement de la ressource.

Au-delà de la proximité, les CDN modernes offrent plusieurs avantages de performance qui réduisent la durée de chargement :

• Optimisation automatique des images : De nombreux CDN compressent, redimensionnent et convertissent les images à la volée. Par exemple, Cloudflare Polish, Imgix et Cloudinary servent du WebP ou de l'AVIF automatiquement en fonction de l'en-tête Accept du navigateur.
• Mise en cache à la périphérie (edge caching) : Les ressources statiques sont mises en cache sur des nœuds périphériques dans le monde entier. Cela évite totalement de les récupérer depuis 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. Aucune modification de configuration côté serveur n'est requise.
• Réutilisation des connexions : Le CDN sert toutes les ressources depuis un seul domaine. Le navigateur réutilise donc une connexion unique. Cela élimine la surcharge liée aux multiples requêtes DNS et aux handshakes TLS.

Les CDN spécialisés dans les images vont plus loin. Ils fournissent des optimisations automatiques en temps réel : conversion de format, redimensionnement et compression.

Auto-héberger les 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 de se connecter à des serveurs tiers. Ces connexions tierces causent des retards considérables à cause des requêtes DNS supplémentaires, des négociations SSL et des configurations de connexion. L'auto-hébergement garantit la réutilisation d'une connexion unique déjà ouverte. Il réduit la surcharge liée à l'établissement de connexions distinctes. Les ressources auto-hébergées donnent é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 le problème de la concurrence réseau. Lorsque le navigateur requête plusieurs ressources en même temps sur une connexion lente, elles se disputent la bande passante. Minimisez cette concurrence en planifiant les téléchargements de ressources.

Prioriser les ressources critiques

Marquez les ressources essentielles, comme les images hero ou le CSS au-dessus de la ligne de flottaison (above-the-fold), avec fetchpriority="high". Cela signale au navigateur de télécharger ces assets en premier. Ils ne seront pas ralentis par des scripts, des widgets ou des éléments tiers qui ne nécessitent pas un chargement instantané. Prioriser ces ressources critiques réduit le temps de chargement du contenu le plus important pour vos utilisateurs. La combinaison de preload (pour résoudre la découverte tardive) et de fetchpriority="high" (pour résoudre la congestion réseau) est la technique la plus puissante pour garantir que la ressource LCP est récupérée aussi tôt et aussi vite que 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 congestion réseau

Rationalisez les téléchargements initiaux en différant ou en appliquant le lazy loading aux assets non essentiels. Repoussez le chargement des images ou vidéos qui ne sont pas immédiatement visibles, ainsi que des éléments d'arrière-plan ou secondaires. Utiliser loading="lazy" pour les médias hors écran est un bon point de départ. Différer davantage d'autres scripts et assets non essentiels libérera de la bande passante. Cela réduira la concurrence avec vos ressources critiques et maintiendra un chargement rapide du contenu principal de votre page. N'appliquez jamais loading="lazy" à votre image LCP ; c'est un anti-pattern critique qui dégradera votre score.

4. Configurer les Speculation Rules

Speculation Rules permet aux navigateurs de pré-récupérer (prefetch) ou de pré-rendre (prerender) des pages web en fonction de la navigation prédite de l'utilisateur. Le prefetch élimine efficacement la sous-partie Time to First Byte du LCP. Il n'a aucun impact sur la durée de chargement de la ressource. Le prerendering génère le rendu de la page suivante dans un onglet masqué et télécharge toutes les ressources de la page. Cela élimine la majeure partie des durées de chargement pour l'élément LCP, comme le montre cet exemple d'analyse détaillée du LCP (LCP breakdown) d'une page pré-rendue.

Prochaines étapes : Continuer à optimiser le LCP

La durée de chargement de la ressource n'est qu'une des quatre phases du LCP. Après avoir optimisé le temps de téléchargement, poursuivez avec les autres phases du LCP :

• Identifier et corriger les problèmes LCP : La méthodologie de diagnostic complète pour trouver et corriger tous les problèmes LCP avec les field data et les outils de laboratoire.
• Optimiser l'image LCP : Sélection du format d'image, images responsives, preloading 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 peut l'afficher immédiatement en libérant le main thread.