Optimiser le LCP (Largest Contentful Paint) sous 2,5 secondes

Sur la page d’accueil de la coopérative Niani, le plus gros élément visible est la bannière qui montre les paniers tressés. C’est la première chose qu’un visiteur attend de voir — et c’est précisément celle qui met quatre secondes à apparaître sur mobile. Tant que cette image ne s’affiche pas, l’utilisateur fixe un écran à moitié vide et se demande si le site fonctionne. Le Largest Contentful Paint mesure exactement ce moment : l’instant où le contenu principal devient visible. Ce tutoriel vous apprend à le faire tomber sous la barre des 2,5 secondes, étape par étape.

🎯 Ce que vous allez apprendre

• Identifier précisément quel élément de votre page est le LCP, sans deviner.
• Décomposer le LCP en quatre sous-parties pour savoir où se perd le temps.
• Prioriser correctement l’image principale avec fetchpriority et le préchargement.
• Éliminer les ressources qui bloquent l’affichage (CSS et JavaScript).
• Réduire le temps de réponse du serveur (TTFB), souvent la part cachée du problème.

🛠️ Ce que vous allez construire

Vous partez d’une page d’accueil dont la bannière met plus de quatre secondes à s’afficher sur mobile, et vous la ramenez sous 2,5 secondes au 75ᵉ centile. À chaque étape, vous appliquez une correction et vous re-mesurez l’impact, jusqu’à ce que l’image principale de Niani apparaisse quasi instantanément, même sur une connexion lente.

Prérequis

• Savoir lancer un audit Lighthouse et lire le LCP — voir le tutoriel Mesurer la performance web.
• Accès au code HTML de votre page (la balise de la bannière, l’en-tête).
• Google Chrome à jour pour l’onglet Performance des outils de développement.
• Niveau : intermédiaire léger. Si vous savez écrire une balise <img> et un <link>, vous suivrez sans peine.
• ⏱️ Temps estimé : ~45 minutes.

Étape 1 — Identifier l’élément LCP

Optimiser le LCP sans savoir quel élément le porte, c’est tirer dans le noir. La première chose à faire est donc de l’identifier formellement. Le LCP est le plus grand élément de contenu visible dans la fenêtre au chargement : le plus souvent une image, parfois un grand bloc de texte ou une vidéo.

Ouvrez les outils de développement, onglet Performance, et enregistrez un chargement de la page (bouton recharger-et-profiler). Dans la trace, repérez le marqueur LCP ; en le survolant, Chrome surligne l’élément exact sur la page et l’affiche dans le détail. Lighthouse fait la même chose plus simplement : son audit « Élément Largest Contentful Paint » nomme directement le coupable.

<!-- Sur la page Niani, l'élément LCP est cette bannière -->
<img src="/img/banniere-paniers.jpg" alt="Paniers tressés de la coopérative">

Une fois l’élément connu, tout devient concret : si c’est une image, on travaille sur sa priorité et son poids ; si c’est un bloc de texte, on travaille sur la police et le CSS qui le retardent. Dans le cas de Niani, c’est l’image de bannière — gardons-la en ligne de mire.

✅ Point d’étape — Vous pouvez nommer votre élément LCP. Notez-le : toutes les optimisations suivantes le visent directement.

Étape 2 — Décomposer le LCP en quatre sous-parties

Le LCP n’est pas un bloc opaque : il se décompose en quatre temps successifs, et savoir lequel domine vous dit quoi corriger. Cette grille de lecture, c’est ce qui sépare le bricolage de l’optimisation méthodique.

D’abord le temps de réponse du serveur (TTFB) : le délai avant que le premier octet du document n’arrive. Ensuite le délai de chargement de la ressource : le temps entre l’arrivée du HTML et le moment où le navigateur commence enfin à télécharger l’image LCP. Puis la durée de chargement de la ressource : le téléchargement de l’image elle-même. Enfin le délai de rendu : le temps entre la fin du téléchargement et l’affichage effectif à l’écran.

Dans la grande majorité des cas, le coupable est le deuxième temps — le délai avant que le navigateur ne décide de charger l’image. Le navigateur découvre tardivement la bannière, ou la traite comme peu prioritaire, et perd de précieuses centaines de millisecondes. C’est exactement ce que les étapes 3 et 4 vont corriger.

✅ Point d’étape — Regardez votre trace : quelle sous-partie domine ? Si c’est le délai de chargement, vous êtes au bon endroit ; si c’est le TTFB, sautez d’abord à l’étape 6.

Étape 3 — Prioriser l’image LCP

Par défaut, le navigateur ne sait pas que votre bannière est l’élément le plus important de la page. Il la découvre en lisant le HTML, l’ajoute à une file d’attente, et lui donne souvent une priorité moyenne. Notre travail : lui dire explicitement « celle-ci d’abord ».

Le levier le plus simple est l’attribut fetchpriority directement sur l’image. Et la règle absolue, son corollaire : ne jamais mettre loading="lazy" sur l’image LCP. Le chargement différé est excellent pour les images sous la ligne de flottaison, mais catastrophique sur la bannière — il retarde volontairement ce qu’on veut afficher en premier.

<!-- On signale au navigateur que cette image est prioritaire... -->
<img src="/img/banniere-paniers.jpg"
     alt="Paniers tressés de la coopérative"
     fetchpriority="high"
     width="1200" height="600">
<!-- ...et surtout PAS de loading="lazy" ici -->

Pour gagner encore, on peut précharger l’image dans l’en-tête du document, afin que le navigateur la télécharge avant même d’avoir fini de lire la page. On ajoute aussi un preconnect vers le domaine qui sert l’image si elle vient d’un CDN distinct, pour amortir la négociation de connexion.

<!-- Dans le <head>, le plus haut possible -->
<link rel="preconnect" href="https://cdn.niani.example">
<link rel="preload" as="image"
      href="https://cdn.niani.example/img/banniere-paniers.jpg"
      fetchpriority="high">

Après ce changement, rechargez et regardez la trace : le délai de chargement de la ressource doit fondre, car le navigateur attaque l’image bien plus tôt. C’est souvent l’optimisation au meilleur rapport effort/gain de tout le tutoriel.

✅ Point d’étape — Votre image LCP porte fetchpriority="high" et n’a pas loading="lazy". Re-mesurez : le LCP devrait déjà avoir baissé de plusieurs centaines de millisecondes.

Étape 4 — Alléger l’image LCP

Prioriser une image trop lourde, c’est précipiter le téléchargement d’un fichier de 800 Ko : on a gagné sur le départ, pas sur la durée. La quatrième étape attaque la durée de chargement : le poids du fichier.

Trois leviers se combinent. Le format moderne d’abord : une bannière en AVIF pèse souvent deux à trois fois moins qu’un JPEG de qualité équivalente, le WebP offrant un compromis très bien supporté. Les dimensions adaptées ensuite : inutile de servir une image de 2400 pixels de large à un téléphone qui en affiche 400 ; l’attribut srcset laisse le navigateur choisir la bonne taille. La compression enfin : un outil comme Squoosh ou la bibliothèque sharp ramène le poids sans dégradation visible.

<picture>
  <source type="image/avif"
          srcset="/img/banniere-400.avif 400w,
                  /img/banniere-800.avif 800w,
                  /img/banniere-1200.avif 1200w"
          sizes="100vw">
  <img src="/img/banniere-800.jpg"
       alt="Paniers tressés de la coopérative"
       fetchpriority="high"
       width="1200" height="600">
</picture>

Le détail complet du choix des formats, du dimensionnement et de la compression fait l’objet du tutoriel Optimiser les images et les polices. Pour le LCP, retenez l’essentiel : une image principale doit être au bon format, à la bonne taille, et bien compressée — avant même d’être priorisée.

✅ Point d’étape — Votre bannière pèse une fraction de son poids initial et se décline en plusieurs tailles. La durée de chargement de la ressource doit avoir chuté.

Étape 5 — Supprimer les ressources bloquantes

Même priorisée et allégée, votre image ne s’affichera pas si le navigateur est occupé à télécharger une feuille de style ou un script qui bloque le rendu. Le CSS et le JavaScript placés dans l’en-tête sont bloquants par défaut : le navigateur attend de les avoir traités avant de peindre quoi que ce soit.

Pour le CSS, la technique est d’inliner le CSS critique — les quelques règles nécessaires à l’affichage de la partie haute de la page — directement dans le document, et de charger le reste de façon non bloquante. Pour le JavaScript, on ajoute defer (ou on utilise type="module", différé par nature) afin qu’il n’interrompe pas l’affichage.

<!-- Script non bloquant : il s'exécute après l'affichage -->
<script src="/js/app.js" defer></script>

<!-- Feuille de style non critique chargée sans bloquer -->
<link rel="stylesheet" href="/css/reste.css" media="print" onload="this.media='all'">

La technique media="print" est une astuce classique : le navigateur considère d’abord la feuille comme destinée à l’impression (donc non bloquante pour l’écran), puis l’active une fois chargée. L’audit Lighthouse « Éliminer les ressources qui bloquent le rendu » liste précisément les fichiers à traiter.

✅ Point d’étape — Lighthouse ne signale plus de ressource bloquante majeure, ou leur impact estimé est tombé sous 100 ms. Le délai de rendu se resserre.

Étape 6 — Réduire le temps de réponse du serveur

Si la décomposition de l’étape 2 montrait un TTFB élevé, aucune optimisation d’image ne suffira : le chronomètre tourne avant même que le HTML n’arrive. Cette étape s’attaque à la racine.

Le premier réflexe est la mise en cache : une page générée à chaque visite par un CMS est lente ; servie depuis un cache (page statique ou cache serveur), elle répond en quelques dizaines de millisecondes. Le second est le réseau de diffusion de contenu (CDN) : il rapproche vos fichiers de l’utilisateur. Pour un visiteur à Cotonou, recevoir la page depuis un nœud régional plutôt que depuis un serveur en Europe peut retrancher 200 à 400 millisecondes.

Enfin, méfiez-vous du rendu côté client : si votre élément LCP n’apparaît qu’après l’exécution d’un gros script JavaScript qui construit la page dans le navigateur, le LCP attendra ce script. Servir le contenu principal en HTML dès la réponse du serveur — rendu côté serveur ou page statique — fait souvent la plus grosse différence.

✅ Point d’étape — Votre TTFB est sous ~600 ms en conditions réelles. Si c’est le cas, les sous-parties suivantes du LCP ont enfin de l’air pour respirer.

Étape 7 — Vérification finale

Reprenez la mesure de départ et comparez. Relancez Lighthouse en mode Mobile, puis vérifiez la trace de l’onglet Performance : le marqueur LCP doit maintenant tomber sous 2,5 secondes en laboratoire. Si vous avez du trafic, surveillez dans les jours qui suivent le 75ᵉ centile du LCP sur le terrain via PageSpeed Insights — c’est lui le juge final.

Faites le bilan des leviers actionnés : élément identifié, image priorisée et préchargée, fichier allégé au bon format, ressources bloquantes neutralisées, serveur accéléré. Chacun grignote une part du temps ; ensemble, ils transforment l’expérience. La bannière de Niani apparaît désormais presque aussitôt, même sur une 3G fatiguée.

🐞 Pièges fréquents

🌍 Réalités du terrain

Le LCP est la métrique qui souffre le plus des connexions lentes, et donc celle qui compte le plus pour un public ouest-africain. Sur une 3G à Ouagadougou ou Kankan, chaque kilo-octet de la bannière se paie en attente visible. Deux décisions ont ici un impact démesuré : choisir un format d’image moderne (AVIF ou WebP) pour diviser le poids, et héberger les images sur un CDN doté de points de présence proches — plusieurs offres gratuites en proposent en Afrique et en Europe du Sud, suffisamment proches pour faire la différence.

Pensez aussi au coût des données. Une bannière de 200 Ko au lieu de 800 Ko, ce n’est pas qu’un LCP plus rapide : ce sont des francs CFA de forfait économisés à chaque visite. Sur un catalogue qui présente des dizaines d’articles, l’addition est réelle pour vos clients comme pour la perception de votre marque.

✅ Récapitulatif

Vous savez maintenant attaquer le LCP de façon méthodique : l’identifier, le décomposer en quatre temps, puis corriger chacun — priorité et préchargement de l’image, allègement du fichier, suppression des ressources bloquantes, réduction du TTFB. Cette discipline « mesurer, décomposer, corriger, re-mesurer » est exactement celle que vous réappliquerez sur l’INP et le CLS dans les tutoriels suivants.

🧾 Aide-mémoire

💪 À vous de jouer

Sur votre page, ajoutez fetchpriority="high" et un preload sur l’image principale, puis comparez la trace Performance avant/après. Mesurez de combien le délai de chargement de la ressource a diminué.

Dans la même série

• Mesurer la performance web — identifier le LCP et suivre son évolution.
• Optimiser les images et les polices — alléger l’image LCP en profondeur.

Pour aller plus loin

• 🔝 Retour au guide principal : Core Web Vitals et performance web.
• Documentation officielle : web.dev — Optimize LCP.

FAQ

Comment savoir si mon LCP est une image ou du texte ?
L’audit Lighthouse « Élément Largest Contentful Paint » et le marqueur LCP de l’onglet Performance surlignent l’élément exact. Si c’est du texte, l’optimisation passe surtout par la police ; si c’est une image, par sa priorité et son poids.

Le préchargement peut-il nuire ?
Oui, si vous préchargez trop de ressources : vous diluez la priorité et entrez en concurrence avec l’image LCP. Préchargez une seule ressource vraiment critique — l’image principale — et rien d’autre par réflexe.

Faut-il un CDN pour avoir un bon LCP ?
Pas obligatoirement, mais cela aide beaucoup quand vos visiteurs sont géographiquement éloignés du serveur. Pour un public régional servi par un hébergement lointain, un CDN avec des nœuds proches est l’un des meilleurs investissements sur le TTFB.