Prima Pagina.
EN

7 juin 2026Le moteur

Mesurer LCP, INP et CLS à l’échelle de milliers de pages

Notre infrastructure de mesure CWV repose sur Lighthouse CLI en mode headless, exécuté sur un échantillon rotatif de 200 pages par semaine, couvrant l’ensemble du corpus en 20 semaines. Les résultats sont stockés en base de données time-series et comparés aux seuils Good/Needs Improvement/Poor de Web.dev.

Pourquoi l’échantillonnage est préférable à la mesure exhaustive

Mesurer 4 000 pages avec Lighthouse en mode Lab prend environ 6 heures sur un serveur dédié (5,4 secondes par page en moyenne). Ce coût est trop élevé pour une mesure hebdomadaire. L’échantillonnage de 200 pages par semaine, avec rotation déterministe basée sur le numéro de semaine ISO, couvre l’intégralité du corpus en 20 semaines pour un coût de 18 minutes par exécution.

La rotation est déterministe pour permettre la comparaison dans le temps : la page mesurée en semaine 1 sera remesurée en semaine 21, pas en semaine 3. Cette propriété est essentielle pour distinguer une dégradation réelle d’un simple changement d’échantillon.

Seuils d’alerte et escalade

Trois seuils sont surveillés par page : LCP inférieur à 2,5 secondes (Good), INP inférieur à 200 ms (Good), CLS inférieur à 0,1 (Good). Une page qui passe de Good à Needs Improvement sur deux mesures consécutives déclenche une alerte de niveau 1 (notification Slack). Une page en Poor sur une seule mesure déclenche une alerte de niveau 2 (email + ticket automatique).

Les alertes de niveau 2 bloquent le prochain build de production jusqu’à résolution documentée. Cette règle empêche de publier de nouvelles pages alors qu’une régression CWV n’est pas traitée, ce qui diluerait le score CrUX du domaine.

Distinguer les mesures Lab et les données terrain CrUX

Lighthouse mesure des conditions de laboratoire (réseau simulé, CPU throttlé). Les données CrUX (Chrome User Experience Report) reflètent les performances réelles des utilisateurs Chrome sur 28 jours glissants. Ces deux sources ne sont pas interchangeables : une page peut être Good en Lab et Needs Improvement en CrUX si les utilisateurs réels ont des connexions ou des appareils différents du profil de test.

Nous collectons les données CrUX via l’API PageSpeed Insights (quota : 25 000 requêtes par jour, suffisant pour l’ensemble du corpus en une nuit) et les stockons séparément. Le tableau de bord distingue clairement les deux sources. Les décisions de déploiement se basent sur CrUX ; les diagnostics de régression utilisent Lighthouse.

Questions fréquentes

Le LCP est-il mesuré sur mobile ou desktop ?

Les deux. Les mesures Lab utilisent les profils Lighthouse ’mobile’ (Moto G4 émulé, réseau 4G lente simulée) et ’desktop’ (réseau câble simulé). Les données CrUX sont segmentées par type d’appareil via le paramètre formFactor de l’API.

Comment identifiez-vous quelle ressource cause un LCP élevé ?

Lighthouse retourne l’élément LCP (sélecteur CSS) et la ressource associée dans son rapport JSON. Un script post-traitement agrège ces informations par type de ressource (image, bloc texte, iframe) pour identifier les causes systémiques plutôt que page par page.