Les performances Web en tant qu'architecture
Pourquoi traiter les performances comme une optimisation de fin de projet échoue, et comment concevoir des systèmes rapides par défaut.
Sommaire
Le mode d’échec de performance le plus courant dans le développement Web moderne consiste à traiter la vitesse comme un bug à corriger à la fin d’un projet.
Les équipes passent des mois à créer une application React massive pour un site de documentation, ignorant la taille croissante du bundle. Lors du lancement du site et que les performances mobiles sont catastrophiques, elles tentent de « l’optimiser » en ajoutant de la mémoïsation, des couches de cache complexes et des limites de chargement différé (lazy-loading).
Ça marche rarement. Vous ne pouvez pas vous sortir par l’optimisation d’une architecture fondamentalement lourde. La performance n’est pas une passe de nettoyage ; c’est la conséquence structurelle de votre modèle de rendu et de la quantité de JavaScript que vous exigez du navigateur qu’il exécute.
Le coût de la taxe d’hydratation
Au cours de la dernière décennie, le modèle mental par défaut pour construire un frontend était la Single Page Application (SPA). Pour que les SPA se chargent plus rapidement, l’industrie a adopté le rendu côté serveur (SSR).
Mais le SSR a introduit la taxe d’Hydratation.
L’hydratation est le processus par lequel le navigateur télécharge le HTML, puis télécharge le JavaScript, et exécute ensuite ce JavaScript pour rattacher les écouteurs d’événements et reconstruire l’arbre d’état. Pendant l’hydratation, le thread principal est bloqué. La page semble prête, mais si l’utilisateur clique sur un bouton, rien ne se passe.
La réalité des appareils
Les développeurs évaluent généralement les performances sur des MacBook de la série M avec une fibre gigabit. Cela produit une fausse certitude.
Sur un appareil Android d’entrée de gamme sur un réseau 3G, la taxe d’hydratation est catastrophique. Analyser et exécuter 500 Ko de JavaScript prend des millisecondes sur l’ordinateur portable d’un développeur, mais peut prendre des secondes sur un téléphone de milieu de gamme. Pendant ces secondes, l’appareil est gelé.
Réponses architecturales à la crise des performances
Si hydrater sans discernement la page entière est le problème, la solution est l’exécution sélective. L’industrie a produit trois réponses architecturales distinctes à ce problème.
Comparaison des modèles de rendu
Voici comment les modèles de rendu modernes résolvent la taxe d’hydratation.
| Modèle | Comment ça marche | Le Bénéfice | Le Coût |
|---|---|---|---|
| Hydratation Totale (Next/Nuxt Standard) | Le serveur rend le HTML. Le client charge tout le JS et réhydrate la page entière. | Modèle mental unifié ; facile de construire un état global complexe. | Lourd coût CPU. Temps jusqu’à interactivité (TTI) lent sur mobile. |
| Architecture en Îlots (Astro) | La page est du HTML statique. Seuls des composants spécifiques marqués chargent le JS et s’hydratent. | Zéro JS de base. Performances imbattables pour les sites de contenu. | Le développeur doit déclarer manuellement les frontières interactives. |
| Résumabilité (Qwik) | Le serveur sérialise les gestionnaires d’événements dans le HTML. Le client « reprend » sans exécuter le code du composant. | Interactivité instantanée. Zéro taxe d’hydratation quelle que soit la taille de l’app. | Modèle mental non orthodoxe ; couplage fort au compilateur du framework. |
| Composants Serveur (RSC) | Le serveur exécute les composants et envoie une charge utile propriétaire au client. | Accès direct au backend dans le code de l’UI ; bundles clients plus petits. | Nécessite un runtime Node/Edge ; sémantique de cache complexe. |
Exemples travaillés : Ce qu’il ne faut pas hydrater
Pour construire des systèmes performants, vous devez développer un instinct pour ce qui n’a pas besoin d’être interactif.
Exemple 1 : La page de documentation (Doit rester statique)
Vous construisez une page d’article comme celle-ci. Elle contient 2 000 mots de texte, quelques blocs de code et un menu de navigation latéral.
La mauvaise architecture : Rendre cela dans une SPA standard. Le navigateur télécharge l’intégralité de l’article en tant que charge utile JSON, plus le runtime React, plus le routeur, puis construit les éléments DOM sur le client. La bonne architecture : Le rendre sous forme de HTML statique. Le seul JavaScript requis est un tout petit script pour basculer le menu de navigation mobile.
Exemple 2 : La page produit E-Commerce (Hybride)
Vous avez une page produit avec une description statique, un carrousel d’images et un bouton « Ajouter au panier » qui met à jour un compteur de panier global.
La mauvaise architecture : Hydrater la page entière pour que le bouton « Ajouter au panier » puisse parler à l’en-tête. Le navigateur gaspille des cycles CPU pour hydrater le pied de page et la description statique du produit. La bonne architecture (Îlots) : La description du produit et le pied de page sont en HTML statique. Le carrousel d’images est un Îlot. Le bouton « Ajouter au panier » est un autre Îlot. Ils communiquent via des événements personnalisés légers ou un minuscule magasin partagé (comme Nano Stores), sans réveiller le reste de la page.
Règles de décision pour les systèmes axés sur le contenu
Si vous créez une publication, un site marketing ou une base de connaissances, adoptez ces heuristiques :
- HTML par défaut : Commencez avec zéro JavaScript. Exigez une justification pour chaque octet de JS ajouté.
- Isoler l’interactivité : Si vous avez besoin d’une calculatrice complexe sur une page d’article, construisez-la comme un îlot. Ne faites pas payer à l’article le coût de performance de la calculatrice.
- Éviter l’évaluation uniquement sur ordinateur de bureau : Ne validez jamais une stratégie de rendu sans brider votre processeur à un ralentissement de 4x et votre réseau sur Fast 3G dans les DevTools.
- Concevoir pour le 90e centile : Si 90 % de votre site est du matériel de lecture et 10 % des formulaires interactifs, choisissez une architecture optimisée pour la lecture (comme Astro), et non une architecture optimisée pour un état complexe (comme une SPA complète).
Vous pouvez toujours ajouter un îlot interactif à une page statique, mais vous ne pouvez pas facilement supprimer la taxe d’hydratation d’une SPA.
Guides et termes associés
Approfondissez votre compréhension :
- Choisir la bonne pile pour le contenu vs les applications — Comment cela s’applique au choix du framework.
- Ce qu’est vraiment l’architecture frontend — Comment les frontières affectent les performances.
- MDX, collections de contenu et le contenu en tant qu’architecture — Modèles d’implémentation.