BLOG

Et si vous rendiez votre front côté back ?

Aujourd’hui le développement front s’appuie très souvent sur des frameworks et librairies Javascript comme React, Angular ou Vue. La zone de confort de ces outils est le rendu côté client, des applications Javascript dites « single page » qui s’exécutent dans le navigateur. Mais ces dernières années on voit un retour vers le rendu côté serveur grâce à des outils qui offrent de nouvelles perspectives au développement front : les meta-frameworks.

On vous explique pourquoi il faut s’y intéresser de près ! 

Quelles sont les limites du rendu côté client (CSR) ? 

Les frameworks et librairies Javascript du marché comme Angular, React ou Vue permettent par défaut de faire du rendu côté client (Client Side Rendering / CSR). On parle souvent de Single Page Applications (SPA) pour décrire ces applications qui sont rendues côté client. 

Une SPA se présente sous la forme d’une page HTML unique qui charge un bundle Javascript généré lors de la phase de développement de l’application. Toute l’application s’exécute ensuite en Javascript dans le client (le navigateur) : construction de l’interface utilisateur (HTML), interactions avec l’utilisateur (saisie, clics, validation de formulaire, animations, …), navigation, appels d’API, etc… 

Ce mode de fonctionnement apporte quelques avantages : 

• Il offre une bonne expérience utilisateur, en particulier une navigation fluide, car on ne recharge que des fragments de page et non la page entière. 

• Il réduit le volume des données échangées entre le client et le serveur (essentiellement de la donnée mais pas de HTML) 

• Le front est simple à héberger : un serveur HTTP comme Nginx ou Apache suffit, ou encore une solution CDN, optimisée pour servir des fichiers statiques. 

Mais ces SPA montrent également des limites : 

• Elles ne peuvent pas fonctionner sans Javascript ! 

• Elles pénalisent le référencement sur les moteurs de recherche. En effet les moteurs d’indexation attendent des pages HTML complètes avec du contenu, alors qu’avec une SPA on fournit une page HTML sans contenu et ne faisant que référence à des ressources Javascript ou CSS. 

• Les SPA ne permettent pas d’optimiser les appels d’API pour le chargement des données qui varient peu entre les utilisateurs. Prenons l’exemple des mentions légales d’un site contribuées dans un CMS, ou encore une liste de pays dans un formulaire, des indicateurs calculés une fois par jour, les informations détaillées d’un produit, etc... Pour toutes ces données identiques pour tous les utilisateurs, des appels d’API seront réalisés pour chaque navigateur, un vrai gaspillage de ressources ! 

• Le temps de démarrage de l’application peut être long car il inclut le chargement des fichiers Javascript (parfois volumineux) et l’exécution initiale du code Javascript pour rendre le contenu de la page. On parle de « Time To Interactive » (TTI), temps nécessaire pour que l’utilisateur puisse interagir avec la page, et c’est un des principaux indicateurs de performance web. 

• Le développement des SPA présente quelques complexités de développement : gestion de la navigation, appels d’API, gestion de cache, etc… 

Ces limites réduisent le champ d’utilisation des SPA. Mais le rendu côté serveur va apporter des solutions à ces problématiques. 

Quels sont les intérêts du rendu côté serveur (SSR) ? 

Le rendu côté serveur (Server Side Rendering / SSR) consiste à construire les pages à la demande, côté serveur, en Javascript. C’est donc une page HTML complète qui est retournée au client. 

Ce mode de fonctionnement apporte une réponse à plusieurs inconvénients des SPA : 

• Les pages retournées sont faciles à indexer pour les moteurs de recherche. 

• Vu qu’on retourne directement du HTML, certaines applications sont capables de fonctionner sans Javascript (au moins en mode dégradé). 

• On améliore le Time To Interactive car on supprime le temps nécessaire à la construction initiale de la page côté client. 

• Les appels d’API peuvent se faire côté serveur et non plus depuis le navigateur. On peut ainsi facilement partager un cache entre les utilisateurs pour optimiser les appels d’API. On peut également conserver les clés d’API côté serveur et ne plus les inclure dans les bundles Javascript. On peut enfin même ne plus exposer l’API sur internet si elle est dédiée à l’application (et donc réduire la surface d’attaque pour les pirates). 

Cette construction des pages côté serveur, c’est déjà ce qu’on fait depuis longtemps avec des technologies comme PHP, JSP, ASP.Net, etc… et plus généralement tous les systèmes de templating côté serveur. Mais de nouveaux outils amènent ce rendu côté serveur à un niveau supérieur : les meta-frameworks. 

Pourquoi les meta-frameworks sont-ils intéressants ? 

Un meta-framework est un outil construit sur la base d’une librairie ou d’un framework Javascript comme React, Angular ou Vue. Il propose des fonctionnalités qui vont améliorer l’expérience utilisateur (UX) et l’expérience développeur (DX).  

Le principal de ces apports est le rendu côté serveur, mais avec des caractéristiques supplémentaires par rapport au rendu serveur traditionnel qu’on peut avoir avec PHP ou JSP par exemple : 

• Avec ces meta-frameworks, on utilise la même technologie côté serveur et côté client : React, Angular, Vue, etc… Un composant côté serveur pourra également s’exécuter côté client en partageant la même technologie. On parle de composants « hybrides ». 

• Une fois chargée sur le client, l’application se transforme en application single page (on parle de « réhydratation »). L’utilisateur bénéficie alors de tous les avantages d’une SPA en termes de fluidité de navigation et d’expérience utilisateur. 

Les meta-frameworks permettent donc de réunir le meilleur des deux mondes : le rendu côté serveur et le rendu côté client. 

Certains meta-frameworks proposent d’autres modes de rendu plus spécialisés, qui sont des extensions de ce mode SSR : 

• Le mode « Static Site Generation » (SSG) dans lequel les pages sont générées au moment du build, déclenché le plus souvent par une plateforme d’intégration continue. C’est l’idéal pour les sites dont le contenu bouge peu (contenu institutionnel, dashboard généré plusieurs fois dans la journée, …) 

• Le mode « Incremental Static Regeneration » (ISR) avec lequel les pages sont générées au build comme dans le mode SSG, mais peuvent aussi être regénérées périodiquement (durée de mise en cache) ou à la demande (par exemple via des webhooks envoyés depuis un CMS quand un article est modifié). 

D'autres meta-frameworks offrent également des fonctionnalités supplémentaires qui répondent à des besoins récurrents sur les sites web : 

• Optimisation du chargement des scripts externes 

• Optimisation des images (une problématique souvent sous-estimée dans les sites web) 

• Fonctionnalités autour du SEO 

• Optimisations des performances etc… 

Toutes les caractéristiques font des meta-frameworks des outils qui vont faciliter le développement de sites et applications web performants et améliorer l’expérience utilisateur. 

Quand utiliser un meta-framework ? 

Les caractéristiques des meta-frameworks autour du référencement et des performances en font des outils incontournables pour développer des sites web grand public. Ils sont en particulier pertinents pour des sites webs pour lesquels le référencement est crucial et qui proposent à la fois du contenu plutôt statique et des fonctionnalités dynamiques. Par exemple un site de e-commerce qui propose du contenu statique (pages institutionnelles, fiches produits, conseils, etc…) et des fonctionnalités dynamiques (recherche, comparatif, gestion de panier, …). On peut aussi citer les sites proposant des dashboards, des catalogues, des blogs, etc… 

Mais un meta-framework peut aussi être utilisé pour des applications métiers ne nécessitant pas de référencement. Dans ce cas l’utilisation du rendu côté serveur et les optimisations proposées apporteront des avantages en matière de performances, d’optimisation des ressources, d’expérience développeur et utilisateur.  

En fait la majorité des sites et applications web développés aujourd’hui gagnent à être développés à l’aide de meta-frameworks. À tel point que la documentation officielle de React recommande aujourd’hui l’utilisation de meta-frameworks comme Next.js ou Remix pour démarrer un projet. 

Pour le prochain site web que vous développerez, posez-vous donc la question de l’intérêt d’utiliser un meta-framework ! 

_________________________________________

PS : si vous voulez en savoir plus sur les différents modes de rendu, vous pouvez regarder le replay de la conférence « Rendez-moi mon front » donnée à Devoxx France en avril 2024 sur ce sujet.