Corriger le LCP avec un agent IA : des données de terrain au correctif de code

Un Largest Contentful Paint lent a quatre causes possibles. Un agent IA connecté aux données de terrain peut identifier laquelle constitue votre véritable goulot d'étranglement, la tracer dans Chrome et générer le correctif. Voici le flux de travail complet de diagnostic du LCP en utilisant CWV Superpowers.

Dernière révision par Arjen Karel en mars 2026

Les quatre phases du LCP

Google divise le LCP en quatre phases. Chacune a des causes et des correctifs différents.

TTFB est le temps écoulé entre le début de la navigation et le premier octet de la réponse HTML. Serveurs lents, CDN manquant, absence de mise en cache, requêtes de base de données longues. Si le TTFB est le goulot d'étranglement, rien d'autre ne compte tant que vous n'avez pas corrigé le serveur.

Load Delay est l'écart entre la réception du HTML et la requête du navigateur pour la ressource du LCP. C'est le problème de découverte. Si l'image du LCP est dans un arrière-plan CSS, chargée via JavaScript ou enfouie derrière une chaîne de redirections, le navigateur ne peut pas commencer à la récupérer tant qu'il n'a pas découvert qu'il en a besoin.

Load Time est le temps que prend la ressource du LCP pour se télécharger une fois demandée. Images volumineuses, compression manquante, CDN lent, absence de srcset responsive.

Render Delay est l'écart entre la fin du téléchargement de la ressource et le moment où le navigateur l'affiche réellement à l'écran. Render-blocking scripts, chargement de polices web, ou JavaScript qui manipule le DOM avant que l'élément du LCP ne devienne visible.

Trouver le goulot d'étranglement avec un raisonnement proportionnel

Les données publiques sur les Core Web Vitals ne sont pas suffisantes pour vous aider à trouver les vrais problèmes avec vos Core Web Vitals.  Lighthouse exécute un test synthétique sur un Moto G Power simulé et rapporte un temps de LCP. CrUX agrège 28 jours de données réelles de Chrome en une seule valeur p75 par URL. Aucun des deux ne vous dit quoi corriger.

C'est encore pire : aucun ne peut segmenter de manière significative. CrUX combine les pages vues mises en cache, non mises en cache, les nouvelles visites et les rechargements de page en un seul p75. Ceux-ci devraient être traités comme des problèmes distincts. Les pages vues en cache pourraient avoir un goulot d'étranglement au niveau du TTFB dû à la validation d'un cache obsolète. Les rechargements de page pourraient masquer un problème de découverte de ressource où le navigateur trouve l'image du LCP tardivement à chaque visite. Le p75 mélangé masque les deux.

CrUX a ajouté des sous-parties de LCP en 2025, ce qui aide. Mais c'est toujours un p75 sur 28 jours sans aucun filtrage par élément, viewport ou autre. Vous voyez les proportions des phases pour "tous les visiteurs de cette URL au cours du mois dernier". Vous ne voyez pas ce qui se passe sur le type d'appareil spécifique, le pays ou le modèle de page où réside le problème.

Les données RUM segmentent selon toutes ces dimensions. CWV Superpowers interroge ces données segmentées et les interprète proportionnellement. Le goulot d'étranglement est la phase qui consomme la plus grande part du temps total pour le segment spécifique qui échoue. Pas une moyenne dénuée de sens ou une simulation de Lighthouse. Des données réelles !

Exemple concret. Le LCP est de 3 800 ms sur les pages de produits mobiles. La répartition issue d'utilisateurs réels pour les premiers visiteurs sur des pages vues en cache :

• TTFB: 600ms (28.7%)
• Load Delay: 1,900ms (44.6%)
• Load Time: 800ms (19.3%)
• Render Delay: 500ms (7.4%)

Le Load Delay est le goulot d'étranglement évident. La moitié du temps total du LCP correspond à l'attente du navigateur pour découvrir que l'image existe. Lighthouse, CrUX ou une investigation manuelle auraient eu beaucoup de mal à trouver cette combinaison exacte de caractéristiques de visiteurs qui a causé ce problème.

Pour une explication complète de cette approche, consultez le raisonnement proportionnel pour les performances web.

Pourquoi le navigateur trouve votre image en retard

Le Load Delay est le goulot d'étranglement du LCP le plus courant que je rencontre. Cela signifie que le navigateur a reçu le HTML mais ne savait pas qu'il avait besoin de l'image hero avant beaucoup plus tard.

Trois causes courantes. L'image est une image d'arrière-plan CSS invisible pour le preload scanner. L'URL de l'image est construite en JavaScript. Ou bien l'image est techniquement dans le HTML mais possède un attribut de chargement paresseux (lazy loading) que le navigateur respecte avec trop de zèle.

Ouvrez la trace de Chrome. Vous verrez un grand écart dans la cascade réseau (network waterfall) entre l'arrivée du HTML et le déclenchement de la requête de l'image. Cet écart est votre Load Delay. Sur les sites que j'audite, il est de 1 500 à 2 500 ms sur mobile. Deux secondes complètes où le navigateur possède le HTML mais n'a aucune idée qu'il a besoin de l'image hero.

L'agent voit le même écart. Il associe la cascade à la répartition de CoreDash et vous dit exactement pourquoi l'image était en retard.

À quoi ressemble le diagnostic

Voici à quoi ressemble la sortie :

Cause identifiée par l'IA : L'image du LCP div.hero-banner > img.product-main sur /product/running-shoes-42 est découverte avec 1 980 ms de retard car il lui manque une indication de préchargement (preload) et n'a pas de fetchpriority="high". Données CoreDash : Le LCP est de 3 820 ms (médiocre) sur mobile, p75. Le Load Delay est le goulot d'étranglement à 52 % du total. La trace Chrome le confirme : écart de 1 940 ms entre le premier octet HTML et la requête de l'image dans la cascade réseau.

C'est tout le diagnostic. L'agent a trouvé le fichier, a écrit le diff. Vous le vérifiez et vous le déployez.

Correctifs typiques par phase

Load Delay : Ajoutez une indication de préchargement (preload) dans le <head>. Définissez fetchpriority="high" sur l'image du LCP. Déplacez l'image de l'arrière-plan CSS ou de JavaScript vers le HTML où le preload scanner peut la trouver.

Load Time : Convertissez en WebP ou AVIF. Réduisez les dimensions de l'image pour qu'elles correspondent à la taille d'affichage réelle. Ajoutez un srcset responsive afin que les utilisateurs mobiles ne téléchargent pas une image de la taille d'un bureau. Voir l'optimisation des images pour les Core Web Vitals.

Render Delay : Supprimez ou différez les scripts bloquant le rendu (render-blocking scripts) qui s'exécutent avant que l'élément du LCP ne devienne visible. Vérifiez font-display sur les polices web affectant l'élément de texte du LCP. Utilisez 103 Early Hints pour livrer le CSS plus tôt.

TTFB : Ajoutez un CDN. Activez la mise en cache côté serveur. Réduisez le temps de requête de la base de données. Utilisez 103 Early Hints pour permettre au navigateur de commencer à précharger les ressources pendant que le serveur génère encore la réponse.

Vérification du correctif

Après le déploiement, interrogez les données de terrain de CoreDash pour la même page et le même segment d'appareil. Les données de terrain se mettent à jour à mesure que de vrais utilisateurs chargent la page. Je vérifie généralement après 24 à 48 heures de trafic. Le p75 du LCP devrait baisser, et la distribution des phases de goulot d'étranglement devrait se déplacer.

C'est la différence entre corriger un chiffre et corriger l'expérience. Vous n'attendez pas 28 jours pour une mise à jour de CrUX ou ne relancez pas Lighthouse en espérant que le score a augmenté. Vous voyez l'amélioration dans les chiffres réels des utilisateurs, sur l'appareil et les segments de réseau où se trouvait le problème.

Pour le diagnostic de l'INP (la métrique qui ne peut pas être mesurée en laboratoire), le même flux de travail segmenté s'applique. Pour un aperçu plus large de la façon dont les agents IA utilisent les données de terrain par rapport aux données de laboratoire sur les trois Core Web Vitals, consultez le débogage des Core Web Vitals par un agent IA.