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

Un Largest Contentful Paint lent a quatre causes possibles. Un agent IA connecté aux données terrain peut identifier lequel est votre véritable goulot d'étranglement, le tracer dans Chrome, et générer le correctif. Voici le flux de travail complet de diagnostic du LCP avec 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 différentes 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 ne corrigez pas le serveur.

Load Delay est le délai entre la réception du HTML et la requête de la ressource LCP par le navigateur. C'est le problème de découverte. Si l'image 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 avant de découvrir qu'il en a besoin.

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

Render Delay est le délai entre la fin du téléchargement de la ressource et le moment où le navigateur la peint réellement à l'écran. Scripts bloquant le rendu, chargement de polices web, ou JavaScript manipulant le DOM avant que l'élément LCP ne devienne visible.

Trouver le goulot d'étranglement avec le raisonnement proportionnel

Lighthouse vous dit "Le LCP est de 3,8 secondes." C'est le total. Il ne vous dit pas quelle phase corriger.

CWV Superpowers obtient la répartition des phases à partir des données terrain de CoreDash et l'interprète proportionnellement. Le goulot d'étranglement est la phase consommant la plus grande part du temps total. Non pas la phase dépassant un seuil absolu.

Exemple concret. Le LCP est de 3 800 ms sur les pages produits mobiles. La répartition provenant des utilisateurs réels :

• TTFB : 600 ms (16 %)
• Load Delay : 1 900 ms (50 %)
• Load Time : 800 ms (21 %)
• Render Delay : 500 ms (13 %)

Le Load Delay est le goulot d'étranglement. La moitié du temps LCP total correspond à l'attente du navigateur pour découvrir que l'image existe. Un audit Lighthouse dirait simplement "3,8 secondes" et suggérerait de compresser les images. La compression d'images corrige le Load Time, qui représente 21 % du problème. Le vrai correctif se trouve dans les 50 %.

Pour une explication complète de cette approche, consultez le raisonnement proportionnel pour la performance 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 n'a pas su qu'il avait besoin de l'image hero avant bien 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 différé (lazy loading) que le navigateur respecte avec trop de zèle.

Ouvrez la trace de Chrome. Vous verrez un large espace dans la cascade réseau (waterfall) entre l'arrivée du HTML et le déclenchement de la requête de l'image. Cet espace 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 a le HTML mais n'a aucune idée qu'il a besoin de l'image hero.

L'agent voit le même espace. Il fait correspondre la cascade réseau à 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 racine : L'image 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 : espace de 1 940 ms entre le premier octet HTML et la requête de l'image dans la cascade réseau.

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

Correctifs typiques par phase

Load Delay : Ajoutez une indication de préchargement dans le <head>. Définissez fetchpriority="high" sur l'image LCP. Déplacez l'image d'un 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 correspondre à la taille d'affichage réelle. Ajoutez un srcset responsive pour que les utilisateurs mobiles ne téléchargent pas une image de la taille d'un bureau. Voir optimiser les images pour les Core Web Vitals.

Render Delay : Supprimez ou différez les scripts bloquant le rendu qui s'exécutent avant que l'élément LCP ne devienne visible. Vérifiez font-display sur les polices web affectant l'élément textuel LCP. Utilisez les 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 les 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érifier le correctif

Après le déploiement, interrogez les données terrain de CoreDash pour la même page et le même segment d'appareil. Les données terrain se mettent à jour à mesure que les utilisateurs réels 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 de la phase de goulot d'étranglement devrait changer.

C'est l'étape qui sépare les correctifs basés sur les données terrain des devinettes de Lighthouse. Vous n'espérez pas que le correctif a fonctionné. Vous le voyez dans les chiffres des utilisateurs réels.