.

Que Choisir pour un Site Web ? Rendu côté Serveur vs. Rendu côté Client

Dans cet article, nous discuterons des différences, des avantages et des inconvénients de ces deux solutions. Cependant, avant cela, nous vous rappellerons brièvement comment les sites web fonctionnent et comment il est possible que, peu importe l'appareil que nous utilisons pour naviguer sur le web, nous n'ayons besoin que d'une connexion internet et de tout appareil avec un navigateur.

Les débuts de HTML

Au début des années 1980, lorsque l'internet était encore à ses balbutiements (sous la forme de l'ARPANET), et bien avant l'apparition des premiers sites web, des scientifiques travaillaient sur la création d'un système qui permettrait de visionner à distance des documents situés sur un autre ordinateur. Ce système devait être fiable et fonctionner sur n'importe quel ordinateur, indépendamment du système d'exploitation et des spécifications. Il s'est avéré que les solutions les plus simples sont les meilleures, et envoyer des données en utilisant du texte avec des balises appropriées telles que header, footer, ou strong est la meilleure option. C'est ainsi que le HTML, qui est encore utilisé dans nos navigateurs pour afficher les pages web, a été créé.

Qu'est-ce que le rendu côté serveur ?

Maintenant que nous savons ce qu'est le HTML, nous devons répondre à la question d'où il provient. Comment est-il possible que, lorsque nous visitons un site web donné, le serveur renvoie un code spécifique ?

Au moment où le serveur reçoit une requête de notre navigateur, il doit traiter un grand volume d'informations, y compris vérifier si nous avons envoyé des cookies avec la requête. Si tel est le cas, le serveur vérifie :

  • quels fichiers ils sont,
  • s'ils contiennent des informations indiquant que nous sommes des utilisateurs connectés,
  • s'ils contiennent des informations indiquant que nous avons déjà visité le site donné et conservé certains de ses paramètres.

Ensuite, le serveur collecte des informations provenant d'autres sources (par exemple une base de données) sur ce qui doit être affiché à l'utilisateur. Dans le cas d'un blog, cela inclura le contenu des derniers articles ou des articles mis en avant.

Ayant toutes les informations nécessaires, le serveur nous envoie en réponse le code HTML que notre navigateur convertit du texte en une forme graphique.

Diagramme illustrant les étapes du rendu côté serveur d'un site web

Source : Duomly

Lorsque nous cliquons sur un lien pour ouvrir un autre article de blog, nous envoyons une autre requête au serveur et tout le processus recommence.

Pour et contre

La norme décrite ci-dessus pour la génération de code HTML est restée en vigueur presque depuis 1991, c'est-à-dire depuis le moment où le premier site web a été présenté au monde. C'est une solution ancienne mais éprouvée. En choisissant le rendu côté serveur, nous pouvons être presque sûrs que notre page web sera affichée correctement à tout moment et en tout lieu, indépendamment du système d'exploitation ou du navigateur.

Cependant, les lecteurs attentifs peuvent déjà percevoir un grave inconvénient de cette solution. Revenons à l'exemple de la page d'article. Après avoir lu le post, nous avons été intéressés par un autre texte qui est apparu dans la section Recommandé pour vous. Nous cliquons sur le lien, et que se passe-t-il ? Nous envoyons une requête au serveur pour générer le code HTML de toute la page, ainsi que le contenu du nouvel article. Mais nous avions en fait seulement besoin du contenu du nouvel article ! Le reste du code HTML a été généré inutilement. Cela entraîne une charge supplémentaire sur le serveur, ce qui, en cas de fort trafic sur le site, peut entraîner des problèmes de performance.

Quand choisir le rendu côté serveur ?

Il vaut la peine de choisir une telle solution lorsque nous voulons être sûrs que notre site web sera affiché correctement, peu importe qui le consulte. Gardons à l'esprit que de nos jours, non seulement les personnes réelles naviguent sur internet. Chaque jour, des pages web sont visitées par des robots de Google, dont la tâche est de déterminer si le contenu y est précieux et à quel point il devrait être classé dans les résultats de recherche. Jusqu'à récemment, ces robots étaient complètement incapables de gérer les sites web qui étaient rendus côté client (ce que nous décrirons plus loin dans le texte), et les robots de Facebook ne peuvent toujours pas le faire.

Qu'est-ce que le rendu côté client ?

Dans ce cas, le serveur traitant la requête effectue uniquement le minimum nécessaire de travail et renvoie en réponse du code JavaScript au lieu du code HTML. Ce qui est important, c'est que le code JS n'est pas généré "à la volée" par le serveur. C'est un fichier statique qui a été enregistré là auparavant.

Le code renvoyé contient les informations sur quel HTML doit être généré. Cette fois, notre navigateur génère ce code localement et affiche le site web graphiquement.

Explication graphique des étapes du rendu côté client d'un site web

Source : Duomly

Pour et contre

Comme vous pouvez probablement le deviner, le premier avantage est la réduction de la charge sur le serveur. Il n'a pas à générer le code HTML entier à chaque fois. C'est maintenant notre navigateur qui le fait. Cela permet au serveur de traiter plus de requêtes en même temps. Cela nous permet également de réduire les coûts liés à l'infrastructure.

En raison du fait que toutes les informations sur la façon dont le code HTML devrait être généré peuvent être trouvées dans notre navigateur, aller sur une nouvelle sous-page ne nécessite pas de la recharger. Le code HTML est modifié localement par notre navigateur, grâce à quoi l'utilisateur a l'impression que le site web fonctionne beaucoup plus rapidement et fonctionne davantage comme une application de bureau ou mobile qu'un site web traditionnel.

Le code JavaScript que notre navigateur reçoit dans le cas du rendu côté client est très similaire au code des applications mobiles ou de bureau. Grâce à cela, dans la plupart des cas, nous sommes en mesure d'étendre le fonctionnement de notre page web de manière très simple et à un faible coût. Elle deviendra à la fois un site web et une application mobile (PWA).

Malheureusement, cette solution n'est pas sans inconvénients. En raison du fait que nous recevons du code JavaScript en réponse du serveur, nous devons activer ce code dans le navigateur. Nous ne verrons aucun contenu sans cela. Il est vrai qu'aujourd'hui, chaque navigateur, récent et ancien, prend en charge ce code, mais comme nous l'avons mentionné plus tôt, internet n'est pas parcouru uniquement par les gens. Gérer ce code reste un problème pour les robots. Si nous voulons que le site soit classé le plus haut possible dans les résultats de recherche, et que les liens partagés vers notre page web soient présentés de manière moderne (avec des graphiques, un titre et une description de la page), le rendu côté client peut ne pas être la meilleure solution.

Dans quels cas est-il préférable de choisir le rendu côté client ?

Le rendu côté client est parfait dans le cas de sites web réactifs où l'utilisateur peut effectuer de nombreuses actions. Google Calendar ou Gmail sont de bons exemples de ce type de pages web. Cette solution fonctionnera également bien si nous nous soucions des utilisateurs utilisant des appareils mobiles, qui seront capables d'installer le site web sur un smartphone sous forme d'application.

Rendu côté client et côté serveur

Les deux solutions présentées ici ont leurs avantages et leurs inconvénients. Cela ne signifie pas, cependant, qu'en choisissant l'une nous devons renoncer aux avantages de l'autre. Il est possible de combiner ces méthodes.

Lorsqu'on visite un site web pour la première fois, le code HTML est généré du côté du serveur de manière traditionnelle et retourné sous cette forme au client. Cependant, le JavaScript est également envoyé avec ce code. Les interactions ultérieures sur la page web sont effectuées via le code JS téléchargé, de la même manière que dans le cas du rendu côté client.

Grâce à cela, nous sommes en mesure de combiner les avantages et d'éliminer les inconvénients des deux solutions mentionnées ci-dessus. Est-ce alors l'option parfaite ? Malheureusement, non. La solution hybride que nous présentons ici est beaucoup plus difficile à mettre en œuvre, et nécessite donc des employés plus qualifiés et prend plus de temps. Cela, à son tour, se traduit par des coûts d'implémentation plus élevés.

Le rendu côté serveur vs le rendu côté client - résumé

Le rendu côté client nous permet de créer des sites web modernes dont le fonctionnement ressemble davantage à des applications qu'à des pages web traditionnelles. Malheureusement, cela a un impact négatif sur les résultats de recherche. La solution intermédiaire n'est pas non plus sans inconvénients. Par conséquent, si vous envisagez de mettre en œuvre l'une de ces solutions sur votre page web, il est préférable de consulter des spécialistes du développement web. Après une analyse approfondie de vos besoins et spécifications, ils seront en mesure de choisir la meilleure solution pour vous.

3. Best practices for software development teams