Les scores Lighthouse sont un signal architectural, pas une liste de contrôle d'optimisation

Pendant longtemps, j'ai supposé que les scores Lighthouse élevés étaient principalement le résultat d'ajustements. Compresser des images, différer des scripts, corriger des décalages de mise en page, ajuster des thèmes, changer de plugins, et répéter le cycle à chaque fois qu'un nouvel avertissement apparaissait.

Avec le temps, cette hypothèse a cessé de correspondre à ce que j'observais en pratique.

Les sites qui obtenaient régulièrement de bons scores n'étaient pas ceux qui faisaient le plus d'efforts d'optimisation. C'étaient ceux où le navigateur avait simplement moins de travail à faire.

À ce moment-là, Lighthouse a cessé de ressembler à un outil d'optimisation et a commencé à ressembler à un signal de diagnostic pour les choix architecturaux.

Ce que Lighthouse mesure réellement

Lighthouse n'évalue pas les frameworks ou les outils. Il évalue les résultats.

La rapidité avec laquelle un contenu significatif apparaît.

La quantité de JavaScript qui bloque le thread principal.

La stabilité de la mise en page pendant le chargement.

L'accessibilité et l'exploitabilité de la structure du document.

Ces résultats sont des effets en aval de décisions prises bien plus tôt dans la pile. En particulier, ils reflètent la quantité de calcul différée au navigateur lors de l'exécution.

Lorsqu'une page dépend d'un bundle côté client volumineux pour devenir utilisable, de mauvais scores ne sont pas surprenants. Lorsqu'une page est principalement du HTML statique avec une logique côté client limitée, les performances deviennent beaucoup plus prévisibles.

JavaScript comme principale source de variance

Dans les audits que j'ai effectués et les projets sur lesquels j'ai travaillé, l'exécution JavaScript est la source la plus courante de régressions Lighthouse.

Ce n'est pas parce que le code est de mauvaise qualité. C'est parce que JavaScript concurrence un environnement d'exécution monothread pendant le chargement de la page.

Les runtimes de frameworks, la logique d'hydratation, les graphes de dépendances et l'initialisation d'état consomment tous du temps avant que la page ne devienne interactive. Même de petites fonctionnalités interactives nécessitent souvent des bundles disproportionnellement volumineux.

Les architectures qui supposent JavaScript par défaut nécessitent des efforts continus pour garder les performances sous contrôle. Les architectures qui traitent JavaScript comme un opt-in explicite ont tendance à produire des résultats plus stables.

La sortie statique réduit l'incertitude

La sortie pré-rendue élimine plusieurs variables de l'équation de performance.

Il n'y a pas de coût de rendu côté serveur au moment de la requête.

Il n'y a pas de bootstrap côté client requis pour que le contenu apparaisse.

Le navigateur reçoit du HTML prévisible et complet.

Du point de vue de Lighthouse, cela améliore des métriques telles que TTFB, LCP et CLS sans nécessiter de travail d'optimisation ciblé. La génération statique ne garantit pas des scores parfaits, mais elle réduit considérablement la gamme de modes de défaillance.

Une étude de cas

Avant de reconstruire mon blog personnel, j'ai exploré plusieurs approches courantes, y compris des configurations basées sur React qui reposent sur l'hydratation par défaut. Elles étaient flexibles et capables, mais les performances nécessitaient une attention continue. Chaque nouvelle fonctionnalité soulevait des questions sur le mode de rendu, la récupération de données et la taille du bundle.

Par curiosité, j'ai essayé une approche différente qui supposait d'abord du HTML statique et traitait JavaScript comme une exception. J'ai choisi Astro pour cette expérience, car ses contraintes par défaut correspondaient aux questions que je voulais tester.

Ce qui ressortait n'était pas un score initial spectaculaire, mais le peu d'effort nécessaire pour maintenir les performances au fil du temps. La publication de nouveau contenu n'introduisait pas de régressions. Les petits éléments interactifs ne se répercutaient pas en avertissements non liés. La base était simplement plus difficile à éroder.

J'ai documenté le processus de construction et les compromis architecturaux dans une note technique séparée tout en travaillant sur cette expérience sur un blog personnel avec un score Lighthouse parfait.

Les compromis comptent

Cette approche n'est pas universellement meilleure.

Les architectures statiques d'abord ne sont pas idéales pour les applications hautement dynamiques et avec état. Elles peuvent compliquer des scénarios qui reposent fortement sur des données utilisateur authentifiées, des mises à jour en temps réel ou une gestion d'état côté client complexe.

Les frameworks qui supposent un rendu côté client offrent plus de flexibilité dans ces cas, au prix d'une complexité d'exécution plus élevée. Le point n'est pas qu'une approche soit supérieure, mais que les compromis se reflètent directement dans les métriques Lighthouse.

Pourquoi les scores Lighthouse ont tendance à être stables ou fragiles

Ce que Lighthouse révèle n'est pas l'effort, mais l'entropie.

Les systèmes qui reposent sur le calcul à l'exécution accumulent de la complexité au fur et à mesure que des fonctionnalités sont ajoutées. Les systèmes qui font plus de travail au moment de la construction contraignent cette complexité par défaut.

Cette différence explique pourquoi certains sites nécessitent un travail de performance constant tandis que d'autres restent stables avec une intervention minimale.

Réflexions finales

Les scores Lighthouse élevés sont rarement le résultat de passes d'optimisation agressives. Ils émergent généralement naturellement d'architectures qui minimisent ce que le navigateur doit faire lors du premier chargement.

Les outils vont et viennent, mais le principe sous-jacent reste le même. Lorsque la performance est une contrainte par défaut plutôt qu'un objectif, Lighthouse cesse d'être quelque chose que vous poursuivez et devient quelque chose que vous observez.

Ce changement concerne moins le choix du bon framework que le choix de l'endroit où la complexité est autorisée à exister.