Raisonnement Proportionnel pour la Performance Web
Le goulot d'étranglement est la phase qui consomme la plus grande part du temps total. Pas la phase qui dépasse un seuil absolu.

Lighthouse vous donne un chiffre. Il ne vous dit pas si ce chiffre est le problème. Convertissez chaque phase en pourcentage du total. Le plus grand pourcentage est votre goulot d'étranglement. Pas la phase qui dépasse un certain seuil absolu. Cela change quelles corrections améliorent réellement vos Core Web Vitals.
Dernière révision par Arjen Karel en mars 2026
Le problème des seuils absolus
Lighthouse dit "Le Render Delay est de 350ms." Qu'en faites-vous ?
Si votre LCP total est de 700ms, oui, 350ms de Render Delay représentent la moitié du problème. Corrigez-le.
Mais si votre LCP total est de 4 200ms et que le TTFB est de 3 800ms, ces 350ms de Render Delay représentent 8 % du total. Le réduire à zéro fait gagner 350ms. Vous avez toujours un LCP de 3 850ms qui échoue. Les 90 % du problème viennent de votre serveur.
Les nombres absolus sans contexte conduisent à des efforts inutiles. Convertissez en pourcentages et le goulot d'étranglement devient évident.
Corrigez le plus grand pourcentage en premier
Le LCP et l'INP se décomposent tous deux en phases. Chaque phase consomme une part du total. La plus grande part est votre goulot d'étranglement. Corrigez celle-ci en premier.
Ce n'est pas compliqué. Mais il est surprenant de voir combien d'outils de performance, et maintenant d'agents IA, sautent cette étape et optimisent ce qui dépasse un seuil fixe.
Exemple de LCP
Le LCP sur vos pages produits mobiles : 3 820ms (médiocre). La répartition des phases provenant d'utilisateurs réels :
- TTFB : 420ms (11 %)
- Load Delay : 2 100ms (55 %)
- Load Time : 680ms (18 %)
- Render Delay : 620ms (16 %)
Réduire les 16 % de Render Delay à zéro fait gagner 620ms. Corriger le problème des 55 % de Load Delay fait gagner plus de 2 000ms. Les deux sont de vrais problèmes. L'un est le goulot d'étranglement.
Un Load Delay à 55 % signifie que le navigateur a reçu le HTML mais n'a pas demandé l'image hero pendant plus de deux secondes. Le navigateur ne trouve pas l'image. Elle n'est pas dans le HTML où le preload scanner peut la voir. Ajoutez une indication de preload et vous réduisez le LCP de près de la moitié.
Exemple d'INP
L'INP sur la page de paiement : 350ms (nécessite une amélioration). La répartition des phases :
- Input Delay : 70ms (20 %)
- Processing : 80ms (23 %)
- Presentation : 200ms (57 %)
Sans pourcentages, un agent optimise l'Input Delay car 70ms dépasse un certain seuil. Montrez-lui les pourcentages et il cible la Presentation. 57 % est l'endroit où le temps s'écoule.
Corriger la Presentation (DOM volumineux, CSS containment manquant, repaint coûteux) fait passer l'INP de 350ms à moins de 200ms. Cela vous fait passer de "nécessite une amélioration" à "bon". Réduire l'Input Delay de 70ms à 0ms (peu probable, mais hypothétique) fait gagner 70ms. Vous échouez toujours à 280ms. Même effort, résultat différent.
Que se passe-t-il lorsque les agents ignorent cela
Un agent IA sans contexte proportionnel fait ce que l'outil lui dit. Lighthouse signale un TBT long. L'agent optimise le TBT. La modification est techniquement correcte. L'impact dans le monde réel est minime car le TBT représentait 20 % du problème et le goulot d'étranglement de 57 % reste intact.
Je vois constamment ce schéma dans les corrections de performance générées par l'IA. La correction traite un symptôme. Le goulot d'étranglement demeure. Les données de terrain ne s'améliorent pas. Le développeur se demande pourquoi une optimisation "correcte" n'a rien fait.
Une approche vous fait perdre votre temps. L'autre corrige le vrai problème.
Comment faire cela sans CWV Superpowers
Vous pouvez le faire manuellement. Pour le LCP : ouvrez les Chrome DevTools, lancez une trace de performance, trouvez le marqueur LCP dans la chronologie, et mesurez les quatre phases. Convertissez chacune en un pourcentage du LCP total. Corrigez le pourcentage le plus élevé en premier.
Pour l'INP : utilisez l'extension Chrome Web Vitals ou un PerformanceObserver avec le type d'entrée event. Enregistrez l'interaction INP, obtenez la durée des trois phases, convertissez en pourcentages.
Ou laissez CWV Superpowers le faire automatiquement avec des données de terrain provenant de milliers de sessions réelles au lieu d'une seule trace de laboratoire.
CoreDash has MCP built in.
Connect it to Claude or any AI agent. Ask it why your INP spiked last Tuesday.
See how it works
