Core Web Vitals sur un site construit par un agent
Code rapide, pages lentes. Les trois seuils, les erreurs précises qu'un agent commet sur chacun, et pourquoi une capture prise après stabilisation ne voit pas le décalage de mise en page.
Un agent écrit du code rapide et livre tout de même des pages lentes. Parce que la performance n'est pas une propriété de la source mais de ce que le navigateur fait de la source, et presque rien de ce qu'un agent observe depuis une session ne l'en informe. L'écart se révèle comme un site qui passe tous les contrôles que vous avez lancés et obtient un mauvais score la première fois que quelqu'un mesure correctement.
Les trois métriques et les seuils qui comptent
Core Web Vitals, c'est trois nombres, et les trois sont jugés au 75e centile des visites réelles, pas sur votre portable. Ce centile est la partie que l'on saute, et il change ce qu'il faut optimiser: une page rapide pour vous et lente pour un quart des visiteurs échoue.
| Métrique | Bon | Ce qu'un agent rate d'ordinaire |
|---|---|---|
| Largest Contentful Paint | 2,5 secondes ou moins | Une image hero sans priorité ni dimensions |
| Cumulative Layout Shift | 0,1 ou moins | Des embeds sans dimensions et une police qui bascule tard |
| Interaction to Next Paint | 200 millisecondes ou moins | Une page entière rendue interactive pour un seul interrupteur |
LCP: c'est presque toujours l'image hero
Sur un site vitrine, le plus grand élément au-dessus de la ligne de flottaison est une photo: le LCP est donc un problème de chargement d'image déguisé en métrique. L'agent qui construit la page prendra le composant image du framework et fera l'essentiel correctement, puis manquera le seul attribut qui compte: le hero doit être marqué comme prioritaire pour ne pas être chargé paresseusement comme tout ce qui suit.
Deux autres récurrentes. Une valeur de qualité non autorisée sur le composant image renvoie une erreur de l'optimiseur et casse l'image sans aucun échec de build, un défaut que nous avons livré. Et un hero servi à sa résolution native sur un téléphone coûte une seconde pour rien, car le navigateur télécharge des pixels qu'il jette ensuite. La référence du composant image couvre les deux.
CLS: le swap de police et l'embed sans dimensions
Le décalage de mise en page est la métrique qu'un agent est le moins équipé pour remarquer, car elle est invisible dans l'état final. La page a l'air correcte une fois tout stabilisé, et tout le défaut s'est produit pendant la stabilisation. Deux causes expliquent presque tout sur un site vitrine: une police web chargée après le premier rendu qui refait couler le titre, et tout élément intégré sans dimensions déclarées, c'est-à-dire cartes, vidéos et widgets tiers.
Les deux se corrigent en une ligne chacune, et aucune ne le sera sans mesure, car un agent à qui l'on demande si la page a l'air correcte prendra une capture après stabilisation et répondra oui en toute sincérité.
INP: l'interactivité que personne n'a demandée
Interaction to Next Paint mesure le temps que met la page à répondre à un appui. Sur un site de contenu, ce devrait être sans effort, et ce qui gâche cela est une page devenue interactive pour une petite chose. Un menu mobile, une barre d'onglets, un accordéon: chacun est une fonctionnalité raisonnable, et chacun peut tirer toute la route vers le rendu client si la frontière du composant est tracée négligemment.
C'est le cas où un agent a besoin d'une règle plutôt que d'un arbitrage, car la frontière du composant paraît arbitraire vue de l'intérieur du fichier. La nôtre: l'interactivité est une feuille. Le plus petit composant possible est l'interactif, et il ne contient jamais de contenu. Cette seule ligne dans les instructions du projet a évité plus de travail de performance que toute optimisation que nous avons faite, l'argument que défend l'article sur CLAUDE.md en général.
Les chiffres de laboratoire sont une hypothèse, ceux du terrain un verdict
Un audit local analyse une page, une fois, sur votre matériel, via votre connexion. Il sert à trouver des causes et ne sert à rien pour juger si vous avez un problème. Lighthouse est explicite sur son statut d'outil de laboratoire, et PageSpeed Insights affiche les données de visites réelles à côté du passage de laboratoire précisément pour que vous puissiez les voir diverger.
La séquence qui marche: trouver les causes en local et juger l'amélioration sur les données de terrain quelques semaines plus tard. Attendre que le chiffre de terrain bouge le jour du déploiement est la façon la plus courante de conclure que le travail de performance ne sert à rien.
Mesurez dans un navigateur qui composite
Une note chèrement acquise. Tous les environnements où un agent peut voir une page ne la rendent pas comme un navigateur. Chez nous, un titre a passé chaque mesure prise tout en étant visiblement cassé à l'écran, parce que l'outillage rapportait des valeurs calculées depuis un moteur qui n'avait jamais composité la couche. Si la question est la performance ou la mise en page, vérifiez dans un vrai navigateur à une vraie largeur. Le reste est une hypothèse, la leçon même de la vérification du travail de l'agent.
Verrouillez-le, sinon il reviendra
La performance régresse en silence, un composant à la fois, et un agent réintroduira les mêmes motifs six semaines plus tard parce que rien dans le dépôt ne l'en dissuade. Le remède est celui de tout défaut récurrent: écrire la règle là où elle est lue, et la verrouiller là où la vérification est bon marché. Une ligne sur les frontières interactives, une sur les images hero, et un contrôle sur la sortie construite. L'article sur les hooks couvre la barrière, la liste SEO couvre le reste à vérifier au lancement, et si vous préférez ne rien lancer vous-même, c'est notre raison d'être.
