LCP : décomposer le temps de chargement en quatre parties

LCP : décomposer avant de corriger

1. Ce que LCP mesure exactement

   LCP — Largest Contentful Paint — mesure le temps entre le début du chargement de la page et l'affichage du plus grand élément de contenu visible dans la fenêtre d'affichage. En pratique : une image, un bloc de texte, une vidéo.

   Trois précisions qui changent les chiffres

   • Un seul élément compte : le plus grand, pas le plus important. Une bannière décorative de 1200 × 400 pixels peut être l'élément LCP d'une page dont le titre est le contenu réel.
   • On ne mesure pas la page, on mesure un élément. L'identification de l'élément LCP est la première étape de toute optimisation — DevTools l'affiche directement.
   • Seuil 2,5 s au 75ᵉ percentile, mobile et desktop séparément. Le chiffre est stable et sert de référence depuis l'introduction des Core Web Vitals.

   Un piège fréquent : la bannière comme LCP

   Sur un site institutionnel, l'élément LCP est très souvent une image de bannière ou une illustration d'en-tête — pas le titre. Toute l'optimisation porte alors sur la bonne cible, mais pas sur celle qu'on imaginait. C'est aussi une question de conception : une image de bannière lourde est un mauvais choix, et le diagnostic performance et le diagnostic graphique arrivent à la même conclusion.

   Le LCP est-il lisible dans le HTML ?

   Si l'élément LCP est une image dont la source est injectée par JavaScript après le chargement, le moteur de recherche et l'utilisateur attendent tous les deux deux choses. Le lien vers le cours `seo` est fait ici : c'est la même cause qu'un problème d'indexation, et la même correction — mettre l'image dans le HTML initial.

2. Les quatre sous-parties, et leurs temps

   Le temps LCP se décompose en quatre segments. Ce découpage est le cœur du module : il transforme « LCP est trop élevé » en « le délai de chargement de la ressource est de 1,8 seconde, voilà le problème ».

   Sous-partie	Part indicative	Nature
   Temps de réponse du premier octet (TTFB)	≈ 40 %	Réseau + serveur
   Délai de chargement de la ressource	< 10 %	Attente évitable
   Durée de chargement de la ressource	≈ 40 %	Taille et distance
   Délai de rendu de l'élément	< 10 %	Attente évitable

   Comment lire ce tableau

   Deux des quatre lignes contiennent le mot « délai ». C'est le signal : ce sont les deux segments qu'il faut ramener à zéro, parce qu'ils ne représentent aucun travail utile. Les deux autres sont du temps de travail réel — transfert réseau, calcul serveur — qui se réduit en optimisant la ressource ou l'infrastructure.

   La documentation est explicite sur un point : ces proportions sont des repères, pas des lois. Si votre LCP est déjà sous 2,5 s de façon constante, la répartition importe peu. Si vous êtes à 4 s et que 2,5 secondes partent en délais, aucun travail sur la taille de l'image ne vous ramènera dans le seuil.

   Le test en une question

   Si la réponse est « le délai de chargement de la ressource » ou « le délai de rendu », le problème est dans le code ou le gabarit, et il se corrige localement. Si la réponse est « le TTFB », le problème est côté serveur ou réseau — et il se corrige autrement, souvent par un cache ou une proximité géographique.

3. Les deux délais : les corriger en premier

   Délai de chargement de la ressource : l'image démarre tard

   C'est le délai entre le début de la page et le moment où le navigateur commence à télécharger l'image LCP. Trois causes, trois corrections.

   • L'image n'est pas dans le HTML initial — elle est injectée par JavaScript. Correction : la sortir du JavaScript, la mettre dans le balisage.
   • L'image porte loading="lazy" — alors que c'est précisément l'image visible immédiatement. Le chargement différé ne doit jamais s'appliquer à l'élément LCP : le navigateur doit d'abord vérifier si l'image est dans la fenêtre, ce qui retarde le téléchargement.
   • L'image est découverte trop tard, après la feuille de style qui la référence. Correction : la déclarer plus tôt dans le flux HTML.

   Délai de rendu de l'élément : l'image est là, mais ne s'affiche pas

   La ressource est chargée, mais l'élément n'est pas affiché. Quatre causes, de la plus fréquente à la plus rare.

   1. Le rendu de la page est bloqué par une feuille de style ou un script synchrone encore en chargement.
   2. L'élément n'est pas encore dans le DOM — il attend un script, ou il est masqué par une condition.
   3. Un script tiers le masque — une bibliothèque de test A/B qui attend son verdict avant d'afficher la page, ou une bannière de consentement qui le recouvre.
   4. Le fil principal est bloqué par des tâches longues. Tous les navigateurs affichent les images sur le fil principal : même une image entièrement téléchargée attend que le JavaScript en cours ait fini. C'est le point le plus contre-intuitif du cours, et il relie directement au module INP.

   La correction la plus rentable : fetchpriority

   Si l'image LCP est bien dans le HTML mais doit attendre sa place dans la file de téléchargement, on lui donne la priorité : fetchpriority="high" sur le <img> ou le <link>. L'attribut augmente sa priorité et elle reçoit plus de bande passante pendant que les autres ressources attendent.

   La documentation est précise sur le rendement : parmi les pages éligibles, une minorité seulement utilisent cet attribut, alors que l'effort est faible et l'effet immédiat. C'est un des rares cas où le gain est élevé et le coût proche de zéro.

4. Durée de chargement et TTFB : le poids, la distance, le cache

   Durée de chargement de la ressource

   C'est le temps de transfert réel des octets. Quatre leviers, du plus rentable au plus lourd.

   • Réduire la taille. Format moderne, dimensions adaptées à l'affichage, pas d'image à 4 000 pixels dans un conteneur de 400. C'est le levier le plus efficace et le plus souvent négligé.
   • Réduire la distance. Un serveur plus proche de l'utilisateur — c'est le rôle d'un CDN. Utile surtout quand le TTFB est mauvais.
   • Réduire la contention. Trop de requêtes en parallèle se disputent la bande passante disponible. Charger dix polices avant de charger la photo principale est un choix contre-intuitif et coûteux.
   • Supprimer le temps réseau. Un cache navigateur bien réglé rend la deuxième visite quasi instantanée. C'est la meilleure performance, celle qui ne coûte rien à l'utilisateur.

   La documentation nuance honnêtement : la durée de chargement est rarement le goulot d'étranglement pour la plupart des sites. Il faut donc mesurer la répartition avant de s'y attaquer — sinon on réduit une image de 30 % alors que le problème est ailleurs.

   Temps de réponse du premier octet

   Le TTFB est le délai avant que le premier octet de la réponse ne parvienne au navigateur. Il est indiqué en dernier dans la documentation parce que c'est souvent le levier dont le développeur Dispose le moins — mais il est aussi celui qui débloque tous les autres : rien ne peut se passer côté navigateur tant que le premier octet n'est pas arrivé.

   Les causes et les corrections : cache serveur, proximité géographique, nombre de requêtes SQL, temps de génération des pages. Sur une application à rendu serveur, une requête qui prend 800 ms sur chaque page est un défaut de LCP déguisé.

   Naviguer sans recharger : deux opportunités

   • Le cache de retour arrière et avant (bfcache) recharge instantanément une page depuis l'historique. Une page qui y est éligible obtient un LCP quasi nul au retour. La condition la plus fréquente d'inéligibilité : un en-tête no-store, ou un gestionnaire unload qui est d'ailleurs obsolète.
   • Le pré-rendu de la page suivante probable — anticiper la navigation la plus probable rend la page suivante instantanée. La prudence est requise : une spéculation erronée consomme des ressources des deux côtés, donc on ne pré-rend que ce dont les données de navigation donnent la certitude.