Mesurer les performances : Lighthouse et Core Web Vitals

Lighthouse est l’outil standard pour mesurer les performances web. Exécutez-le dans Chrome DevTools (onglet Lighthouse) ou via le CLI (npx lighthouse https://yoursite.com). Lors de l’évaluation de l’architecture en îlots, exécutez Lighthouse sur des pages représentatives avant et après la migration afin de quantifier objectivement les gains.

LCP mesure le moment où le plus grand élément de contenu visible a fini d’être rendu. L’architecture en îlots améliore le LCP, car le serveur envoie immédiatement du HTML entièrement rendu : le navigateur n’attend pas que JavaScript rende le contenu. Une image principale ou un titre qui constituerait le LCP est affiché à partir de la réponse HTML initiale.

Dans une SPA React, le LCP est souvent retardé, car le navigateur doit télécharger et exécuter JavaScript avant que React ne rende l’élément LCP. Avec l’architecture en îlots, le contenu LCP se trouve dans le HTML initial, de sorte que l’exécution de JavaScript ne bloque pas le LCP. Il s’agit de l’un des avantages mesurables les plus importants.

Le temps total de blocage mesure la durée pendant laquelle le fil d’exécution principal est bloqué par des tâches JavaScript de plus de 50 ms. L’hydratation d’une grande SPA React peut produire plusieurs centaines de millisecondes de TBT. L’architecture en îlots réduit considérablement le TBT, car la quantité de JavaScript exécutée est proportionnelle au nombre d’îlots, et non à la taille de la page.

Le décalage cumulatif de mise en page mesure la stabilité visuelle, c’est-à-dire les déplacements des éléments pendant le chargement de la page. Le contenu généré par JavaScript peut provoquer des décalages de mise en page lorsque React effectue le rendu et modifie les dimensions. Le HTML généré côté serveur par l’architecture en îlots évite les décalages de mise en page liés à l’hydratation, car la mise en page initiale provient d’un HTML statique qui ne change pas lors de l’hydratation.

Le délai de première saisie (désormais remplacé par l’interactivité jusqu’au prochain affichage, INP) mesure la rapidité avec laquelle la page répond aux interactions de l’utilisateur. L’architecture en îlots améliore l’INP, car chaque îlot possède un petit paquet JavaScript ciblé. Les interactions au sein d’un îlot s’exécutent rapidement, puisqu’il n’y a pas de grande arborescence React dans laquelle ordonnancer le travail.

Pour une page de blog, une comparaison typique serait la suivante : une SPA React complète peut obtenir un score de 45 à 65 dans Lighthouse sur mobile (TBT : 800 ms, LCP : 3,2 s). Le même contenu sous forme de site Astro avec un seul îlot React peut obtenir un score de 90 à 98 (TBT : 80 ms, LCP : 1,1 s). Les gains sont particulièrement importants sur les pages riches en contenu et peu interactives.

L’architecture en îlots n’est pas le bon choix pour les applications très interactives comme les tableaux de bord, les éditeurs de code ou les outils collaboratifs. Ces applications comportent des composants qui partagent constamment leur état et sont réaffichés ensemble : le surcoût de la communication entre îlots annulerait les gains de performance et ajouterait une complexité architecturale.

L’architecture en îlots excelle pour les sites riches en contenu qui présentent une interactivité dispersée : les blogs (lecture du contenu, avec parfois un bouton J’aime ou un commentaire), la documentation (lecture de la documentation, avec parfois une recherche ou un bouton de copie du code), les pages d’accueil (principalement statiques, avec un îlot pour le formulaire d’inscription à la newsletter) et les pages de produits de commerce en ligne (images et description statiques, avec un îlot d’ajout au panier).

Google utilise les Core Web Vitals (LCP, INP, CLS) comme signaux de classement. L’amélioration de ces métriques grâce à l’architecture en îlots favorise directement le classement dans les résultats de recherche. Un site qui fait passer son score Lighthouse sur mobile de 55 à 92 en adoptant l’architecture en îlots bénéficie simultanément d’une meilleure expérience utilisateur et d’un meilleur référencement naturel.

Les équipes qui migrent une SPA React Next.js vers Astro pour des sites marketing et de documentation constatent des tendances constantes : les volumes de JavaScript diminuent de 70 à 90 %, les scores de performance sur mobile augmentent de 20 à 40 points et les coûts d’hébergement côté serveur diminuent, car les fichiers statiques sont servis depuis un CDN sans le surcoût du rendu côté serveur à chaque requête.

Pourquoi l’architecture en îlots réduit-elle considérablement le temps total de blocage (TBT) ?

L’architecture en îlots améliore tous les Core Web Vitals : le LCP bénéficie du HTML généré côté serveur, le TBT diminue parce que la quantité de JavaScript est proportionnelle à l’interactivité, le CLS est réduit grâce à des mises en page stables générées côté serveur et l’INP s’améliore avec de petits paquets ciblés pour chaque îlot. Les scores Lighthouse des pages riches en contenu progressent considérablement. Ce modèle ne convient pas aux applications très interactives, mais il excelle pour les blogs, la documentation, les pages d’accueil et le commerce en ligne.