LCP lent : le diagnostic en 30 minutes, avant de toucher au code

Pourquoi un LCP lent n'est presque jamais un problème de serveur.

Parce que dans la très grande majorité des cas, l'élément qui déclenche le LCP est une image, et que le temps perdu l'est avant même que le navigateur ait su qu'il devait la télécharger. Le Web Almanac 2025, construit sur les données publiques du HTTP Archive de juillet 2025, mesure que l'élément LCP est une image sur 85,3 % des pages desktop et 76 % des pages mobile. Le réflexe qui consiste à augmenter la puissance du serveur dès qu'un LCP dépasse 3 secondes traite donc rarement la bonne cause.

Le scénario type se répète de boutique en boutique. Une page produit affiche un visuel principal servi par un carrousel JavaScript. Le HTML initial ne contient aucune balise image : le navigateur reçoit la page, exécute le script, construit le carrousel, puis découvre enfin l'image à charger. Pendant ce temps, le serveur a déjà répondu depuis longtemps. Le TTFB est excellent, le LCP est catastrophique, et les deux chiffres ne se contredisent pas. Ils décrivent deux moments différents.

Cette confusion a un coût concret. Elle envoie une équipe technique sur un chantier d'infrastructure de plusieurs semaines quand le correctif tient en trois attributs HTML. Avant d'ouvrir un ticket de développement, il faut donc savoir où exactement les secondes se perdent. C'est l'objet de la décomposition ci-dessous, et c'est un travail qui prend trente minutes, pas trois jours. Le même raisonnement vaut pour les pages de destination que vous payez au clic : nous l'avons abordé sous l'angle de l'arbitrage éditorial dans landing page ou page de service pour votre trafic payant.

Les quatre segments qui composent un LCP, et leur budget.

Google décompose le LCP en quatre segments consécutifs qui couvrent l'intégralité de la mesure, sans trou ni recouvrement, et publie pour chacun un pourcentage cible. Cette répartition est la pièce la plus utile de toute la documentation performance, et c'est aussi la moins reprise. Elle transforme une plainte vague, la page est lente, en une question à réponse unique : lequel des quatre segments dépasse son budget.

Deux enseignements sortent de ce tableau. Le premier : 80 % du budget est accordé au serveur et au téléchargement, c'est-à-dire à des choses qui coûtent de l'argent à améliorer. Le second, plus intéressant : les deux segments à moins de 10 % sont ceux qui dérapent le plus souvent, et ce sont aussi les moins chers à corriger. Un délai de découverte à 45 % du LCP total est un cas banal. Il ne se répare pas avec un serveur plus puissant, il se répare en rendant l'image visible dans le HTML initial.

Le diagnostic en 30 minutes, dans l'ordre.

L'ordre compte autant que les étapes. Chacune élimine une hypothèse et conditionne la suivante, ce qui évite de corriger trois choses à la fois et de ne jamais savoir laquelle a produit l'effet. Prévoyez une URL précise, pas un site entier, et le même appareil de référence du début à la fin.

1. 1Minutes 0 à 5 : lire la donnée de terrain avant tout scoreOuvrez le rapport Signaux web essentiels de la Search Console. Notez la valeur LCP au 75e percentile, le statut du groupe d'URL, et distinguez mobile et desktop. La Search Console regroupe les pages à expérience similaire et attribue au groupe le statut de sa métrique la plus faible. Vous ne diagnostiquez donc pas une page isolée, vous diagnostiquez un gabarit.
2. 2Minutes 5 à 10 : identifier l'élément LCP réel, pas celui que vous croyezPassez l'URL exacte dans PageSpeed Insights, ou ouvrez l'onglet Performance des outils de développement de Chrome. L'outil nomme l'élément retenu. Dans huit cas sur dix ce sera une image, mais pas forcément celle que vous aviez en tête : un bandeau de cookies, une bannière promotionnelle ou un bloc de texte peuvent tenir ce rôle. Tant que l'élément n'est pas identifié, toute optimisation est un pari.
3. 3Minutes 10 à 15 : mesurer le TTFB et le comparer à 0,8 secondeLe seuil d'un bon TTFB est de 0,8 seconde ou moins, au 75e percentile, et un TTFB supérieur à 1,8 seconde est considéré comme mauvais. Si vous êtes au-dessus de 0,8 seconde, le premier chantier est serveur, cache ou redirections, et il est inutile de regarder la suite avant de l'avoir traité. Si vous êtes en dessous, le serveur est hors de cause : passez à l'étape suivante sans y revenir.
4. 4Minutes 15 à 20 : vérifier la découverte de la ressourceC'est l'étape qui paie le plus. Affichez le code source initial de la page, celui que le serveur renvoie, et cherchez la ressource LCP. Trois questions : est-elle présente dans ce HTML initial, porte-t-elle un attribut loading=lazy, est-elle injectée par un script. Un oui à la deuxième ou à la troisième question explique à lui seul la plupart des LCP à plus de 4 secondes.
5. 5Minutes 20 à 25 : peser la ressource, puis regarder le renduRelevez le poids réel du fichier téléchargé, son format et ses dimensions affichées par rapport à ses dimensions natives. Une image servie en 2 400 pixels de large pour un affichage à 600 pixels gaspille les trois quarts de son temps de transfert. Puis regardez ce qui se passe après le téléchargement : une feuille de style bloquante ou un rendu entièrement côté client repoussent l'affichage alors que l'image est déjà là.
6. 6Minutes 25 à 30 : écrire une seule hypothèse, et son testUne phrase, pas un rapport : le segment X représente Y % du LCP au lieu de son budget de Z %, la cause probable est A, le correctif est B. Un seul correctif par déploiement. Mesurez l'effet en laboratoire immédiatement, et en données de terrain après quatre semaines pleines, le temps que la fenêtre glissante se renouvelle. Cette discipline de test isolé est la même que celle que nous appliquons en optimisation du taux de conversion.

Données de terrain ou données de laboratoire : lesquelles font foi.

Les données de terrain font foi, les données de laboratoire servent à diagnostiquer et à itérer vite. Les deux sont utiles, elles ne répondent simplement pas à la même question, et les confondre est la deuxième cause d'erreur après le délai de découverte. Un site peut afficher 95 sur 100 à PageSpeed Insights et rester classé médiocre dans la Search Console, sans qu'aucun des deux outils ne soit en faute.

Exemple chiffré : un LCP à 4,1 secondes, décomposé.

Voici un cas construit, avec des hypothèses volontairement lisibles. Ce ne sont les chiffres d'aucun client : ce sont des ordres de grandeur destinés à faire apparaître la mécanique. Remplacez-les par les vôtres, la méthode ne change pas.

• •LCP mesuré au 75e percentile sur mobile : 4,1 secondes, statut médiocre
• •TTFB : 0,7 seconde, soit 17 % du total, pour un budget indicatif d'environ 40 %
• •Délai de découverte de la ressource : 1,9 seconde, soit 46 %, pour un budget de moins de 10 %
• •Durée de chargement de la ressource : 1,2 seconde, soit 29 %, pour un budget d'environ 40 %
• •Délai de rendu de l'élément : 0,3 seconde, soit 7 %, dans le budget

1. 1.Le serveur est hors de cause. À 0,7 seconde, le TTFB est sous le seuil de 0,8 seconde. Toute dépense d'hébergement sur ce cas aurait été une dépense perdue.
2. 2.Un seul segment dépasse son budget, et il le dépasse d'un facteur supérieur à quatre : le délai de découverte, à 46 % au lieu de moins de 10 %.
3. 3.Le code source initial confirme le diagnostic : l'image principale n'est pas dans le HTML renvoyé par le serveur, elle est ajoutée par le script du carrousel, et elle porte un attribut loading=lazy hérité du thème.
4. 4.Le correctif tient en trois gestes : sortir l'image du carrousel et la placer en dur dans le HTML initial, retirer l'attribut de chargement différé sur cette image et sur elle seule, ajouter fetchpriority=high.
5. 5.Si le délai de découverte retombe à 0,2 seconde, l'arithmétique donne un LCP autour de 2,4 secondes. C'est une arithmétique, pas une promesse : le chiffre réel dépend des trois autres segments, qui bougent eux aussi quand l'ordre de chargement change.
6. 6.Le rapport de la Search Console, lui, ne bougera pas avant plusieurs semaines. La fenêtre glissante de 28 jours contient encore l'ancienne version de la page.

Ce que cet exemple illustre dépasse le cas particulier. Le Web Almanac 2025 mesure que 16 % à 17 % des pages chargent en différé leur propre image LCP, dont 11,5 % sur desktop et 10,4 % sur mobile par l'attribut natif. En face, fetchpriority=high n'est présent que sur 16,3 % des pages desktop et 17,3 % des pages mobile, et le préchargement explicite sur 2,1 % à 2,2 %. Autrement dit, autant de sites freinent leur image principale qu'il n'y en a pour l'accélérer. Sur un site e-commerce, où la fiche produit est le gabarit le plus visité, l'écart se paie sur des milliers de pages d'un coup.

Limites, erreurs fréquentes et cas où ce diagnostic ne s'applique pas.

• •Un bon LCP ne fait pas vendre. Google indique que les Core Web Vitals, avec les autres aspects de l'expérience de page, rejoignent ce que ses systèmes de classement cherchent à valoriser, et recommande de viser un LCP dans les 2,5 premières secondes. Cela ne veut pas dire qu'un passage de 4 à 2 secondes déplace des positions à lui seul. Le contenu et la pertinence restent devant. Attendre un bond de trafic de ce seul chantier mène à la déception.
• •Sans trafic, pas de données de terrain. Les pages et origines doivent être publiquement accessibles et suffisamment visitées pour figurer dans le CrUX. Un site à faible audience n'aura ni rapport Search Console exploitable ni donnée CrUX : il faudra se contenter du laboratoire et d'une mesure côté utilisateur installée sur le site.
• •Le LCP n'est qu'une des trois Core Web Vitals. Les seuils de bon sont de 2,5 secondes pour le LCP, 200 millisecondes pour l'INP et 0,1 pour le CLS. La Search Console attribue au groupe d'URL le statut de sa métrique la plus faible : réparer le LCP sans regarder les deux autres ne change parfois rien au verdict affiché.
• •Vous diagnostiquez un gabarit, pas une page. Le regroupement par expérience similaire fait qu'un correctif appliqué à une seule URL ne déplacera pas le statut du groupe. Corrigez le modèle de page, la fiche produit ou l'article, pas l'exemplaire sur lequel vous avez fait le test.
• •Sur Shopify ou un CMS à thème, la marge est contrainte. Une partie du HTML est produite par le thème et par les applications installées, et l'attribut de chargement différé y est souvent appliqué globalement. Le chantier devient alors un arbitrage entre performance et fonctionnalités installées. C'est une discussion que nous ouvrons systématiquement sur les projets Shopify.
• •Ne corrigez pas quatre choses à la fois. C'est l'erreur la plus coûteuse, parce qu'elle rend l'apprentissage impossible : vous gagnez une seconde et vous ne saurez jamais laquelle des quatre modifications l'a produite. La rigueur de test vaut ici ce qu'elle vaut en expérimentation A/B.

Ce qu'on recommande.

1. 1.Commencer par la donnée de terrain au 75e percentile, jamais par un score global. Le score est un outil de chantier, pas un indicateur de pilotage.
2. 2.Décomposer systématiquement le LCP en quatre segments avant d'ouvrir le moindre ticket, et confronter chaque segment à son budget indicatif.
3. 3.Vérifier en priorité le délai de découverte de la ressource LCP : présence dans le HTML initial, absence de chargement différé sur cette image, priorité de récupération élevée.
4. 4.Traiter le gabarit et non la page, en vérifiant l'effet sur l'ensemble du groupe d'URL concerné.
5. 5.Déployer un correctif à la fois, et accepter d'attendre quatre semaines pleines avant de juger l'effet sur les données de terrain.
6. 6.Inscrire la valeur LCP au 75e percentile dans le tableau de bord mensuel, à côté des indicateurs d'acquisition, et non dans un rapport technique que personne n'ouvre.

La performance web souffre d'un mal de famille : elle est mesurée par des outils techniques, et arbitrée par des budgets qui ne le sont pas. La décomposition en quatre segments est ce qui permet de faire tenir la conversation en une phrase devant un dirigeant : voilà où partent les secondes, voilà ce que coûte de les récupérer, voilà ce que ça ne réglera pas. C'est le même principe que celui qui gouverne nos chantiers de tracking et data et l'ensemble de notre méthode. Chez Connexion., un chiffre qu'on ne sait pas décomposer n'est pas un chiffre sur lequel on engage un budget.