Optimiser 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 nécessaire pour télécharger la ressource LCP sur le réseau. Même si le délai de chargement de la ressource représente souvent une part plus importante du LCP, optimiser la durée de téléchargement reste indispensable pour obtenir 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 Core Web Vitals qui mesurent l'expérience utilisateur en ligne. Le LCP mesure le temps nécessaire pour que le plus grand élément de contenu (image, vidéo ou bloc de texte) devienne visible dans le viewport. La durée de chargement de la ressource est une sous-partie du LCP qui indique le temps passé à récupérer la ressource réseau de 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 durée de chargement, 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 du téléchargement jusqu'à sa fin complète par le navigateur. Pour les éléments LCP textuels, cette durée est généralement de zéro. Le guide d'optimisation du LCP de Google décompose le LCP en quatre sous-parties séquentielles, la durée de chargement correspondant 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 la déterminent :

• Taille du fichier : un fichier plus lourd nécessite un temps de téléchargement plus long.
• Vitesse du réseau : une connexion lente allonge mécaniquement la durée de chargement.
• Réactivité du serveur : un retard dans la réponse du serveur ralentit la récupération de la ressource.
• Téléchargements simultanés : les ressources téléchargées en parallèle se disputent la bande passante, ce qui augmente le temps de chargement.

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

Deux méthodes efficaces permettent d'identifier et de mesurer la durée de chargement de la ressource :

Inspection réseau dans les DevTools Chrome : utilisez le raccourci Ctrl + Maj + I pour ouvrir les outils de développement de Chrome, sélectionnez l'onglet « Network » et rechargez la page. Repérez l'élément LCP parmi les requêtes réseau (pour identifier facilement l'élément LCP, essayez le Core Web Vitals Visualizer). L'inspecteur réseau indique le temps nécessaire au téléchargement de la ressource.

Conseil d'expert : activez les grandes lignes de requête pour afficher des détails supplémentaires comme la latence du LCP, la taille transférée et la taille réelle.

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

Les outils RUM enregistrent souvent les données d'attribution du LCP. Ces données d'attribution contiennent des informations sur la durée de chargement de la ressource. Grâce à elles, vous pouvez tracer l'évolution de la durée de chargement au fil du temps ou par page, et repérer les pages ou les éléments qui ralentissent l'affichage.

Guide étape par étape : pour une mesure lab data précise, enregistrez une trace dans le panneau Performance. L'insight de répartition du LCP affiche la durée de chargement de la ressource aux côtés des trois autres sous-parties. Guide complet : Diagnostiquer le LCP avec le panneau Performance des DevTools Chrome.

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

Les problèmes de durée de chargement surviennent quand les ressources sont trop volumineuses ou empruntent un chemin réseau sous-optimal. Deux approches permettent de les traiter : réduire la taille des données ou optimiser leur acheminement.

1. Optimiser la taille des fichiers

Optimiser la taille des fichiers réduit le nombre d'octets transférés 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 pour savoir comment optimiser les images.

Utiliser des formats d'image modernes

AVIF et WebP offrent la meilleure compression d'image. Sur les photos complexes, AVIF permet d'obtenir des fichiers jusqu'à 50 % plus légers que WebP, sans perte de qualité visible. WebP bénéficie d'une prise en charge plus large par les navigateurs et convient parfaitement aux images plus simples. D'après le Web Almanac 2025, WebP est désormais utilisé pour plus de 40 % des requêtes d'images, tandis que l'adoption d'AVIF a presque doublé d'une année sur l'autre, tout en restant sous la barre des 10 %.

Choisir le bon niveau de qualité

Les formats modernes comme WebP et AVIF tolèrent une réduction importante de la qualité avant que la dégradation visuelle ne devienne perceptible. En règle générale, un niveau de qualité compris entre 75 et 85 pour WebP, et entre 60 et 75 pour AVIF, donne un rendu identique à l'original à distance normale de lecture, pour une fraction du poids du fichier. Testez toujours avec vos propres images : la qualité optimale dépend du type de contenu (photos, illustrations ou images contenant beaucoup de texte).

Automatiser la compression d'images avec Sharp

Pour optimiser les images au moment 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 nécessaire
  .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 responsive
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 prenant en charge les formats modernes. Sur WordPress, des extensions comme ShortPixel ou Imagify gèrent cette conversion automatiquement lors de l'upload.

Images responsive

L'élément <picture> et l'attribut srcset permettent de fournir des images adaptées à l'écran : versions réduites sur mobile, haute résolution sur grand écran. 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>

Adapter les dimensions des images

Le responsive ne résout qu'une partie du problème, car une image responsive n'est pas forcément dimensionnée correctement. Faire correspondre les dimensions de l'image à sa taille d'affichage réelle reste l'une des erreurs les plus fréquentes que je constate. Envoyer une image de 2 000 px de large pour un affichage de 500 px gaspille de la bande passante et ralentit nettement le temps de chargement.

Optimiser les fichiers de polices

Lorsque l'élément LCP est un texte affiché avec une police web personnalisée, le fichier de police devient la ressource LCP. Pour réduire sa durée de chargement :

• Utilisez le format WOFF2 : WOFF2 offre la meilleure compression pour les polices web, avec des fichiers généralement 30 % plus légers que WOFF et nettement plus compacts que les formats TTF ou OTF.
• Réduisez le jeu de caractères (subsetting) : si votre site n'utilise que des caractères latins, supprimez les jeux de caractères inutiles (cyrillique, grec, CJK). Des outils comme glyphhanger ou pyftsubset automatisent cette tâche et réduisent souvent le poids de la police de 50 % ou plus.
• Limitez les variantes : chaque graisse et chaque style (regular, bold, italic) implique le téléchargement d'un fichier distinct. Ne chargez que les graisses réellement utilisées par votre design.

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 à s'en affranchir totalement.

Éviter le réseau grâce au cache du navigateur

La connexion réseau la plus rapide est celle dont on se passe. Le navigateur peut servir le contenu statique (images, scripts, feuilles de style) directement depuis son 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 ce type :

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

• public : autorise la mise en cache de la ressource par le navigateur 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 au fil du temps, ce qui évite les requêtes de revalidation inutiles.

Pour appliquer cette stratégie en toute sécurité, utilisez des noms de fichiers basés sur un hash de leur contenu (par exemple hero-abc123.webp). Dès que l'image est modifiée, son nom change, ce qui invalide automatiquement le cache.

Compression Brotli vs Gzip

Pour les ressources textuelles (HTML, CSS, JavaScript, SVG), la compression côté serveur est indispensable. Brotli, développé par Google, surpasse systématiquement Gzip en taux de compression tout en conservant une vitesse de décompression comparable. Le tableau suivant illustre cette différence :

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

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

Le protocole de transfert prend toute son importance lorsque le navigateur télécharge plusieurs ressources en parallèle.

• HTTP/2 a introduit le multiplexage, permettant d'envoyer plusieurs requêtes et réponses simultanément sur une seule connexion TCP. Cela élimine le problème de blocage en tête de file (head-of-line blocking) d'HTTP/1.1, où une ressource lente pouvait retarder toutes les autres. HTTP/2 prend également en charge la compression des en-têtes (HPACK) et le server push.
• HTTP/3 va encore 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ù un seul paquet perdu bloque tous les flux), accélère l'établissement de la connexion grâce au 0-RTT (reprise sans temps d'aller-retour pour les visiteurs réguliers) et gère mieux la perte de paquets. Ces améliorations réduisent avant tout le Time to First Byte, mais elles diminuent aussi la durée de chargement de la ressource.

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

Content Delivery Networks (CDN)

Un CDN est un réseau de serveurs distribués qui mettent en cache et fournissent des ressources statiques comme les images, les CSS et le 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 diminue directement la durée de chargement de la ressource.

Au-delà de la proximité, les CDN modernes offrent plusieurs avantages de performance pour réduire 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 distribuent automatiquement du WebP ou de l'AVIF en fonction de l'en-tête Accept du navigateur.
• Mise en cache à l'edge : les ressources statiques sont stockées sur des nœuds edge à travers le monde, évitant complètement les requêtes vers 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 modification côté serveur.
• Réutilisation de la connexion : comme le CDN sert toutes les ressources depuis un même domaine, le navigateur réutilise une connexion unique, éliminant le surcoût lié aux multiples résolutions DNS et handshakes TLS.

Les CDN d'images spécialisés vont encore plus loin en proposant des optimisations automatiques en temps réel, comme la conversion de format, le redimensionnement et la compression.

Auto-héberger les ressources

Par défaut, les ressources réseau critiques et prioritaires doivent toujours être hébergées sur le serveur d'origine. L'auto-hébergement évite de se connecter à des serveurs tiers, qui provoquent des délais considérables en raison des résolutions DNS, des négociations SSL et de l'établissement des connexions supplémentaires. Il garantit la réutilisation d'une connexion unique déjà ouverte et supprime la surcharge liée à l'ouverture 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 priorité des ressources

Une fois le poids des ressources réduit et le réseau optimisé, reste la question de la concurrence réseau. Lorsque le navigateur demande plusieurs ressources en même temps sur une connexion lente, celles-ci se disputent la bande passante. Réduisez cette concurrence en planifiant le téléchargement des ressources.

Prioriser les ressources critiques

Attribuez fetchpriority="high" aux ressources essentielles, comme l'image hero ou le CSS au-dessus de la ligne de flottaison. Cela indique au navigateur de télécharger ces assets en premier, sans les laisser ralentir par des scripts, des widgets ou des éléments tiers qui n'ont pas besoin d'un chargement instantané. Prioriser ces ressources critiques réduit le temps de chargement du contenu qui compte le plus pour vos utilisateurs. L'association du preload (pour résoudre la découverte tardive) et de fetchpriority="high" (pour résoudre la contention réseau) constitue la méthode la plus puissante pour récupérer la ressource LCP 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 réseau

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

4. Mettre en place les Speculation Rules

Les Speculation Rules permettent au navigateur d'anticiper la navigation de l'utilisateur pour précharger (prefetch) ou pré-rendre (prerender) des pages web. Le prefetch élimine la sous-partie Time to First Byte du LCP et n'a aucun impact sur la durée de chargement de la ressource. Le prerendering génère la page suivante dans un onglet masqué et télécharge l'ensemble de ses ressources. Cela élimine la quasi-totalité de la durée de chargement de l'élément LCP, comme l'illustre cet exemple de décomposition du LCP d'une page pré-rendue.

Étapes suivantes : continuer à optimiser le LCP

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

• Identifier et corriger les problèmes de LCP : la méthodologie de diagnostic complète pour détecter et corriger tous les problèmes de LCP à l'aide des field data et des outils de lab data.
• Optimiser l'image LCP : choix du format d'image, images responsive, préchargement et erreurs fréquentes d'optimisation d'image.
• Délai de chargement de la ressource : assurez-vous que le navigateur découvre la ressource LCP le plus tôt possible. C'est souvent un goulet d'étranglement plus important que la durée de chargement elle-même.
• Délai d'affichage de l'élément : une fois la ressource téléchargée, veillez à ce que le navigateur puisse l'afficher immédiatement en libérant le main thread.