Mesurez avec les deux : données de lab et de terrain — elles répondent à des questions différentes. Lighthouse est du lab (synthétique, reproductible, pour le débogage) ; le RUM est du terrain (utilisateurs réels, pour la vérité). Si vous ne faites confiance qu'à l'un, vous optimisez la mauvaise chose.
| Lab (Lighthouse) | Terrain / RUM |
|---|
| Source | Une exécution synthétique, appareil/réseau fixes | Vraies visites, tous appareils/réseaux |
| Utile pour | Débogage, gates de régression en CI, reproductible | Ce que les utilisateurs vivent réellement |
| INP | Impossible à mesurer (pas d'interactions réelles) | Mesuré sur l'ensemble de la visite |
| Faiblesse | Ne reflète pas votre vrai trafic | Bruité, nécessite du volume, plus dur à déboguer |
Lighthouse exécute un unique chargement throttlé sur une machine propre — parfait pour reproduire un problème, inutile pour connaître votre p75. L'INP en particulier ne peut être capturé que sur le terrain, car il nécessite de vraies interactions au fil d'une session.
import { onLCP, onCLS, onINP } from "web-vitals";
function send(metric) {
// Le build d'attribution vous dit QUEL élément/interaction l'a causé
navigator.sendBeacon("/rum", JSON.stringify({
name: metric.name, value: metric.value, id: metric.id,
}));
}
onLCP(send); onCLS(send); onINP(send); // rapporte chaque métrique à sa finalisation
C'est la même méthodologie que le CrUX (Chrome User Experience Report) de Google, qui alimente le classement Search — le CrUX est le p75 des utilisateurs réels, pas du lab.
Le signal senior, c'est de savoir que lab ≠ terrain, que le classement utilise le p75 de terrain, et que l'INP n'est réel que sur le terrain. Optimiser un score Lighthouse pendant que le p75 réel reste mauvais est un piège classique que cette question est conçue pour exposer.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don