Le rendu HTML côté serveur suffit à la plupart des sites d'affaires

L'affirmation

Pour un site vitrine, un catalogue de produits, un formulaire de réservation ou un tableau de bord interne utilisé par quelques centaines de personnes, du HTML rendu côté serveur accompagné d'un peu de JavaScript surpasse une application monopage sur les mesures qui comptent vraiment : le délai avant le premier octet, le délai avant l'interactivité, le taux d'erreur sur le terrain et les heures que votre équipe consacre à l'entretien. L'architecture monopage règle un vrai problème. Ce n'est simplement pas le vôtre.

Ce qu'une application monopage coûte avant même votre code

Commençons par le plancher. React et ReactDOM totalisent environ 45 ko compressés. Ajoutez un routeur, une couche de récupération de données, une bibliothèque de formulaires et un sélecteur de dates : vous êtes à quelque 120 ko de cadriciel avant d'avoir écrit une seule ligne. Les sites d'entreprises canadiennes de taille moyenne qu'on nous demande de redresser arrivent généralement avec 250 à 600 ko de JavaScript compressé.

Mesurez le vôtre plutôt que de le deviner :

find dist/assets -name '*.js' -exec sh -c 'gzip -c "$1" | wc -c' _ {} \; | paste -sd+ | bc

Faites ensuite le calcul sur un appareil réel. Une cliente avec un téléphone Android de trois ans sur un réseau LTE rural près de Belleville n'obtient pas 100 Mbit/s. Supposons 1,6 Mbit/s utile et 250 ko de JavaScript : cela fait environ 1,25 seconde de transfert. L'analyse et la compilation du paquet sur un cœur ARM d'entrée de gamme ajoutent quelques centaines de millisecondes, et rien de tout cela ne se chevauche avec du travail utile, puisque la page reste vide tant que le paquet n'a pas été exécuté et que le premier appel réseau n'est pas revenu.

Ce que coûte le rendu côté serveur

Un gabarit rendu par Django, Rails, Laravel ou Go sur une base de données tiède prend couramment de 8 à 20 ms. Compressée en Brotli, une page riche en contenu pèse de 20 à 40 ko. Le navigateur peut commencer à peindre dès les premiers paquets reçus, parce que le HTML est un format en continu depuis toujours.

La troisième colonne est celle qu'on sous-estime. Chaque aller-retour supplémentaire coûte une latence réseau complète, et la latence ne s'améliore pas quand le client change de forfait.

Le mode de défaillance que personne ne budgète

Une page rendue au serveur dont un module lève une exception livre quand même le reste du document. Une page rendue au client qui échoue à l'hydratation livre un rectangle blanc. Nous avons audité des sites où une balise d'analytique tierce, bloquée par un mandataire d'entreprise, mettait tout le processus de commande hors service pour quiconque passait derrière ce mandataire. Personne ne l'a remarqué pendant onze jours : le serveur renvoyait 200 à chaque requête et les tableaux de bord étaient au vert.

Quand l'application monopage est le bon choix

Il existe une vraie catégorie d'applications qui doivent l'être : éditeurs collaboratifs, outils de dessin, écrans de répartition ou de négociation en direct, tout ce qui maintient un état local optimiste devant survivre à une connexion capricieuse, et tout ce dont la session dure quarante minutes et compte des centaines d'interactions. Si vos utilisateurs ouvrent l'outil le matin et le ferment à dix-sept heures, amortir 400 ko sur la session est une aubaine. S'ils arrivent d'un résultat de recherche, lisent une page et remplissent un formulaire, l'amortissement n'arrive jamais.

La voie mitoyenne n'est pas un compromis

Rendez au serveur, puis ajoutez de l'interactivité là où elle se justifie. Turbo, htmx et Alpine permettent de conserver une seule couche de gabarits en livrant de 10 à 15 ko de JavaScript au total. Quand il vous faut un composant réellement riche — un plan de salle, une carte, un planificateur — montez-le en îlot sur une page autrement statique et chargez-le en différé.

Complétez avec un en-tête de cache qui laisse un RDC absorber le trafic :

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=86400

Cette directive demande au navigateur de revalider chaque fois, à la périphérie de servir une copie en cache pendant cinq minutes, puis de continuer à servir une copie périmée jusqu'à une journée pendant qu'elle se rafraîchit en arrière-plan. Pour un catalogue modifié quelques fois par semaine, l'écrasante majorité des requêtes quitte ainsi votre serveur d'origine sans aucune logique d'invalidation à entretenir.

Trancher en un après-midi

1. Sortez trente jours de statistiques et regardez la durée médiane des sessions et le nombre de pages par session. Sous trois pages et deux minutes, vous servez des arrivées, pas des utilisateurs.
2. Comptez les éléments d'état distincts qui doivent être partagés entre les vues sans rechargement. Sous cinq, aucun magasin d'état côté client n'est requis.
3. Demandez-vous si l'outil doit fonctionner hors ligne. Sinon, aucun cache côté client n'est requis non plus.

Deux réponses sur trois pointant vers le serveur suffisent. L'architecture gagnante est celle que votre équipe de deux personnes pourra encore comprendre dans dix-huit mois, et un gabarit qui renvoie du HTML est très difficile à rater.