Performance web : un audit Lighthouse complet en 30 secondes
Vous venez de publier une nouvelle landing page et voulez vous assurer qu'elle ne pèse pas comme une enclume. Un client demande pourquoi sa boutique met 9 secondes à charger. Vous pitchez une refonte et avez besoin d'un chiffre sur la slide ("ils sont à 38, vous serez à 95"). Toutes ces situations partagent une seule réponse : un audit Lighthouse.
Cet outil interroge l'API Google PageSpeed Insights (le même moteur Lighthouse qu'utilise Google Search Console) pour obtenir le rapport complet : quatre scores 0-100 (Performance, Accessibilité, Bonnes pratiques, SEO), Core Web Vitals (LCP, INP, CLS, FCP, TTFB, Speed Index) et une liste de choses concrètes à corriger (par exemple "cette image hero de 1.2 Mo bloque le rendu, vous pouvez gagner 2.8 s").
D'où viennent les données ? La mesure en labo tourne dans le cloud Google sur une connexion 4G simulée plus smartphone milieu de gamme. Si le site dispose de données réelles dans le Chrome User Experience Report (CrUX) - le jeu de données public Google des métriques terrain de vrais visiteurs Chrome - alors INP et TTFB incluent ces données terrain. Les petits sites n'ont en général pas d'échantillon CrUX, vous ne voyez donc que les chiffres labo.
Mobile vs Desktop : ce n'est pas le même audit. Le mobile bride à un appareil de classe Moto G4 sur 4G lente (1.6 Mbps, 150 ms de latence), donc les scores sont toujours plus bas. Google privilégie le mobile dans son classement (mobile-first indexing depuis 2019), vérifiez donc celui-ci en priorité.
Mode d'emploi
- Collez l'URL de la page à auditer. Vous pouvez omettre `https://`, on l'ajoute. Ce doit être une URL publique - Google ne peut pas atteindre `localhost`, `.local`, ou des pages derrière un login.
- Choisissez une stratégie : Mobile (par défaut, ce qui compte pour le SEO) ou Desktop (plus facile à pousser au-dessus de 90, utile pour comparer). Auditez les deux quand le quota le permet - le mobile est souvent bien plus lent.
- Cliquez sur Lancer la vérification et patientez 10 à 30 secondes. Google charge littéralement la page dans un navigateur virtuel, mesure chaque étape et la note. Ce n'est pas un lookup en cache - chaque exécution est une mesure fraîche.
- Vous voyez 4 jauges (Performance, Accessibilité, Bonnes pratiques, SEO). Vert = 90-100, ambre = 50-89, rouge = 0-49. Google considère le vert comme "bon", le reste est de la marge de progression.
- Sous les jauges, les Core Web Vitals : LCP (Largest Contentful Paint, quand l'écran semble visuellement prêt), INP (Interaction to Next Paint, vitesse de réaction de la page aux clics), CLS (Cumulative Layout Shift, est-ce que le contenu saute pendant le chargement), FCP, TTFB, Speed Index.
- La liste des opportunités en bas est la partie actionnable - corrections concrètes triées par impact. Chacune indique l'économie estimée, par exemple "compresser les images : -2.1 s". Attaquez les 3 premières marquées High, le reste est anecdotique.
- Relancez après avoir déployé un correctif : nouvelle mesure, nouveau score, comparaison facile. Ouvrir dans PageSpeed Insights vous emmène sur le rapport officiel Google sur pagespeed.web.dev (mêmes données, plus de détails).
Quand cet outil est utile
Six situations où cet outil bat un "ça devrait être assez rapide" prononcé à l'oral :
- Vérification de régression pré-déploiement. Vous venez de faire un gros refactor frontend (mise à jour de framework, nouvelle librairie de composants, changement de CMS). Avant de pusher en prod, vous confirmez que le score n'est pas tombé sous 90. Si c'est le cas, vous savez creuser ce qui a été ajouté (souvent : un bundle JS surdimensionné ou des images non optimisées).
- Montrer un concurrent à un client. Réunion commerciale. Vous voulez prouver que le prestataire actuel du client livre des sites lents. Vous auditez sa page et celle d'un concurrent : 38 vs 92. Le client se met à écouter - difficile de contre-argumenter face aux chiffres Google.
- Diagnostiquer "pourquoi la boutique rame". Un client dit que la conversion a chuté et soupçonne la vitesse. Vous auditez : LCP 6.8 s (devrait être sous 2.5 s), les opportunités montrent "images hero trop grosses (3.4 Mo)". Réglé en une demi-journée.
- Audit SEO avant une migration. Le client passe de WordPress à Shopify / Webflow / une stack custom. Vous auditez le site actuel avant et le nouveau site après, en comparant les 4 scores. SEO vous dit si meta tags, alt text et sitemap ont survécu. Best Practices, si vous avez introduit du contenu mixte ou des APIs dépréciées.
- Valider un changement d'hébergement / CDN. Vous passez d'un VPS générique à Vercel / Cloudflare Pages / Netlify. Audit mobile + desktop avant et après. TTFB (Time To First Byte) montre tout de suite si le serveur répond plus vite. LCP, si les images chargent plus vite (CDN cache hit).
- Spot-check accessibilité WCAG. Les clients du secteur public ou soumis à la conformité ont besoin de la conformité WCAG 2.1 AA. L'audit Accessibilité couvre le contraste, les alt text, les rôles ARIA, les anneaux de focus. Un audit complet nécessite une revue humaine, mais Lighthouse attrape environ 80 % des problèmes techniques.
Besoin de plus de contexte ? L'inspecteur de certificat SSL confirme que HTTPS est correctement configuré (un prérequis pour Best Practices = 100). La consultation DNS montre si le serveur répond via les bons enregistrements. L'aperçu Open Graph aide à vérifier les meta tags de partage social que Lighthouse attend de vous.