Rendu côté client et côté serveur: pourquoi ce n'est pas tout en noir et blanc

Depuis la nuit des temps, la méthode conventionnelle pour afficher votre HTML sur un écran consistait à utiliser le rendu côté serveur. C'était le seul moyen. Vous avez chargé vos pages .html sur votre serveur, puis votre serveur est allé les transformer en documents utiles sur les navigateurs de vos utilisateurs.

Le rendu côté serveur fonctionnait également très bien à l'époque, car la plupart des pages Web étaient principalement destinées à afficher des images et du texte statiques, avec peu d'interactivité.

Avance rapide jusqu'à aujourd'hui et ce n'est plus le cas. Vous pourriez soutenir que les sites Web de nos jours ressemblent davantage à des applications prétendant être des sites Web. Vous pouvez les utiliser pour envoyer des messages, mettre à jour des informations en ligne, faire des achats et bien plus encore. Le Web est beaucoup plus avancé qu'il ne l'était auparavant.

Il est donc logique que le rendu côté serveur commence lentement à prendre du recul par rapport à la méthode toujours croissante de rendu des pages Web côté client.

Alors, quelle méthode est la meilleure option? Comme pour la plupart des choses en développement, cela dépend vraiment de ce que vous prévoyez de faire avec votre site Web. Vous devez comprendre les avantages et les inconvénients, puis décider par vous-même de l'itinéraire qui vous convient le mieux.

Fonctionnement du rendu côté serveur

Le rendu côté serveur est la méthode la plus courante pour afficher des informations à l'écran. Il fonctionne en convertissant les fichiers HTML du serveur en informations utilisables pour le navigateur.

Chaque fois que vous visitez un site Web, votre navigateur fait une demande au serveur qui contient le contenu du site Web. La requête ne prend généralement que quelques millisecondes, mais cela dépend finalement d'une multitude de facteurs:

  • Votre vitesse Internet
  • l'emplacement du serveur
  • combien d'utilisateurs tentent d'accéder au site
  • et à quel point le site Web est optimisé, pour n'en nommer que quelques-uns

Une fois le traitement de la demande terminé, votre navigateur récupère le code HTML entièrement rendu et l'affiche à l'écran. Si vous décidez ensuite de visiter une autre page du site Web, votre navigateur effectuera à nouveau une nouvelle demande pour les nouvelles informations. Cela se produit à chaque fois que vous visitez une page dont votre navigateur n'a pas de version en cache.

Peu importe si la nouvelle page ne contient que quelques éléments différents de la page actuelle, le navigateur demandera la nouvelle page entière et le rendra à nouveau à partir de zéro.

Prenons par exemple ce document HTML qui a été placé dans un serveur imaginaire avec une adresse HTTP de example.testsite.com.

    Example Website   

My Website

This is an example of my new website

Link

Si vous deviez saisir l'adresse de l'exemple de site Web dans l'URL de votre navigateur imaginaire, votre navigateur imaginaire ferait une demande au serveur utilisé par cette URL et attendrait une réponse d'un texte à afficher sur le navigateur. Dans ce cas, ce que vous verriez visuellement serait le titre, le contenu du paragraphe et le lien.

Supposons maintenant que vous vouliez cliquer sur le lien de la page rendue qui contient le code suivant.

    Example Website   

My Website

This is an example of my new website

This is some more content from the other.html

La seule différence entre la page précédente et celle-ci est que cette page n'a pas de lien et à la place un autre paragraphe. La logique voudrait que seul le nouveau contenu soit rendu et que le reste soit laissé seul. Hélas, ce n'est pas ainsi que le rendu côté serveur fonctionne. Ce qui se passerait réellement serait que la nouvelle page entière serait rendue, et pas seulement le nouveau contenu.

Bien que cela ne semble pas être un gros problème pour ces deux exemples, la plupart des sites Web ne sont pas aussi simples. Les sites Web modernes ont des centaines de lignes de code et sont beaucoup plus complexes. Imaginez maintenant que vous parcourez une page Web et que vous deviez attendre que chaque page s'affiche lorsque vous naviguez sur le site. Si vous avez déjà visité un site WordPress, vous avez vu à quel point ils peuvent être lents. Ceci est une des raisons.

Du côté positif, le rendu côté serveur est idéal pour le référencement. Votre contenu est présent avant que vous ne l'obteniez, les moteurs de recherche peuvent donc l'indexer et l'explorer très bien. Quelque chose qui n'est pas le cas avec le rendu côté client. Du moins pas simplement.

Fonctionnement du rendu côté client

Lorsque les développeurs parlent de rendu côté client, ils parlent de rendu du contenu dans le navigateur à l'aide de JavaScript. Ainsi, au lieu d'obtenir tout le contenu du document HTML lui-même, vous obtenez un document HTML simple avec un fichier JavaScript qui rendra le reste du site à l'aide du navigateur.

Il s'agit d'une approche relativement nouvelle du rendu des sites Web, et elle n'est vraiment devenue populaire que lorsque les bibliothèques JavaScript ont commencé à l'intégrer dans leur style de développement. Quelques exemples notables sont Vue.js et React.js, sur lesquels j'ai écrit plus en détail ici.

Pour revenir au site Web précédent example.testsite.com, supposons que vous disposez maintenant d'un fichier index.html avec les lignes de code suivantes.

    Example Website 

Vous pouvez voir tout de suite qu'il y a des changements majeurs dans la façon dont index.hmtl fonctionne lors du rendu à l'aide du client.

Pour commencer, au lieu d'avoir le contenu dans le fichier HTML, vous avez un conteneur div avec un identifiant root. Vous avez également deux éléments de script juste au-dessus de la balise de fermeture du corps. Celui qui chargera la bibliothèque JavaScript Vue.js et celui qui chargera un fichier appelé app.js.

Ceci est radicalement différent de l'utilisation du rendu côté serveur car le serveur n'est désormais responsable que du chargement du strict minimum du site Web. Le passe-partout principal. Tout le reste est géré par une bibliothèque JavaScript côté client, dans ce cas, Vue.js et un code JavaScript personnalisé.

Si vous deviez faire une demande à l'URL avec uniquement le code ci-dessus, vous obtiendrez un écran vide. Il n'y a rien à charger car le contenu réel doit être rendu en utilisant JavaScript.

Pour résoudre ce problème, vous devez placer les lignes de code suivantes dans le fichier app.js.

var data = { title:"My Website", message:"This is an example of my new website" } Vue.component('app', { template: ` 

{{title}}

{{message}}

Link `, data: function() { return data; }, methods:{ newContent: function(){ var node = document.createElement('p'); var textNode = document.createTextNode('This is some more content from the other.html'); node.appendChild(textNode); document.getElementById('moreContent').appendChild(node); } } }) new Vue({ el: '#root', });

Now if you visit the URL, you would see the same content as you did the server-side example. The key difference is that if you were to click on the link the page to load more content, the browser will not make another request to the server. You are rendering items with the browser, so it will instead use JavaScript to load the new content and Vue.js will make sure that only the new content is rendered. Everything else will be left alone.

This is much faster since you are only loading a very small section of the page to fetch the new content, instead of loading the entire page.

There are some trade offs with using client-side rendering, though. Since the content is not rendered until the page is loaded on the browser, SEO for the website will take a hit. There are ways to get around this, but it’s not as easy as it is with server-side rendering.

Another thing to keep in mind is that your website/application won’t be able to load until ALL of the JavaScript is downloaded to the browser. Which makes sense, since it contains all the content that will be needed. If your users are using slow internet connection, it could make their initial loading time a bit long.

The pros and cons of each approach

So there you have it. Those are the main differences between server-side and client-side rendering. Only you the developer can decide which option is best for your website or application.

Below is a quick breakdown of the pros and cons for each approach:

Server-side pros:

  1. Search engines can crawl the site for better SEO.
  2. The initial page load is faster.
  3. Great for static sites.

Server-side cons:

  1. Frequent server requests.
  2. An overall slow page rendering.
  3. Full page reloads.
  4. Non-rich site interactions.

Client-side pros:

  1. Rich site interactions
  2. Fast website rendering after the initial load.
  3. Great for web applications.
  4. Robust selection of JavaScript libraries.

Client-side cons:

  1. Low SEO if not implemented correctly.
  2. Initial load might require more time.
  3. In most cases, requires an external library.

If you want to learn more about Vue.js, check out my website at juanmvega.com for videos and articles!