Depuis la nuit des temps, la méthode classique pour afficher votre code 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 les a transformés 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 à l’affichage d’images et de 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 bien plus avancé qu’avant.

Il est donc logique que le rendu côté serveur commence lentement à prendre le pas sur 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 envisagez de faire avec votre site Web. Vous devez comprendre les avantages et les inconvénients, puis décider vous-même quel itinéraire vous convient le mieux.

Comment fonctionne le rendu côté serveur

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

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

• Votre vitesse internet
• l'emplacement du serveur
• combien d'utilisateurs essaient d'accéder au site
• et comment le site Web est optimisé, pour ne citer que quelques

Une fois le traitement de la demande terminé, votre navigateur récupère le code HTML entièrement restitué et l'affiche à l'écran. Si vous décidez ensuite de visiter une autre page du site Web, votre navigateur demandera à nouveau les nouvelles informations. Cela se produira chaque fois que vous visiterez une page pour laquelle votre navigateur ne possède pas de version en cache.

Peu importe que la nouvelle page ne contienne que quelques éléments différents de la page actuelle, le navigateur demandera la totalité de la nouvelle page et refera tout le rendu à partir de la base.

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

  
    
    
  
  
    
Mon site internet
    
Ceci est un exemple de mon nouveau site web
    Lien
  

Si vous deviez saisir l'adresse de l'exemple de site Web dans l'URL de votre navigateur imaginaire, celui-ci adresserait une requête au serveur utilisé par cette URL et attendrait une réponse de 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.

  
    
    
  
  
    
Mon site internet
    
Ceci est un exemple de mon nouveau site web
    
Ceci est un peu plus de contenu de l'autre.html
  

La seule différence entre la page précédente et celle-ci est que cette page n'a pas de lien mais 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 arriverait en réalité serait que toute la nouvelle page soit 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 naviguez sur une page Web et que vous deviez attendre que chaque page soit rendue lors de la navigation 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 excellent pour le référencement. Votre contenu est présent avant que vous ne le récupériez, afin que les moteurs de recherche puissent l'indexer et l'explorer correctement. Ce qui n’est pas le cas avec le rendu côté client. Du moins pas simplement.

Comment fonctionne le rendu côté client

Lorsque les développeurs parlent de rendu côté client, ils parlent de restitution 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, qui n’est vraiment devenue populaire que lorsque les bibliothèques JavaScript ont commencé à l’intégrer à leur style de développement. Quelques exemples notables sont Vue.js et React.js, sur lesquels j’ai écrit plus à propos ici.

En revenant sur le site précédent, exemple.testsite.com, supposons que vous ayez maintenant un fichier index.html avec les lignes de code suivantes.

Vous pouvez voir tout de suite que des modifications majeures ont été apportées au fonctionnement du fichier index.hmtl 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 body de fermeture. Une qui chargera la bibliothèque JavaScript Vue.js et une autre qui chargera un fichier nommé 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 de la charge nue du site Web. Le passe-partout principal. Tout le reste est géré par une bibliothèque JavaScript côté client, en l'occurrence Vue.js, et du 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 avec JavaScript.

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

var data = 
        titre: "Mon site",
        message: "Ceci est un exemple de mon nouveau site web"
      
  Vue.component ('app', 
    modèle:
    `
    

    
Titre
    
message
    Lien
    
    
    
    
    `,
    data: function () 
      renvoyer des données;
    ,
    méthodes: 
      newContent: function () 
        var node = document.createElement ('p');
        var textNode = document.createTextNode ('Ceci est encore du contenu de l'autre.html');
        node.appendChild (textNode);
        document.getElementById ('moreContent'). appendChild (node);
      
    
  )
  nouveau Vue (
    el: '#root',
  );

Maintenant, si vous visitez l'URL, vous verrez le même contenu que celui de l'exemple côté serveur. La principale différence est que si vous cliquez sur le lien de la page pour charger plus de contenu, le navigateur ne fera aucune autre demande au serveur. Vous rendez les éléments avec le navigateur. Il utilisera donc JavaScript pour charger le nouveau contenu et Vue.js s'assurera que seul le nouveau contenu est rendu. Tout le reste sera laissé seul.

Ceci est beaucoup plus rapide car vous ne chargez qu'une très petite section de la page pour récupérer le nouveau contenu, au lieu de charger la page entière.

Cependant, l'utilisation du rendu côté client présente certains inconvénients. Étant donné que le contenu n'est pas rendu tant que la page n'est pas chargée sur le navigateur, le référencement du site Web prendra un coup. Il existe des moyens de contourner ce problème, mais ce n’est pas aussi facile qu’avec le rendu côté serveur.

Une autre chose à garder à l’esprit est que votre site Web / votre application ne pourra pas être chargé tant que TOUT le JavaScript ne sera pas téléchargé sur le navigateur. Ce qui est logique, car il contient tout le contenu nécessaire. Si vos utilisateurs utilisent une connexion Internet lente, le temps de chargement initial pourrait être un peu long.

Les avantages et les inconvénients de chaque approche

Donc là vous l'avez. Ce sont les principales différences entre le rendu côté serveur et le rendu côté client. Seul le développeur peut décider de la meilleure option pour votre site Web ou votre application.

Vous trouverez ci-dessous une ventilation rapide des avantages et des inconvénients de chaque approche:

Avantages côté serveur:

1. Les moteurs de recherche peuvent explorer le site pour un meilleur référencement.
2. Le chargement initial de la page est plus rapide.
3. Idéal pour les sites statiques.

Inconvénients côté serveur:

1. Requêtes fréquentes du serveur.
2. Un rendu de page global lent.
3. Recharges pleine page.
4. Interactions de sites non riches.

Avantages côté client:

1. Interactions de site riches
2. Rendu rapide de site Web après le chargement initial.
3. Idéal pour les applications Web.
4. Sélection robuste de bibliothèques JavaScript.

Inconvénients côté client:

1. Faible référencement si non implémenté correctement.
2. Le chargement initial peut nécessiter plus de temps.
3. Dans la plupart des cas, nécessite une bibliothèque externe.

Si vous voulez en savoir plus sur Vue.js, visitez VueReactor.com. Vous pouvez également visiter juanmvega.com pour vous tenir au courant de mes dernières histoires.