Tester la performance d’un site avec Lighthouse et Window Performance

Quand on cherche comment tester la vitesse d’un site web, on tombe vite sur deux excès. Le premier: ne vivre que pour le score Lighthouse. Le second: lire trois valeurs dans window.performance et croire que tout est sous contrôle. Dans la vraie vie, aucun de ces raccourcis ne suffit.

Lighthouse donne une vue de laboratoire. C’est excellent pour comparer deux versions, repérer du JavaScript inutile, des images trop lourdes ou des ressources qui bloquent le rendu. Le Window Performance API, lui, montre ce qui se passe vraiment dans le navigateur: quels fichiers ralentissent le chargement, quand le contenu utile apparaît, et si le thread principal reste occupé alors que l’écran donne l’impression que la page est prête.

Pour le SEO, ce duo est beaucoup plus intéressant qu’il n’y paraît. Un LCP lent, une page qui répond mal ou un layout qui bouge au mauvais moment ne font pas seulement baisser le confort de lecture. Ils grignotent aussi la conversion.

Pourquoi croiser test labo et signal navigateur

Lighthouse est rapide, propre et très utile pour prioriser. Mais il ne reproduit pas tous les contextes d’usage réels. Vos visiteurs n’arrivent pas tous avec une machine récente, un Wi-Fi stable et zéro script tiers chargé.

Avec window.performance, vous voyez les choses autrement:

• Le problème vient-il du serveur, du HTML initial ou d’un script externe?
• Le contenu principal tarde-t-il à s’afficher à cause de l’image hero, des polices ou du rendu bloqué?
• La page est-elle visible, mais encore trop occupée pour être fluide?

Dit autrement: Lighthouse pose l’alerte. Window Performance aide à expliquer le "pourquoi".

Bien exploiter Lighthouse sans fétichiser le score

Le plus simple reste Chrome DevTools. Ouvrez la page, lancez F12, onglet Lighthouse, choisissez Mobile ou Desktop, puis exécutez l’audit. Pour les comparaisons plus sérieuses ou l’intégration CI, le CLI reste très pratique.

Vous pouvez aussi commencer par un passage dans le SEO Analyzer pour repérer rapidement les URLs à problème et les signaux mobiles qui méritent une vérification plus poussée.

Le vrai travail se fait ensuite dans le détail:

• JavaScript inutilisé
• ressources qui bloquent le rendu
• poids des images au-dessus de la ligne de flottaison
• scripts tiers qui gonflent le TBT

À ce moment-là, le rapport devient un plan d’action, pas une note abstraite.

Les métriques à lire en premier

Vous n’avez pas besoin de tout retenir. Si l’objectif est d’améliorer SEO, UX et conversion, commencez par:

1. LCP: le moment où le contenu principal devient visible.
2. INP: la capacité réelle de la page à répondre vite aux interactions.
3. CLS: la stabilité visuelle pendant le chargement.
4. FCP: le premier signe de vie à l’écran.
5. TBT: un très bon indicateur de labo pour détecter les longs blocages du thread principal.

On croise encore souvent TTI ou FID dans d’anciens articles. Ce n’est pas inutile de les connaître, mais pour prioriser aujourd’hui, LCP, INP, CLS et TBT sont nettement plus parlants.

Ce que le Window Performance API ajoute à l’analyse

C’est ici que l’on descend d’un cran dans le diagnostic.

Avec performance.getEntriesByType('navigation'), vous récupérez les timings de navigation. Avec resource, vous voyez les fichiers lents. Avec paint, vous suivez les premiers signaux visuels. Et pour observer LCP, CLS ou les long tasks proprement, mieux vaut passer par PerformanceObserver.

1const nav = performance.getEntriesByType('navigation')[0];
2const resources = performance.getEntriesByType('resource');
3
4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd);
5console.log('Load event:', nav.loadEventEnd);
6console.log(
7  'Top 5 slowest resources:',
8  resources.sort((a, b) => b.duration - a.duration).slice(0, 5)
9);

1const observer = new PerformanceObserver((list) => {
2  for (const entry of list.getEntries()) {
3    console.log(entry.entryType, entry.startTime, entry.duration || entry.value);
4  }
5});
6
7observer.observe({ type: 'largest-contentful-paint', buffered: true });
8observer.observe({ type: 'layout-shift', buffered: true });
9observer.observe({ type: 'longtask', buffered: true });

Pour suivre correctement l’INP en production, il est plus sûr de s’appuyer sur votre couche RUM ou sur une implémentation web-vitals que de bricoler une collecte approximative.

Comparer plusieurs profils réseau est souvent le moment de vérité. Une page qui semble "correcte" sur une bonne connexion peut devenir franchement pénible dès qu’on la teste sur mobile.

Le workflow que je recommande

Pas besoin d’un cérémonial compliqué. Il faut surtout éviter de mesurer n’importe comment:

1. Lancez Lighthouse pour trouver les pages à risque et hiérarchiser.
2. Utilisez window.performance pour comprendre précisément où ça ralentit.
3. Vérifiez ensuite si les données terrain confirment le problème.
4. Corrigez, puis rejouez le test dans les mêmes conditions, pas dans des conditions plus favorables.

Si les audits pointent surtout vers des assets trop lourds, le JavaScript Compressor, le CSS Compressor et le HTML Compressor peuvent aider à enlever du poids avant la mise en ligne.

Conclusion

Un bon test de performance ne sert pas à produire une belle capture. Il sert à obtenir une explication défendable: pourquoi la page est lente, quelle partie du stack bloque, et quelle correction vaut vraiment l’effort.

Lighthouse donne le premier signal. Window Performance permet d’aller au fond du problème. Si vous voulez commencer par une vue globale avant d’ouvrir DevTools, faites d’abord passer l’URL dans SeoSpeedup, puis utilisez ces données comme point de départ pour une analyse plus précise.