Le terme isomorphisme est communément appliqué en mathématique pour désigner un changement de forme réversible qui conserve les propriétés originales (en formulation très simplifiée : deux graphes sont isomorphes s’ils ont le même nombre de sommets ainsi que les mêmes connexions sans pour autant partager la même forme. cf ci-dessous)
En informatique, il désigne une application qui s’utilise tout aussi bien dans un modèle Client Side Rendering (CSR) que dans un modèle Server Side Rendering (SSR), sans avoir à modifier sa structure.
Un certain nombre de frameworks permettent de construire des applications de ce type. C’est notamment le cas d’Angular, par exemple, qui propose de builder vos applications sur un modèle SSR.
Le but de cet article n’est pas d’expliquer comment construire une application “isomorphic” mais de s’intéresser à sa mise en application dans le cas d’un site internet.
Quelques rappels
Un site internet se caractérise par son accessibilité sans restriction d’aucune sorte.
Des robots d’indexation sont en charge de référencer le site au sein des différents moteurs de recherche. Pour cela des principes sont appliqués afin de faciliter le travail de ces robots. Il s’agit du Search Engine Optimization (SEO).
Chaque robot indexe le site sur la base d’un certains nombres de critères telles que la notoriété, la performance ou encore la fiabilité. Ces éléments sont basés sur les mêmes critères que peuvent expérimenter les utilisateurs finaux.
Ces scores déterminent le classement du site dans le moteur de recherche. Ainsi, un site performant, fiable et disposant de nombreux backlinks (liens externes vers des pages de son site) se verra attribuer un meilleur classement car il apportera logiquement davantage de pertinence et une meilleure expérience d’utilisation.
On peut donc en déduire qu’il y a un lien très étroit entre l’expérience que doit fournir le site internet à un utilisateur et celle qu’il doit fournir à un moteur d’indexation.
Alors QUID d’un site “isomorphic” ?
Rappelons que la distinction entre le CSR et le SSR est que dans le premier cas, c’est le navigateur qui se charge de calculer la structure et d’agréger le contenu de la page, alors que dans le cas du SSR, c’est le serveur qui calcule les éléments de structure et agrège le contenu avant de le rendre à l’utilisateur.
Il est donc évident que le comportement diffère entre les deux. Et cette différence de comportement peut induire une expérience différente pour les utilisateurs et les moteurs d’indexation, pouvant donner une mauvaise perception d’expérience utilisateur aux robots d’indexation.
Pour vous donner un exemple, il est pratique courante de mettre en place un Cache Delivery Network (CDN) en frontal d’un site vitrine de contenu. Cela garantit de bonnes performances, mais également, permet de mieux supporter la charge d’utilisation (voir dans certains cas, d’attaques sur le site).
Toutefois, la mise en place d’un CDN en frontal d’un site de type CSR n’aura pas la même finalité que celui d’un site SSR. Dans le premier cas, il servira à mettre en cache les ressources utilisées par le navigateur pour le rendu des pages, alors que dans le second cas, il mettra en cache le rendu “calculé” de la page par le serveur. L’expérience d’utilisation se retrouvera encore plus impactée car d’un côté la page reste à “calculer”, alors que de l’autre, elle l’est déjà. Pour aller plus loin, le cache risque également(selon la stratégie de rafraichissement choisie) de conserver une version obsolète du contenu de la page, alors qu’au même moment, la partie CSR renverra le contenu actualisé.
Un autre détail, qui a son importance, le CDN du SSR n’apportera pas une expérience optimale du fait qu’il ne sera “chauffé” que par des robots d’indexation et des accès directs aux pages du site (liens depuis d’autres sites / moteurs de recherche ou favoris), ce qui, selon les sites, peut s’avérer un faible pourcentage des visiteurs.
Alors doit-on s’en remettre pour autant aux bons vieux sites en SSR only ?
Pas forcément. Tout dépend des usages de votre site et la façon dont vous voulez qu’il s’intègre à son environnement (par exemple : certaines fonctions mobiles). Toutefois, un site isomorphic va requérir plus de complexité dans la conception et la validation.
Vous devrez prendre en compte et valider le comportement du SSR sur le plan des performances (et plus globalement du SEO) et attacher une importance à ce que le rendu CSR et SSR reste cohérent (voir plus haut les problèmes de cache).
Certains outils vous aide à cette démarche : pagespeed ou lighthouse.
Un petit lien qui date de quelques années désormais, pour approfondir la conception : https://developers.google.com/search/blog/2016/11/building-indexable-progressive-web-apps
Il ne me reste plus qu’à vous souhaiter un bon coding. Eclatez vous 😀.