Comment corriger le LCP sur mobile : un pas à pas

Ce que mesure réellement le LCP

Largest Contentful Paint est le temps écoulé entre le début de la navigation et la fin du rendu de la plus grande image ou du plus grand bloc de texte dans le premier viewport. Pas la page entière, pas chaque élément, pas le « chargement complet » : un seul élément, le plus grand que le visiteur voit sans faire défiler.

Le seuil est de 2,5 secondes ou moins pour une bonne évaluation. Entre 2,5 et 4,0 secondes, on parle de « à améliorer », et au-delà de 4,0 secondes, de mauvais. Point crucial : le chiffre qui compte est le 75e percentile des chargements réels sur mobile, et non le résultat d'un test sur votre ordinateur portable. Une page qui se charge en 1,2 seconde chez vous et en 5 secondes chez un visiteur sur un Android de milieu de gamme est une page en échec, car c'est le visiteur que Google mesure.

Il est utile de décomposer le LCP en ses quatre parties, car la correction dépend entièrement de la partie lente : le time to first byte, le délai avant que le navigateur commence à récupérer la ressource de l'élément, la durée de téléchargement de cette ressource, et le délai avant son rendu final. La plupart des corrections visent la deuxième partie.

INP et CLS, en bref

Les Core Web Vitals comptent trois métriques, et le LCP n’est que l’une d’elles. Interaction to Next Paint mesure la réactivité : le temps que met la page à réagir visiblement à un tap ou à un clic, sur l’ensemble des interactions d’une visite. Un bon résultat est de 200 millisecondes ou moins au 75e percentile. Cette métrique a remplacé First Input Delay en mars 2024, et elle est bien plus difficile à contourner, car elle porte sur les tâches longues du thread principal et non sur une seule interaction précoce. Cumulative Layout Shift mesure l’ampleur des déplacements de la page sous le doigt du lecteur ; un bon résultat est de 0,1 ou moins.

Les trois métriques interagissent, ce qui explique que corriger l’une isolément dégrade parfois une autre. Différer une feuille de style peut améliorer le LCP et provoquer un flash de contenu non stylé ; supprimer un décalage passe souvent par la réservation d’un espace, ce qui peut repousser le plus grand élément. Mesurez les trois après chaque modification.

Étape un : identifier l’élément LCP avant de toucher à quoi que ce soit

Vous ne pouvez pas corriger le LCP sans savoir quel élément est mesuré, et ce n’est généralement pas celui que vous imaginez. Il s’agit le plus souvent de l’image héros, parfois d’une image d’arrière-plan, et fréquemment du h1 ou d’un grand paragraphe de texte lorsque le texte s’affiche avant la fin du chargement de l’image. Sur une page rendue côté client, l’élément LCP est souvent quelque chose qui existe à peine dans le code HTML source.

Deux points à comprendre avant d’aller plus loin. Premièrement, l’élément diffère entre mobile et desktop, car la fenêtre d’affichage est plus étroite, la mise en page se recompose et les images recadrées par art direction sont remplacées via les media queries. Deuxièmement, le mobile est plus lent pour des raisons qui n’ont rien à voir avec votre code : un processeur plus lent, un cache plus froid et une connexion à latence plus élevée suffisent à faire franchir le seuil à la même page.

Obtenez la réponse via PageSpeed Insights, qui nomme l’élément LCP dans ses diagnostics, ou lisez-la directement dans le navigateur :

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log(last.element, Math.round(last.startTime), 'ms');
}).observe({ type: 'largest-contentful-paint', buffered: true });

Correctifs concrets pour chaque cause

Réduire le temps jusqu’au premier octet

Ajoutez un cache pleine page pour que les requêtes anonymes n’atteignent jamais l’application, puis un cache d’objets pour les requêtes de base de données qui subsistent, puis un cache en périphérie ou un CDN devant. Vérifiez les requêtes longues sur le chemin critique de la page et une base de données simplement trop petite pour le jeu de données actif. Sur un serveur auto-géré, le TTFB est généralement un problème de disque, de mémoire ou de configuration, et c’est pourquoi le travail au niveau de l’hébergement fait partie de la même discussion. Si votre offre manque de RAM sous un trafic normal, aucun réglage front-end ne sauvera la métrique, et passer à une offre NVMe KVM aux ressources prévisibles coûte moins cher que des mois de réglages.

Débloquer le rendu

Intégrez en ligne le CSS nécessaire au premier écran et chargez le reste sans blocage, via media et onload ou un preload suivi d’un swap. Ajoutez defer aux scripts qui n’ont pas besoin de s’exécuter avant l’affichage, et async uniquement lorsque l’ordre n’a réellement aucune importance. Auditez chaque entrée de tag manager et chaque script tiers : analytics, widgets de chat, heatmaps et outils A/B constituent souvent le premier coût de rendu restant, et la plupart peuvent attendre une interaction. Hébergez vos polices vous-même, utilisez font-display: swap et ne préchargez que la graisse utilisée au-dessus de la ligne de flottaison.

Corriger correctement l’image héros

Préchargez-la pour que la requête démarre pendant l’analyse du HTML plutôt qu’après la mise en page, servez de l’AVIF ou du WebP avec un fallback, fournissez un srcset pour qu’un téléphone ne télécharge jamais un fichier de taille desktop, et définissez toujours des width et height explicites ou un ratio d’aspect afin que l’espace soit réservé et que rien ne se décale.

Ne pas activer le lazy loading sur l’image LCP

C’est la blessure LCP la plus fréquente et la plus auto-infligée. Quelqu’un ajoute loading="lazy" à toutes les images du site, ce qui est correct pour les vingt images sous la ligne de flottaison et activement nuisible pour celle que Google chronomètre. Une image lazy n’est demandée qu’une fois que le navigateur a mis la page en page et déterminé que l’image est proche de la fenêtre d’affichage : vous avez donc ajouté un aller-retour complet de délai à l’élément qui avait le plus besoin d’être rapide.

Corrigez d’abord l’image LCP. Conservez le lazy loading partout ailleurs, où c’est un gain réel.

Sortir le premier écran du JavaScript

Rendez côté serveur ou générez statiquement le héros, son titre et son texte d’accompagnement pour qu’ils existent dans le HTML livré. Si le framework doit hydrater, gardez le héros hors du sous-arbre hydraté et préchargez les données dont il a besoin. Un héros qui apparaît au bout de 3 secondes parce qu’il attendait un bundle et un appel API relève d’un choix d’architecture de rendu, pas d’un problème de réglage, et doit être corrigé à ce niveau.

Comment tester : données terrain et données labo

Les données terrain proviennent de visiteurs réels, agrégées dans le Chrome User Experience Report et dans le rapport Core Web Vitals de la Search Console, exprimées au 75e percentile sur une fenêtre glissante de 28 jours et ventilées entre mobile et desktop. C’est le chiffre qui compte, car il reflète ce que les appareils réels ont réellement vécu, et c’est celui utilisé pour tout signal de recherche.

Les données labo correspondent à un chargement synthétique unique, généralement Lighthouse dans PageSpeed Insights, sur une machine rapide avec une connexion bridée et un cache vide. Elles ne peuvent pas vous dire ce que vivent vos utilisateurs, mais elles sont bien meilleures pour expliquer pourquoi : elles nomment l’élément LCP, listent les ressources bloquantes et affichent la cascade.

Ils divergent parce qu'ils mesurent des populations différentes. Les données terrain moyennent des milliers d'appareils, de réseaux et d'états de cache, y compris des visites répétées où tout est déjà en cache ; les données de laboratoire correspondent à un seul chargement à froid sur un téléphone simulé. Les données terrain utilisent aussi une logique de centiles : une page est validée lorsque 75 % des chargements sont inférieurs à 2,5 secondes, même si un quart de vos visiteurs attendent bien plus longtemps. Lisez-les ensemble : utilisez le laboratoire pour identifier la cause, puis confirmez sur le terrain que le correctif a fait évoluer le 75e centile. Comptez environ 28 jours de décalage avant qu'un correctif soit pleinement visible, et ne concluez pas qu'une modification a échoué au troisième jour.

La réserve honnête à propos des Core Web Vitals

Les Core Web Vitals départagent les résultats, ils ne sont pas une solution miracle pour le classement. Les réussir ne vous place pas au-dessus d'un concurrent au contenu plus fort, au maillage interne mieux pensé et aux liens plus pertinents. Les échouer ne vous coûte pas forcément les positions que vous occupez déjà. Considérez-les comme une hygiène nécessaire, non comme une stratégie de croissance, et soyez sceptique face à quiconque vend un projet de vitesse comme un projet de classement.

L'autre moitié de la réserve compte tout autant : un site rapide au contenu mince ne se classera toujours pas. Si une page met trois secondes à charger et répond mieux à la requête que tout ce qui la précède, elle l'emporte souvent malgré tout. Corrigez le LCP parce que les pages lentes perdent des visiteurs indépendamment de Google, parce que cela améliore la conversion et parce que cela supprime une raison facile d'être jugé moins bon qu'un concurrent. Ne le corrigez pas en vidant la page du contenu qui la rendait utile, et ne laissez pas une métrique dicter le design d'une page qui convertissait.

Questions fréquentes sur le LCP mobile

Pourquoi mon LCP est-il bon sur ordinateur et médiocre sur mobile ?

Parce que l'élément mesuré et les conditions changent tous les deux. Un viewport plus étroit recompose la mise en page et peut promouvoir un autre élément au rang de plus grand élément, la direction artistique peut servir une image différente, et l'appareil dispose d'un processeur bien plus lent et d'une connexion à latence plus élevée. Diagnostiquez toujours le mobile séparément et ne supposez jamais qu'un score obtenu sur ordinateur se transpose.

Faut-il précharger toutes les images de la page ?

Non. Le préchargement demande au navigateur de récupérer une ressource immédiatement et avec une priorité élevée ; précharger davantage que l'image LCP entre donc en concurrence avec la ressource même que vous cherchez à accélérer. Préchargez l'image héros et laissez le reste être découvert normalement.

Mon score PageSpeed est de 60 mais les données terrain sont conformes. Que faut-il corriger ?

Ce sont les données terrain qui reflètent vos visiteurs et qui servent à toute évaluation. Un score de laboratoire faible avec des données terrain conformes signifie généralement que le laboratoire simule un scénario que votre trafic réel ne connaît pas, souvent un cache froid. Utilisez le laboratoire pour diagnostiquer, pas pour rendre le verdict.

Le lazy-loading aide-t-il parfois le LCP ?

Rarement, et seulement indirectement. Il libère de la bande passante pour l'élément qui compte en empêchant les images sous la ligne de flottaison de lui faire concurrence. Appliqué à l'élément LCP lui-même, il nuit toujours, car il retarde le chargement d'au moins un cycle de mise en page.

Combien de temps après un correctif les données CrUX changent-elles ?

Les données terrain couvrent une fenêtre glissante de 28 jours : une modification s'y intègre progressivement et sa prise en compte complète demande environ un mois. Vérifiez le correctif immédiatement en laboratoire, puis confirmez-le sur le terrain au bout de quatre semaines plutôt que de retester le serveur chaque jour.

Quelle part du LCP relève de mon hébergement ?

Plus que ne l'admettent la plupart des guides front-end. Si le time to first byte dépasse 600 millisecondes, aucune optimisation d'image ou de script ne vous fera passer sous 2,5 secondes, car vous avez déjà consommé une large part du budget avant même que la page commence à arriver.