Lighthouse et DevTools suffisent-ils vraiment pour diagnostiquer le JavaScript inutilisé ?

Google propose une méthodologie en deux temps pour auditer le JavaScript : un premier passage avec Lighthouse pour détecter le code mort, un second avec le panneau Network de DevTools pour analyser les temps de chargement.

Cette déclaration s'inscrit dans la continuité des recommandations sur les Core Web Vitals, où le JavaScript mal optimisé impacte directement le LCP et le FID. Mais concrètement, que signifie "trop lent" ou "inutilisé" dans ce contexte ?

Que détecte précisément Lighthouse comme JavaScript inutilisé ?

Lighthouse identifie le code téléchargé mais non exécuté pendant le chargement initial de la page. Attention : ce n'est pas parce qu'un script n'est pas exécuté immédiatement qu'il est inutile — il peut être nécessaire pour une interaction utilisateur ultérieure.

L'audit se base sur la couverture de code (Coverage) pendant les premières secondes. Un script de 200 Ko dont seuls 30 Ko sont utilisés au chargement sera signalé comme problématique, même si les 170 Ko restants servent après un clic utilisateur.

Comment le panneau Network aide-t-il à identifier les scripts lents ?

Le panneau Network permet d'analyser la cascade de chargement et le temps de téléchargement de chaque ressource. Vous visualisez les scripts qui bloquent le rendu, ceux qui arrivent trop tard, et les dépendances qui s'enchaînent.

Problème : Martin Splitt ne donne aucun seuil chiffré. À partir de combien de millisecondes un script devient-il "trop lent" ? 500 ms ? 1 seconde ? 3 secondes ? Cette absence de référentiel concret complique l'arbitrage.

Pourquoi Google recommande-t-il ces deux outils spécifiquement ?

Lighthouse et DevTools sont des outils maison Google, intégrés à Chrome et accessibles gratuitement. Leur adoption massive garantit que les développeurs parlent le même langage que les audits PageSpeed Insights.

Mais soyons honnêtes : ces outils ne détectent pas tout. Ils ne capturent pas les scripts chargés après interaction utilisateur, ni les ressources déclenchées par des événements complexes. L'audit reste partiel.

• Lighthouse repère le code téléchargé mais non exécuté au chargement initial
• Le panneau Network visualise les temps de téléchargement et les blocages de rendu
• Aucun seuil officiel pour qualifier un script de "trop lent"
• Ces outils ne capturent pas les scripts chargés après interactions utilisateur
• L'approche combine audit automatisé et analyse manuelle

Cette recommandation est-elle vraiment suffisante pour un audit JavaScript complet ?

Non. Lighthouse et Network donnent une photo à l'instant T, celle du chargement initial dans des conditions contrôlées. Sur une SPA complexe ou un site e-commerce avec des dizaines de scripts tiers, cette approche ne révèle qu'une fraction du problème.

Les scripts chargés en lazy loading, ceux déclenchés par scroll ou clic, les trackers qui s'activent après 5 secondes — tout ça échappe à l'audit Lighthouse standard. Et c'est souvent là que se cachent les vrais gouffres de performance.

Que signifie concrètement "JavaScript inutilisé" dans le contexte SEO ?

Google parle de code "inutilisé", mais pour qui ? Pour Googlebot qui crawle la page, ou pour l'utilisateur qui cliquera peut-être sur un bouton ? La nuance est capitale. Un script de formulaire de contact n'est jamais exécuté lors du crawl, pourtant il est indispensable.

Le vrai enjeu : identifier le JavaScript qui bloque le rendu critique sans apporter de valeur immédiate. Les bibliothèques chargées en entier alors que 5% seulement est utilisé. Les polyfills pour des navigateurs qui n'existent plus. [À vérifier] : Google ne précise jamais à quel moment un script passe de "non critique" à "problématique" pour le ranking.

Les seuils de performance varient-ils selon le type de site ?

Absolument, et c'est là que la recommandation de Martin Splitt montre ses limites. Un blog WordPress avec 3 scripts peut se permettre d'être moins optimisé qu'une marketplace avec 40 vendors tiers. Mais Google ne différencie pas dans ses guidelines.

Terrain, on observe que les sites e-commerce avec des Core Web Vitals médiocres rankent quand même s'ils cochent toutes les autres cases (contenu, backlinks, autorité). Le JavaScript "trop lent" semble moins pénalisant qu'annoncé — ou alors le seuil de tolérance est plus élevé que prévu.

Comment auditer efficacement le JavaScript de mon site ?

Commence par un audit Lighthouse depuis Chrome DevTools (F12 > Lighthouse > Analyze page load). Coche "Performance" et "Best Practices". Le rapport te donnera une première liste de scripts avec leur taux d'utilisation.

Ensuite, ouvre le panneau Coverage (F12 > cmd/ctrl + Shift + P > "Show Coverage"). Charge ta page et déclenche quelques interactions. Tu verras en temps réel quel pourcentage de chaque fichier JS est réellement exécuté.

Quelles actions concrètes mettre en place après l'audit ?

Priorise les scripts qui pèsent lourd et dont moins de 50% du code est utilisé. Envisage le code splitting : découpe les gros bundles en morceaux chargés à la demande. Pour les librairies tierces, vérifie s'il existe des versions allégées ou des alternatives plus légères.

Pour les scripts lents identifiés dans Network : vérifie s'ils bloquent le rendu (render-blocking). Si oui, ajoute les attributs defer ou async. Si un script tiers ralentit tout, charge-le après les éléments critiques ou envisage son remplacement.

Quelles erreurs éviter lors de l'optimisation JavaScript ?

Ne supprime jamais un script sans comprendre son rôle. Certains ne s'exécutent qu'après interaction utilisateur mais restent indispensables. Teste chaque modification sur un environnement de staging avec plusieurs scénarios utilisateur.

Évite de te focaliser uniquement sur le score Lighthouse. Un score de 100 qui casse la moitié des fonctionnalités du site n'a aucune valeur. L'objectif : trouver le compromis entre performance et expérience utilisateur.

• Auditer avec Lighthouse et activer le panneau Coverage de DevTools
• Identifier les scripts avec moins de 50% de code exécuté au chargement
• Envisager le code splitting pour les gros bundles JavaScript
• Vérifier les attributs defer/async sur les scripts render-blocking
• Tester toute modification en staging avant production
• Monitorer l'impact réel sur les Core Web Vitals via Search Console
• Documenter chaque script tiers et son utilité pour faciliter les arbitrages