📍 Article principal : Application web installable hors-ligne : architecture complète pas à pas
Ce tutoriel explique comment auditer une application installable avec Lighthouse après la suppression de la catégorie PWA. Pour la vue d’ensemble, consulter d’abord l’article principal.
Lighthouse et l’application installable : un paysage qui a évolué
Pendant des années, Lighthouse a exposé une catégorie dédiée « Progressive Web App » qui agrégeait une dizaine d’audits — manifeste valide, service worker enregistré, page hors-ligne, icône maskable — en un score unique. C’était commode mais trompeur : un site pouvait afficher un score parfait sans pour autant offrir une expérience hors-ligne digne de ce nom, parce que la catégorie mesurait l’installabilité plus que la résilience.
Avec la version 12.0 sortie le 22 avril 2024, l’équipe Lighthouse a retiré la catégorie PWA. Le raisonnement officiel : les critères d’installation ont évolué (par exemple le service worker n’est plus requis pour l’installation sur Chrome desktop), et le score agrégé donnait une impression de complétude trompeuse. Les audits individuels existent toujours, accessibles séparément, mais ne sont plus regroupés dans une note unique. Ce tutoriel reconstitue un protocole d’audit complet en s’appuyant sur les catégories restantes — Performance, Best Practices, Accessibility, SEO — plus les audits PWA individuels et les outils complémentaires comme PWABuilder.
Prérequis
- Chrome version récente (testé avec la 130 et au-delà — Lighthouse intégré au navigateur)
- Une application installable déjà déployée en HTTPS (ou en local sur
localhost) - Notions des Core Web Vitals (LCP, INP, CLS)
- Niveau intermédiaire en performances web
- Temps estimé : 45 minutes pour un premier audit complet
Étape 1 — Lancer Lighthouse depuis Chrome DevTools
L’audit le plus rapide se fait directement dans le navigateur. Ouvrez l’application dans une fenêtre Chrome en navigation privée, ce qui garantit l’absence d’extensions et de cache résiduel qui fausseraient les mesures. Appuyez sur F12 pour les DevTools, puis cliquez sur l’onglet « Lighthouse ».
Le panneau affiche quatre catégories cochées par défaut : Performance, Accessibility, Best Practices, SEO. Sous « Device », choisir « Mobile » — c’est le profil qui simule un Moto G Power (depuis Lighthouse 10) avec le réseau « Slow 4G » : 1,6 Mbps en téléchargement, 750 Kbps en envoi, 150 ms de latence, plus un ralentissement CPU de 4×. Ces conditions sont représentatives de l’usage réel sur mobile d’entrée de gamme. Choisir « Navigation (default) » comme mode pour un audit complet au chargement initial. Cliquer sur « Analyze page load » — l’audit prend 30 à 90 secondes.
Important : la case « PWA » n’existe plus depuis la version 12 de Lighthouse. Si vous voyez encore cette case, c’est que votre Chrome est en version trop ancienne ou que vous utilisez une intégration Lighthouse tierce non mise à jour.
Étape 2 — Lire le rapport Performance
La catégorie Performance est la plus dense. Le score global agrège six métriques pondérées : First Contentful Paint (10 %), Speed Index (10 %), Largest Contentful Paint (25 %), Total Blocking Time (30 %), Cumulative Layout Shift (25 %). Les seuils retenus en 2024 sont les suivants :
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| First Contentful Paint (FCP) | ≤ 1,8 s | 1,8 – 3,0 s | > 3,0 s |
| Largest Contentful Paint (LCP) | ≤ 2,5 s | 2,5 – 4,0 s | > 4,0 s |
| Total Blocking Time (TBT) | ≤ 200 ms | 200 – 600 ms | > 600 ms |
| Cumulative Layout Shift (CLS) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
| Speed Index | ≤ 3,4 s | 3,4 – 5,8 s | > 5,8 s |
Sous les métriques, la section « Opportunities » liste les améliorations chiffrées : éliminer les ressources bloquantes, réduire le JavaScript inutilisé, servir des images au format moderne, différer les images hors écran. Chaque entrée indique l’économie estimée en kilo-octets et en secondes — c’est la liste prioritaire d’optimisations à attaquer.
Étape 3 — Vérifier les audits d’installabilité individuels
Même sans catégorie dédiée, Lighthouse exécute toujours les audits d’installation, mais ils sont disséminés dans la catégorie « Best Practices » ou apparaissent comme audits manuels. Pour les passer en revue systématiquement, ouvrir un autre outil : le panneau « Application » des DevTools.
Onglet Application, sous-onglet Manifest : Chrome affiche le manifeste parsé, les icônes, le diagnostic d’installabilité. Si quelque chose cloche (icône trop petite, start_url non chargeable, display manquant), un message rouge ou jaune en haut le précise. Sous-onglet Service Workers : statut du service worker, son scope, ses événements en attente. Sous-onglet Storage : usage actuel, quota disponible, possibilité de vider tout pour tester le premier chargement à froid.
Étape 4 — Compléter avec PWABuilder
Le site pwabuilder.com maintenu par Microsoft propose un audit gratuit dédié aux applications installables. Coller l’URL du site, attendre l’analyse : la page de résultats note la qualité du manifeste, la présence du service worker, le respect des critères d’installation Chrome, Edge et iOS, et propose même de générer les packages pour les magasins d’applications (Microsoft Store, Google Play via Trusted Web Activity, Meta Quest).
PWABuilder remplace en partie ce que faisait la catégorie PWA de Lighthouse, avec en plus un découpage par store et des recommandations concrètes pour atteindre les critères. C’est l’outil de référence pour vérifier qu’une application est prête à être distribuée au-delà du simple navigateur.
Étape 5 — Tester en conditions dégradées
Un score Lighthouse mesuré sur « Slow 4G » peut être bon alors que l’expérience réelle sur 2G ou 3G est désastreuse. Pour des tests représentatifs, simuler manuellement des conditions plus sévères via l’onglet Network des DevTools, menu déroulant des conditions réseau, option « Add custom profile ». Créer un profil « 2G » avec 250 kb/s download, 50 kb/s upload, 800 ms latency. Recharger la page avec ce profil actif.
L’audit Lighthouse en mode « Mobile » utilise par défaut le profil « Slow 4G » interne. Pour un test plus sévère, lancer Lighthouse en ligne de commande avec un profil personnalisé :
npm install -g lighthouse
lighthouse https://votre-site.example \
--throttling.cpuSlowdownMultiplier=6 \
--throttling.downloadThroughputKbps=250 \
--throttling.uploadThroughputKbps=50 \
--throttling.requestLatencyMs=800 \
--viewLes options --throttling.* remplacent le profil par défaut. --view ouvre le rapport HTML généré dans le navigateur. Lancer plusieurs fois (5 à 10) et prendre la médiane : les mesures Lighthouse ont une variance non négligeable, surtout sur les machines sous charge.
Étape 6 — Profiler le service worker
Lighthouse ne profile pas en détail le service worker — il vérifie son existence et son scope, c’est tout. Pour mesurer ce qu’il fait réellement, basculer sur l’onglet Performance des DevTools. Cocher « Screenshots » et « Memory », commencer un enregistrement, recharger la page, arrêter au bout de quelques secondes.
Dans la timeline résultante, la piste « Service Worker » affiche les événements fetch, install, activate avec leur durée précise. Une intervention service worker doit rester sous 5 ms ; au-delà, la réponse aux requêtes ralentit perceptiblement. Si une stratégie déclenche des écritures cache synchrones lourdes, elles apparaissent ici comme blocs orange — signal de refactorer pour pousser ces écritures en arrière-plan via cache.put() dans une promesse non attendue.
Étape 7 — Auditer la consommation de stockage
Une application installable accumule des données. Sous « Application → Storage », la barre supérieure affiche l’usage agrégé : Cache Storage, IndexedDB, Cookies, Local Storage, Service Worker. Cliquer sur « Clear site data » remet tout à zéro pour tester un premier chargement à froid. La méthode programmatique équivalente :
const estimate = await navigator.storage.estimate();
console.log(`Usage: ${(estimate.usage / 1024 / 1024).toFixed(1)} Mo`);
console.log(`Quota: ${(estimate.quota / 1024 / 1024).toFixed(1)} Mo`);
console.log(`Détail: ${JSON.stringify(estimate.usageDetails)}`);Le champ usageDetails n’est exposé que sur Chrome et donne la répartition entre les différents stockages. Sur Firefox et Safari, seul l’usage total est disponible. Surveiller régulièrement permet de détecter une croissance anormale — typiquement un cache d’images mal borné.
Étape 8 — Lighthouse en intégration continue
Mesurer ponctuellement est utile ; suivre l’évolution dans le temps est indispensable pour détecter les régressions. Lighthouse CI exécute Lighthouse à chaque commit ou pull request, compare les scores à une baseline, et fait échouer la CI si certains seuils sont franchis. L’installation se fait via npm.
npm install -g @lhci/cliCréer un fichier lighthouserc.json à la racine du projet :
{
"ci": {
"collect": {
"url": ["http://localhost:3000/", "http://localhost:3000/produits"],
"numberOfRuns": 5
},
"assert": {
"assertions": {
"categories:performance": ["error", {"minScore": 0.85}],
"categories:accessibility": ["error", {"minScore": 0.9}],
"first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
"interactive": ["warn", {"maxNumericValue": 4000}]
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}Lancer lhci autorun dans le pipeline CI : il démarre le serveur de prévisualisation, exécute Lighthouse 5 fois par URL, calcule la médiane, et fait échouer le build si les seuils ne sont pas atteints. Le rapport est uploadé sur un stockage temporaire avec un lien partageable, pratique pour discuter d’une régression en équipe.
Interpréter un rapport et prioriser les actions
Un rapport Lighthouse de 200 audits effraie quand on n’a pas de méthode pour le digérer. La règle pragmatique : ne jamais essayer de tout corriger d’un coup. Trier les opportunités par économie de temps (colonne « Estimated savings » en secondes) et attaquer les trois plus rentables. Une seule action qui gagne 1,5 seconde sur le LCP vaut dix actions qui grattent 50 ms chacune sur le TBT.
Trois leviers reviennent presque toujours en tête de liste sur une application installable mal optimisée. D’abord, réduire le JavaScript inutilisé via le code-splitting : Vite, Webpack et Rollup le font tous, encore faut-il vérifier que les routes lazy le sont vraiment. Ensuite, servir des images modernes au format AVIF ou WebP avec srcset adapté à la densité de pixel cible — gain typique de 60 à 80 % sur le poids visuel. Enfin, éliminer les ressources bloquantes au-dessus de la ligne de flottaison : tout CSS qui n’est pas critique passe en chargement asynchrone avec media="print" puis onload="this.media='all'", ou via la directive preload avec as="style".
Pour l’application installable spécifiquement, deux audits méritent une attention particulière même s’ils n’apparaissent plus dans une catégorie dédiée. L’audit « Service worker registers a fetch handler » vérifie que le service worker intercepte effectivement les requêtes — un worker enregistré sans handler fetch n’apporte aucune résilience. L’audit « Web app manifest meets the installability requirements » consolide en un seul résultat tous les critères d’installation. Les deux apparaissent dans la section « Best Practices » ou en audits manuels selon la version de Chrome.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Score Lighthouse très variable entre deux runs | Variance naturelle + charge machine | Lancer 5 à 10 fois, prendre la médiane ; idéalement audit depuis un environnement contrôlé |
| « No service worker detected » en Best Practices | Service worker non enregistré au moment de l’audit | Vérifier la registration dans Application → Service Workers ; recharger après inscription |
| Audit échoue avec « Page failed to load » | Trafic bloqué par un firewall ou erreur SSL | Tester depuis Chrome directement ; vérifier le certificat ; si self-signed, ajouter --ignore-certificate-errors |
| CLS élevé sans cause visible | Image sans dimensions, font swap, contenu inséré dynamiquement | Ajouter width et height sur les images ; font-display: swap avec fallback proche |
| LCP qui ne s’améliore pas malgré les optimisations | Élément LCP réel non identifié | Onglet Performance, ligne « LCP » : la flèche pointe l’élément exact à optimiser |
Tutoriels frères
- Service Workers avec Workbox 7 : tutoriel complet pas à pas — l’objet d’audit principal.
- Stratégies de cache : CacheFirst, NetworkFirst, StaleWhileRevalidate — leur impact direct sur les scores de performance.
- IndexedDB avec Dexie.js : stockage local riche en JavaScript — surveiller l’usage stockage via l’audit.
Pour aller plus loin
- 🔝 Retour à l’article principal : Application web installable hors-ligne : architecture complète pas à pas
- Chrome for Developers — Lighthouse (overview)
- Lighthouse changelog (releases et changements de catégories)
- PWABuilder — audit et génération de packages
- web.dev — Lighthouse CI (intégration continue)
- web.dev — Core Web Vitals (référence des seuils)
Questions fréquentes
Le score Lighthouse est-il vraiment représentatif de l’expérience utilisateur ?
Partiellement. Lighthouse mesure en laboratoire avec des conditions simulées, ce qui donne une note reproductible mais standardisée. Pour l’expérience réelle, compléter avec les données « field » : Chrome User Experience Report (CrUX) agrège les vraies mesures Core Web Vitals des utilisateurs Chrome ayant accepté la télémétrie. Disponible via PageSpeed Insights ou l’API CrUX BigQuery.
Pourquoi mes scores chutent-ils brusquement après une mise à jour de Lighthouse ?
Les algorithmes évoluent à chaque version majeure. La pondération des métriques change, de nouveaux audits apparaissent, les seuils se durcissent. Ce n’est pas que votre site s’est dégradé, c’est que l’aune s’est rapprochée des standards de pointe. Consulter le changelog officiel pour comprendre l’impact spécifique.
Comment auditer une page derrière une authentification ?
Lighthouse CLI accepte un script Puppeteer qui se connecte avant l’audit. Le pattern : lighthouse --chrome-flags="..." --output=json --output-path=report.json https://app/dashboard précédé d’un script puppeteer-script.js qui se connecte avec des credentials de test. Configuration plus lourde mais indispensable pour les SaaS authentifiés.
Lighthouse remplace-t-il les tests utilisateurs réels ?
Non. Lighthouse mesure la performance technique, pas l’utilisabilité. Une application avec un score parfait peut être incompréhensible. Combiner audits automatisés (Lighthouse, axe-core pour l’accessibilité) et tests utilisateurs qualitatifs reste la seule approche fiable.
Quelle alternative à Lighthouse pour un audit régulier hors CI ?
WebPageTest offre des mesures plus précises avec des appareils physiques et des géographies variées. SpeedCurve combine WebPageTest, CrUX et un dashboard de suivi. Pour rester gratuit, PageSpeed Insights fait l’essentiel et expose à la fois les données lab (Lighthouse) et field (CrUX).