Le score Lighthouse n'est pas le résultat d'une optimisation, mais un miroir reflétant l'essence de l'architecture

Lorsque l’on compare un site avec un score Lighthouse élevé à un site avec un score faible, des faits surprenants émergent. Un site avec un score élevé n’est pas forcément celui qui a consacré le plus de temps à l’optimisation, mais plutôt un site conçu de manière simple, sans faire peser une soif de traitement sur le navigateur.

Ce que révèlent les métriques de performance

Lighthouse ne mesure pas le classement des outils ou des frameworks. Ce qu’il évalue, ce sont les résultats concrets :

• La vitesse à laquelle un utilisateur voit un contenu significatif
• Le temps pendant lequel JavaScript occupe le thread principal
• La stabilité du layout lors du chargement
• L’accessibilité et la crawlabilité de la structure du document

Ces métriques (TTFB, LCP, CLS) sont la réaction en chaîne des décisions prises lors de l’implémentation. Elles sont particulièrement liées à la quantité de calcul que le navigateur doit effectuer lors de l’exécution.

Une architecture dépendant de gros bundles côté client est inévitablement associée à un score faible. À l’inverse, un site basé principalement sur du HTML statique, avec une logique client minimale, offre des performances prévisibles et stables.

La soif de JavaScript : le vrai coupable de la dégradation des performances

Un problème commun à de nombreux projets audités est l’exécution de JavaScript.

Ce n’est pas une question de qualité du code, mais plutôt une contrainte fondamentale du modèle de traitement en thread unique du navigateur. Les runtimes de frameworks, l’hydratation, la résolution des dépendances, l’initialisation de l’état — tout cela gaspille du temps avant que la page ne devienne interactive.

Même de très petites fonctionnalités interactives exigent souvent des bundles excessivement volumineux. Les architectures qui supposent JavaScript par défaut nécessitent des ajustements constants pour maintenir la performance.

En revanche, une architecture qui positionne explicitement JavaScript comme une option à activer volontairement tend à produire des résultats plus stables. Cette différence de philosophie se reflète nettement dans le score Lighthouse.

Le traitement lors de la build élimine l’incertitude

Les sorties pré-rendues éliminent plusieurs variables de l’équation de performance :

• Pas besoin de coûts de rendu côté serveur à la requête
• Pas besoin de bootstrap côté client pour afficher le contenu
• Le navigateur reçoit un HTML complet et prévisible

En conséquence, les métriques comme TTFB, LCP, CLS s’améliorent naturellement. Cela ne garantit pas un score parfait, mais limite considérablement les risques d’échec.

Apprendre d’un exemple concret

Dans un projet de reconstruction d’un blog personnel, plusieurs approches ont été envisagées. La configuration basée sur React avec hydratation était flexible, mais nécessitait une vigilance constante sur la performance. À chaque ajout de fonctionnalités, il fallait repenser la stratégie de rendu, la récupération des données, la taille des bundles.

À l’inverse, une approche basée sur du HTML statique, en traitant JavaScript comme une exception, a montré des résultats spectaculaires. Le choix d’Astro s’est imposé parce que sa conception contraignante correspondait à l’hypothèse que nous voulions tester.

Ce qui a été surprenant, ce n’est pas le score initial, mais la stabilité des performances dans le temps :

• Pas de baisse de score lors de la publication de nouveau contenu
• Pas de chaînes d’avertissements causés par de petits éléments interactifs
• Une base qui se dégrade peu

Dans cette architecture, le score Lighthouse n’est pas une fin en soi, mais une conséquence naturelle.

La réalité des compromis

Il est crucial de comprendre que cette approche n’est pas universelle. Une architecture centrée sur le statique est peu adaptée à des applications très dynamiques et avec beaucoup d’état. Dans des scénarios nécessitant authentification, mise à jour en temps réel ou gestion complexe de l’état côté client, la complexité d’implémentation augmente.

Les frameworks orientés rendu côté client offrent une flexibilité pour ces cas, au prix d’une complexité accrue lors de l’exécution.

L’essentiel est de réaliser que ce qui est supérieur, ce n’est pas la méthode, mais que le choix architectural influence directement les métriques Lighthouse.

Pourquoi le score se stabilise ou baisse

Ce que Lighthouse met en évidence, ce n’est pas le fruit d’un effort d’optimisation, mais la complexité du système.

Les systèmes dépendant d’un calcul en temps d’exécution accumulent de la complexité à chaque ajout de fonctionnalité. Ceux qui effectuent un travail en build, en revanche, limitent cette complexité par défaut.

C’est cette différence qui explique pourquoi certains sites nécessitent sans cesse des ajustements de performance, tandis que d’autres restent stables avec peu d’intervention.

Le choix fondamental

Un score Lighthouse élevé n’est généralement pas le résultat d’un ajustement via des outils d’optimisation actifs. Il découle naturellement d’une architecture qui minimise la charge lors du chargement initial du navigateur.

Même si les outils et tendances évoluent, le principe fondamental reste le même : intégrer la performance comme une contrainte dès la conception, pas comme un objectif à atteindre. Ainsi, le score Lighthouse ne devient pas une fin en soi, mais un indicateur à observer.

Ce changement ne concerne pas le choix du framework, mais la décision de où accepter la complexité.