Il y a une règle de performance que personne ne peut contester, parce qu'elle est tautologique. Le JavaScript le plus rapide est celui que tu n'envoies pas. Pas de téléchargement, pas d'analyse, pas d'exécution, pas d'hydratation. Zéro coût. Et c'est exactement ce que permettent les Server Components, une brique de Next.js bien utilisé, expédier du HTML déjà prêt au lieu d'envoyer au navigateur du travail à faire.
Le problème, c'est que par défaut, dans la plupart des bases de code, tout part côté client. Chaque composant, qu'il soit interactif ou pas, devient du JavaScript que le navigateur doit télécharger puis réveiller. Y compris des blocs qui ne font rien d'autre qu'afficher du texte. Voici pourquoi ça coûte cher, ce que ça change concrètement, et la règle simple pour trancher entre client et serveur.
L'hydratation, la taxe invisible que Copyboost payait au prix fort
Quand tu envoies un composant côté client, le navigateur ne se contente pas de l'afficher. Il doit l'hydrater, c'est à dire reprendre le HTML déjà là et y rebrancher toute la logique JavaScript, les écouteurs d'événements, l'état, les effets. Cette étape d'hydratation a un coût, et ce coût se paie sur le fil principal du navigateur, celui là même qui doit répondre aux clics de ton visiteur.
Le piège, c'est que l'hydratation est invisible à l'oeil. La page a l'air affichée, elle semble prête, mais en coulisses le navigateur est encore en train de tout réveiller. Pendant ce temps, ton visiteur peut cliquer, et rien ne répond, parce que le fil principal est occupé. C'est exactement ce qui dégrade la réactivité aux clics, l'INP. Tu paies cette taxe sur chaque composant client, même ceux qui n'ont rien à hydrater de réel, parce qu'ils n'ont aucune interactivité.
Les Server Components cassent ce mécanisme. Un composant qui ne fait qu'afficher du contenu est rendu une fois sur le serveur, et arrive dans le navigateur sous forme de HTML pur, sans JavaScript associé. Rien à télécharger pour lui, rien à hydrater. Le navigateur reçoit le résultat fini au lieu de la recette à exécuter. Tu réserves le coût du JavaScript aux endroits qui en ont vraiment besoin, ceux qui réagissent au visiteur.
Et ce coût n'est pas le même pour tout le monde. Sur ta machine de développeur, l'hydratation se fait en un éclair, tu ne la sens jamais. Sur un téléphone milieu de gamme, dont le processeur est plusieurs fois plus lent, cette même hydratation peut bloquer le fil principal pendant un temps qui se ressent vraiment. Le JavaScript a un coût d'exécution proportionnel à la puissance de l'appareil, et la majorité de tes visiteurs ne sont pas sur ta machine. Servir du HTML plutôt que du JavaScript, c'est précisément protéger ceux qui ont les appareils les plus faibles, c'est à dire souvent la majorité.
Cette taxe, je ne l'ai pas découverte dans un article, je l'ai payée moi-même. Sur Copyboost, son coût était mesurable et lourd.
- Ce qui partait au client. Une chaîne partagée chargeait 301 kilooctets de JavaScript sur chaque page, et 13 des 16 morceaux de code étaient communs à l'accueil et à l'application. Une grande partie de ce code servait à hydrater des composants qui, à la réflexion, n'avaient pas besoin de tourner dans le navigateur. C'est le cas typique du JavaScript qui bloque le rendu sans rien apporter au visiteur.
- Ce que ça coûtait. Le temps de blocage du fil principal, le TBT, était de 1740 millisecondes. Près de deux secondes pendant lesquelles la page semblait prête mais ne répondait pas aux interactions. En allégeant ce qui était envoyé et hydraté, ce temps est tombé à 950 millisecondes. Le visiteur n'attendait plus que le navigateur finisse de réveiller du code inutile.
La leçon, c'est que mon problème n'était pas la quantité de fonctionnalités, c'était que je faisais hydrater au navigateur des choses qui auraient dû rester du HTML servi. Le serveur aurait pu faire le travail une fois, j'ai demandé au navigateur de le refaire à chaque visiteur.
Le détail qui m'a ouvert les yeux, c'est que 13 de mes 16 morceaux de code étaient communs à l'accueil et à l'application. Autrement dit, un visiteur qui venait juste lire ma page d'accueil téléchargeait et réveillait du code conçu pour l'application connectée, dont il n'avait aucun usage. Je lui faisais payer l'interactivité d'un produit qu'il n'utilisait pas encore. Séparer ce qui est public et passif de ce qui est applicatif et interactif, c'est la première chose à faire avant même de parler de Server Components.
La plupart de tes composants n'ont rien à faire côté client
Voici l'affirmation qui dérange. Si tu regardes honnêtement ton SaaS, la majorité de tes composants n'ont aucune raison d'être interactifs. Un en tête, un pied de page, une fiche de contenu, une section marketing, un tableau qui affiche des données sans les éditer. Tout ça pourrait être du HTML servi tel quel. Et pourtant, par défaut, tu l'envoies en JavaScript à hydrater.
Le réflexe de tout passer côté client n'est pas un choix d'architecture, c'est une habitude héritée d'une époque où c'était la seule option. Aujourd'hui, le défaut sain est l'inverse, serveur par défaut, client seulement quand c'est nécessaire. La plupart des équipes font encore le contraire, et paient une taxe d'hydratation sur des composants qui ne réagiront jamais à rien.
Trois questions pour trancher entre client et serveur
Pour chaque composant, pose une seule question, dans cet ordre.
- Est ce qu'il a besoin d'interactivité ? Des clics qui changent l'état, une saisie, un effet qui réagit au navigateur. Si oui, il est client, c'est légitime. Si non, continue.
- Est ce qu'il utilise une API du navigateur ? Accès au stockage local, à la fenêtre, à la géolocalisation. Si oui, client. Si non, continue.
- Sinon, il est serveur. Affichage de contenu, données en lecture seule, structure de page, sections marketing. Tout ça part en HTML servi, sans coût de JavaScript côté visiteur.
La règle se résume en une phrase. Serveur par défaut, client uniquement quand le composant doit réagir au visiteur. Tu inverses le réflexe habituel, et tu cesses de payer une taxe d'hydratation sur ce qui ne bouge jamais.
Ce qu'il faut retenir
Le JavaScript le plus rapide est celui que tu n'envoies pas, et l'hydratation est la taxe invisible que tu paies sur chaque composant client, y compris ceux qui ne réagissent à rien. Sur Copyboost, alléger ce qui était hydraté a fait tomber le temps de blocage de 1740 à 950 millisecondes. C'est l'une des façons les plus nettes de traiter la vitesse comme premier levier CRO. Passe tes composants en revue avec une seule question, est ce que ça doit réagir au visiteur, et bascule en serveur tout ce qui répond non. Commence par tes pages publiques, les plus visitées et les moins interactives, c'est là que le gain est le plus net. Une page d'accueil ou un article de blog n'a presque rien à hydrater, et c'est pourtant souvent là que tu envoies le plus de code par défaut. Si tu veux savoir combien de JavaScript inutile ton SaaS fait hydrater, c'est ce que je mesure dans un diagnostic de performance.