Rendu côté serveur ou côté client : le retour de balancier
Server Side vs Client Side Rendering : l'histoire du web est-elle une boucle infinie ? Comment nous sommes passés du SSR au CSR... pour revenir au SSR et aller vers des technologies Edge.
Au commencement du web dynamique, les pages HTML étaient rudimentaires, et la logique était exécutée côté serveur.
Avec l’apparition des contenus dynamiques, puis l'engouement progressif pour les Single Page App (SPA), ce travail s’est progressivement reporté sur les navigateurs. On peut parler d’un grand bond en avant pour la “Dev eXperience”, mais bien moins pour l’utilisateur final, particulièrement sur les mobiles peu puissants.
De fait, un “retour en arrière” (ou plus précisément au centre) est peut-être devenu nécessaire pour exécuter toujours plus de code et de logique métier, tout en étant moins gourmands en ressources et en CPU.
Quelques précisions techniques - mais accessibles - sur ce changement de paradigme, ce que ça implique, et les perspectives que ça ouvre.
Rappels historiques : le mouvement de balancier entre Server Side et Client Side Rendering
Au temps des dinosaures et de Netscape Navigator, les pages HTML des sites web étaient statiques. Il fallait occuper une ligne téléphonique pour naviguer, saisir l’adresse du site parce qu’il n’y avait pas de moteurs de recherche (ou le trouver dans un annuaire), et Internet était un outil de publication d’informations qui n’avaient pas vocation à beaucoup bouger dans le temps.
Une première évolution a été introduite par des technologies et langages tels que CGI, ASP, Perl ou PHP, pour interpréter les requêtes et générer une réponse HTML dynamique pour chaque utilisateur. Ces langages sont alors toujours exécutés côté serveur.
Presque 30 ans plus tard, un navigateur comprend 3 langages :
- HTML, pour créer des documents, décrire et créer leur structure de contenu,
- CSS, pour définir le style des documents HTML,
- JavaScript (JS), pour rendre plus interactive la page HTML.
Javascript, qui était auparavant utilisé uniquement pour ajouter de l’interactivité à des pages, est progressivement devenu central pour beaucoup de sites web, jusqu’à presque tout remplacer.
On peut ainsi voir des frameworks JS utilisés pour afficher des sites web entiers avec uniquement du JS (qui va bien sûr générer du HTML et du CSS, c’est ce que comprend un navigateur).
Par ailleurs, pour afficher un site, différentes options existent, notamment la possibilité d’opérer le rendu côté serveur (Server Side Rendering, SSR, “à l’ancienne”), ou côté client (ou navigateur, soit le Client Side Rendering, CSR). Mais nous allons voir que nous sommes allés bien trop loin dans la charge supportée par le navigateur.
Dans l’absolu, selon la complexité d’un site, l’une ou l’autre des options peut être pertinente. Pour comprendre les détails, cet article explique très bien les principes, les avantages et les limites du SSR et du CSR ; et ce graphique en fait un très bon résumé, avec en plus des informations à propos de l’impact sur les métriques webperf :
Bien sûr, une fois que le site est chargé, une SPA est a priori beaucoup plus rapide. Elle présente toutefois des inconvénients importants : la page HTML inclut peu de contenu, ce qui fait que les robots Google ont peu de choses à se mettre sous la dent. Même si Google sait indexer du contenu JS, cela reste un problème pour le SEO.
Par ailleurs, une SPA implique de gros paquets (chunks) de JS à exécuter dès le début du chargement. Pour un Mac dernière génération, ça ne pose aucune difficulté, mais les performances des mobiles moyen ou entrée de gamme seront forcément dégradées - alors que le trafic mobile devient majoritaire partout dans le monde.
Enfin, pour accompagner cette tendance, les outils de conception de SPA se sont également développés, et les frameworks JS ont ainsi beaucoup amélioré la Dev eXperience, mais au détriment de l’expérience utilisateur en termes de performance web. Autrement dit, le confort de quelques milliers de développeurs est devenu prioritaire par rapport à celui des millions d'utilisateurs finaux.
Forts de ce constat, et vu l’importance que prend la vitesse pour le référencement depuis que Google en tient compte dans son algorithme de ranking, l’heure est au régime de ces SPA et au retour vers le rendu côté serveur (SSR). “What goes around comes around”.
Rendu côté serveur ou côté client, balle au centre
Le constat est sans appel : rééquilibrer le travail entre serveur et navigateur est indispensable pour préserver les performances et l’UX (et donc le SEO et le CA), alors que les sites web deviennent de plus en plus lourds et complexes, et que les enjeux de sobriété énergétique sont présents à l’esprit des éditeurs comme des utilisateurs !
Des pistes vers un compromis existent pour corriger les défauts du rendu côté client, comme on l’a vu dans le tableau récapitulatif ci-dessus, mais ça ne suffit pas. En effet, dans cette optique, il faut malgré tout recharger tout le code généré côté serveur pour l’exécuter encore côté client, ce qui fait que le SEO peut être amélioré, mais pas la vitesse de chargement.
La solution pour de meilleures performances : en demander le moins possible au navigateur, et revenir au Server Side Rendering pour pré-calculer un maximum de choses côté serveur et non plus côté navigateur. Dans ce sens, deux options se présentent :
- télécharger progressivement les features d’un site, mais bien que certains frameworks commencent à le gérer nativement (comme Sapper ou RemixJS), cela reste complexe à mettre en œuvre car si le framework ne sait pas le faire, c’est complexe de tout prévoir ;
- ou bien réaliser le travail de nettoyage du JS inutile, de compilation et de précalcul “at the Edge”, c’est-à-dire entre le serveur et le navigateur. L’exécution se fait ainsi côté serveur, qui envoie alors des éléments beaucoup plus légers au navigateur, et le travail de rendu est partagé.
Sans revenir aux “anciens” langages comme PHP, on retourne à un équilibre entre navigateur et serveur, et les technologies Edge permettent justement de servir des sites dynamiques avec les performances du statique, en rapatriant l’exécution des éléments dynamiques à un niveau qui a les capacités pour le faire : le serveur !
Ce fonctionnement offre des perspectives enthousiasmantes, dont certaines montrent déjà tout leur potentiel, via des solutions d’exécutions de JS (first party ou third party) déportées soit dans des web workers, soit dans des couches de Edge Computing. Et ce n’est que le début !
Edge : le nouvel eldorado
Comme nous venons de le voir, en demandant moins au navigateur et plus aux serveurs, le Edge computing répond à plusieurs problématiques :
- Il permet d’exécuter le code sur une couche plus proche de l'utilisateur, d’une part parce qu’elle se situe entre le navigateur et les serveurs d’origine, mais aussi parce que les serveurs sont distribués en Points de Présence (PoP) à la manière d’un CDN, soit au plus proche des utilisateurs sur le plan géographique.
- Il permet d’intervenir sur le site “at the Edge” au lieu d’intervenir sur l’origine, et c’est une vraie solution dans les cas où on ne maîtrise pas son origine ou son CMS, ou que les modifications de code ne sont pas supportées par le framework, voire trop complexes à déployer.
Une partie de l’intelligence est ainsi déplacée du côté de cette couche de CDN. Un CDN classique qui ne faisait que stocker et diffuser est maintenant très souvent augmenté de fonctionnalités de calcul, avec des capacités bien supérieures à celles des navigateurs, et avec une implémentation bien moins complexe que sur les serveurs d’origine.
C’est le même principe qui est utilisé pour les solutions d’optimisation webperf ou d’images, et cette intelligence peut être employée pour d’autres domaines comme le SEO.
Outre l’optimisation des images et du front-end, et forte de cette expertise, c’est une des raisons pour laquelle nous nous sommes orientés vers une solution d’optimisation SEO at the Edge, pour réécrire et optimiser le code instantanément.
Plus besoin de modifier le code à l’origine, ou d’attendre la disponibilité des équipes techniques pour déployer une roadmap ; tester et modifier immédiatement des optimisations SEO pour déployer 100% de sa roadmap est maintenant une réalité. Un véritable eldorado !