LCP sur mobile : l'image héro est rarement le coupable

Le diagnostic est presque toujours le même quand une équipe s’attaque à un mauvais temps d’affichage sur mobile : l’image héro est lourde, il faut l’optimiser. On la convertit dans un format moderne, on produit des variantes responsives, on divise son poids par trois. Puis on remesure, et le chiffre a bougé de 100 ms sur un total de 4 secondes. La conclusion qu’on en tire est souvent que la mesure est peu fiable. En réalité, l’optimisation a parfaitement fonctionné — elle a simplement porté sur le segment qui ne comptait pas.

Le temps d’affichage du plus grand élément est une mesure composite. Elle additionne quatre durées successives, et la dernière — celle du téléchargement de la ressource — est la seule sur laquelle porte le réflexe d’optimisation. Sur la majorité des pages que j’audite, ce n’est pas celle qui domine.

Les quatre segments qui composent le LCP

Il vaut la peine de les nommer précisément, parce que la répartition entre eux détermine entièrement ce qu’il faut faire.

Le premier est le temps de réponse du serveur : l’intervalle entre la demande du navigateur et l’arrivée du premier octet. Aucun rendu n’est possible avant. Sur une page rendue dynamiquement, ce segment absorbe l’exécution du gabarit, les appels aux services de commerce, les requêtes en base. Il est fréquemment le poste dominant, et il est invisible pour un outil qui n’analyse que le contenu de la page.

Le deuxième est la durée de blocage du rendu. Après le premier octet, le navigateur lit le document et rencontre des ressources qu’il considère indispensables avant de peindre : feuilles de style, scripts synchrones. Tant qu’elles ne sont pas résolues, l’écran reste vide, quelle que soit la légèreté des images.

Le troisième est le délai de découverte. Le navigateur ne peut demander une ressource qu’après avoir appris son existence. Si l’image héro est déclarée dans une feuille de style, injectée par un script, ou portée par un composant qui s’hydrate côté client, sa requête ne part que tardivement. Ce segment est le plus souvent ignoré et il est régulièrement le plus long.

Le quatrième seulement est le temps de chargement de la ressource — le seul que l’optimisation d’image améliore.

Segment	Ce qu’il mesure	Ce qui le corrige
1. Réponse serveur (TTFB)	Requête → premier octet	Cache, pré-génération, réduction des appels amont
2. Blocage du rendu	Premier octet → premier pixel	CSS critique embarqué, scripts non bloquants
3. Découverte de la ressource	Premier pixel → départ de la requête LCP	Déclaration dans le HTML, préchargement
4. Chargement	Départ → fin de la requête LCP	Le seul segment que l’optimisation d’image améliore

Sur la majorité des pages que j’audite, les segments 1 à 3 représentent l’essentiel du total. C’est pourquoi diviser par trois le poids d’une image ne déplace presque rien.

Le relevé qui prend 5 minutes

Avant toute intervention, je fais le même relevé, et il ne demande aucun outil particulier : une chronologie réseau, sur un chargement mobile avec bridage du processeur et du réseau, à froid.

On note quatre instants : l’arrivée du premier octet, le premier rendu à l’écran, le départ de la requête de l’élément LCP, et sa fin. Les écarts entre ces quatre repères donnent la répartition exacte des quatre segments.

Ce relevé règle la question en 5 minutes et il évite de consacrer deux semaines au mauvais segment. Il révèle aussi, assez souvent, que l’élément LCP n’est pas celui qu’on croyait — un bloc de texte, un bandeau promotionnel, ou la surcouche de consentement.

Optimiser sans avoir décomposé la mesure, c’est traiter la partie visible du problème parce qu’elle est visible. L’image héro a l’immense défaut d’être la seule chose qu’on voit.

Le bandeau de consentement, coupable récurrent

Il mérite une section à lui seul, parce qu’il concentre plusieurs des défauts décrits plus haut et qu’il est presque toujours hors du champ de l’audit.

L’implémentation typique charge un script depuis un domaine tiers, de manière bloquante ; ce script interroge parfois un service de géolocalisation pour déterminer le régime applicable ; il calcule ensuite quelle version du bandeau afficher ; puis il peint une surcouche.

Chacune de ces étapes ajoute de la latence avant le contenu réel. Et il arrive fréquemment que la surcouche devienne elle-même le plus grand élément visible de la page — auquel cas la mesure ne décrit plus l’affichage du contenu mais celui du bandeau, ce qui rend toute optimisation du contenu sans effet sur le chiffre.

Les corrections sont connues et rarement appliquées : charger le script de manière non bloquante, peindre le bandeau localement avec du style embarqué plutôt que d’attendre le tiers, et éviter que la surcouche ne couvre une grande surface. Sur les pages où ce problème existe, il vaut à lui seul 200 à 500 ms.

Quand le texte est l’élément le plus grand

Sur une page éditoriale, une fiche produit à grand titre, ou une page de collection sobre, l’élément LCP est fréquemment un bloc de texte. Le facteur limitant change alors complètement de nature.

Ce qui retient le rendu est la police de caractères. Si elle est chargée depuis un domaine tiers, il faut résoudre le nom de domaine, établir la connexion sécurisée, télécharger une feuille de style, puis découvrir seulement à ce moment l’adresse du fichier de police. Et si la configuration d’affichage masque le texte pendant ce temps, alors le LCP attend la fin de toute cette chaîne.

Les corrections sont simples et leur effet est immédiat : auto-héberger la police pour supprimer une connexion externe, la précharger pour supprimer le délai de découverte, et permettre l’affichage immédiat avec une police de secours, quitte à accepter une substitution visible. Aucune de ces actions ne touche aux images.

Le rendu côté client, plafond invisible

Reste le cas où le contenu principal n’existe pas dans le document initial parce qu’il est produit par du code côté client. Le navigateur reçoit alors une page vide ou squelettique, doit télécharger le code, l’exécuter, faire les requêtes de données, et seulement ensuite peindre.

Sur un appareil mobile de milieu de gamme, l’exécution du code représente à elle seule un temps considérable, et il n’existe aucune optimisation d’image capable de le compenser. Ce cas impose un changement d’architecture : rendre côté serveur, ou pré-générer statiquement les pages critiques. C’est un chantier plus lourd, mais c’est le seul qui déplace le plafond.

Un dernier avertissement sur la mesure

Un point d’hygiène pour finir, parce qu’il fausse beaucoup de décisions.

Le LCP mesuré en laboratoire est une valeur unique, obtenue dans des conditions choisies. Le LCP réel est une distribution, produite par des appareils, des réseaux et des localisations très divers. La valeur qui compte est le 75e centile du terrain, pas la valeur du laboratoire.

Ces deux mesures ne servent pas au même usage, et les confondre conduit soit à optimiser un environnement fictif, soit à ne pas pouvoir bloquer une régression avant qu’elle n’atteigne la production¹. Le laboratoire sert à empêcher la dégradation ; le terrain sert à décider où porter l’effort. Un écart important entre les deux n’est pas une anomalie de mesure : c’est l’information la plus utile de tout l’audit.

---

Footnotes

1. Sur l’articulation entre mesure de laboratoire opposable en intégration continue et mesure de terrain servant à réviser les seuils, voir Un budget de performance sert à refuser des fonctionnalités et Core Web Vitals 2026 : pourquoi la quasi-totalité des sites Shopify Plus échouent à INP. ↩