Rendu côté serveur ou côté client : l’historique Web est-il une boucle infinie ? &#xD ;

Comment passe-t-on de la SSR à la RSE… pour revenir à la SSR et passer aux technologies Edge.

Au début du Web dynamique, les pages HTML étaient rudimentaires et la logique était exécutée par le serveur.

Avec l’apparition des contenus dynamiques, puis l’engouement progressif pour les Single Page Apps (SPA), ce travail s’est progressivement déplacé vers les navigateurs. On peut parler d’un grand bond en avant pour la « Dev eXperience », mais beaucoup moins pour les utilisateurs finaux, notamment sur les téléphones les moins puissants.

En fait, un « rollback » (ou plus précisément vers le centre) peut devenir nécessaire pour exécuter de plus en plus de code et de logique métier, tout en étant moins gourmand en ressources et en CPU.

Rappels historiques : le mouvement de balancier entre Server Side et Client Side Rendering

Quelques détails techniques – mais accessibles – sur ce changement de paradigme, ce qu’il implique et les perspectives qu’il ouvre.

À l’époque des dinosaures et de Netscape Navigator, les pages Web HTML étaient statiques. Il fallait occuper une ligne téléphonique pour naviguer, entrer l’adresse du site car il n’y avait pas de moteur de recherche (ou la trouver dans un annuaire), et Internet était un outil de publication d’informations qu’ils n’avaient pas l’intention de déplacer beaucoup. temps

Une première évolution a été introduite par des technologies et des 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.

Près de 30 ans plus tard, un navigateur comprend 3 langues :

Javascript, qui n’était auparavant utilisé que pour ajouter de l’interactivité aux pages, est progressivement devenu central sur de nombreux sites Web, remplaçant presque tout.

On peut donc voir des frameworks JS utilisés pour afficher des sites entiers avec uniquement du JS (qui génère naturellement du HTML et du CSS, c’est ce qu’un navigateur comprend).

De plus, pour visualiser un site, il existe différentes options, notamment la possibilité d’opérer le rendu côté serveur (Server Side Rendering, SSR, « old style »), ou côté client (ou navigateur, à savoir Client Side Le rendu). , RSE). Mais on voit qu’on est allé 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, avantages et limites de la RSS et de la RSE ; et ce graphique en fait un très bon résumé, avec plus d’informations sur l’impact sur les métriques webperf :

Bien sûr, une fois le site chargé, un SPA est a priori beaucoup plus rapide. Cependant, il présente des inconvénients importants : la page HTML comprend peu de contenu, ce qui signifie que les robots de Google ont peu à manger. Même si Google sait comment indexer le contenu JS, cela reste un problème pour le SEO.

De plus, un SPA implique de gros morceaux de JS à exécuter au début du chargement. Pour un Mac de dernière génération, cela ne pose aucune difficulté, mais les performances des téléphones de milieu de gamme ou d’entrée de gamme seront inévitablement dégradées – alors que le trafic mobile devient majoritaire partout dans le monde.

À Lire  Vosgien. Saint-Dié : un sapin de Noël, qui pèse plus de 2 tonnes, est installé

Enfin, pour accompagner cette tendance, les outils de design SPA se sont également développés, et les frameworks JS ont ainsi grandement amélioré la Dev eXperience, mais au détriment de l’expérience utilisateur en termes de performances web. En d’autres termes, le confort de quelques milliers de développeurs est devenu une priorité par rapport à celui de millions d’utilisateurs finaux.

Rendu côté serveur ou côté client, balle au centre  

Dans cette optique, et compte tenu de l’importance de la rapidité pour le SEO puisque Google en tient compte dans son algorithme de classement, l’heure est à ces SPA et au retour au rendu côté serveur (SSR). « Plus ça change, plus c’est la même chose. »

Le constat est clair : rééquilibrer le travail entre serveur et navigateur est indispensable pour préserver performances et UX (et donc SEO et chiffre d’affaires), alors que les sites web deviennent de plus en plus lourds et complexes, et que les problématiques de sobriété énergétique sont présentes dans l’esprit des éditeurs et des utilisateurs . !

Des pistes vers un compromis existent pour corriger les défauts de rendu côté client, comme nous l’avons vu dans le tableau résumé ci-dessus, mais cela ne suffit pas. En effet, dans cette optique, il faut aussi recharger tout le code généré par le serveur pour toujours tourner côté client, ce qui veut dire que le référencement peut être amélioré, mais pas la vitesse de chargement.

La solution pour de meilleures performances : demander le moins possible au navigateur, et revenir au Server Side Rendering pour pré-calculer le plus possible côté serveur et pas plus côté navigateur. À cet égard, il existe deux options :

Sans revenir aux « vieux » langages comme PHP, on revient à un équilibre entre le navigateur et le serveur, et les technologies Edge permettent justement de servir des sites dynamiques avec des performances statiques, rapatriant l’exécution des éléments dynamiques à un niveau qui a la capacité de le faire : le serviteur !

Edge : le nouvel eldorado

Cette opération offre des perspectives intéressantes, dont certaines montrent déjà tout leur potentiel, à travers des solutions d’exécution JS à distance (first party ou third party) tant dans les web workers que dans les couches Edge Computing. Et ce n’est que le début!

Comme nous venons de le voir, en exigeant moins du navigateur et plus des serveurs, l’Edge computing résout plusieurs problèmes :

Une partie de l’intelligence est ainsi déplacée du côté de cette couche CDN. Un CDN classique qui ne fait que stocker et distribuer est aujourd’hui très souvent augmenté de fonctionnalités informatiques, avec des capacités bien supérieures à celles des navigateurs, et avec une implémentation bien moins complexe que dans les serveurs d’origine.

C’est le même principe qui est utilisé pour les solutions de performance web ou d’optimisation d’image, et cette intelligence peut être utilisée pour d’autres domaines comme le SEO.