Côté client vs. Rendu côté serveur

Publié le par


Des temps de chargement plus rapides des pages Web jouent un rôle important dans l’expérience utilisateur et le référencement, la vitesse de chargement des pages étant un facteur déterminant clé pour l’algorithme de Google.

Un développeur Web front-end doit décider de la meilleure façon de rendre un site Web afin qu’il offre une expérience rapide et un contenu dynamique.

Deux méthodes de rendu populaires incluent le rendu côté client (CSR) et le rendu côté serveur (SSR).

Tous les sites Web ont des exigences différentes, donc comprendre la différence entre le rendu côté client et côté serveur peut vous aider à rendre votre site Web adapté à vos objectifs commerciaux.

Google et Javascript

Google dispose d’une documentation complète sur la manière dont il gère JavaScript, et les Googleurs proposent des informations et répondent régulièrement aux questions JavaScript via différents formats, officiels et non officiels.

Par exemple, dans un Rechercher le podcast Off The Recordil a été discuté du fait que Google restitue toutes les pages pour la recherche, y compris celles contenant beaucoup de JavaScript.

Cela a déclenché une conversation substantielle sur LinkedInet quelques autres points à retenir du podcast et des discussions qui ont suivi sont les suivants :

  • Google ne mesure pas le coût du rendu de pages spécifiques.
  • Google affiche toutes les pages pour voir le contenu, qu’il utilise ou non JavaScript.

La conversation dans son ensemble a contribué à dissiper de nombreux mythes et idées fausses sur la façon dont Google aurait pu a approché JavaScript et alloué des ressources.

Le commentaire complet de Martin Splitt sur LinkedIn à ce sujet était :

« Nous ne gardons pas la trace de « combien cette page a-t-elle coûté pour nous ? » ou quelque chose comme ça. Nous savons qu’une partie substantielle du Web utilise JavaScript pour ajouter, supprimer et modifier le contenu des pages Web. Il suffit de rendre, pour tout voir. Peu importe qu’une page utilise ou non JavaScript, car nous ne pouvons être raisonnablement sûrs de voir tout le contenu qu’une fois qu’il est rendu.

Martin a également confirmé une file d’attente et un délai potentiel entre l’exploration et l’indexation, mais pas seulement parce que quelque chose est JavaScript ou non, et ce n’est pas un problème « opaque » que la présence de JavaScript soit la cause première de la non-indexation des URL.

Meilleures pratiques générales JavaScript

Avant d’entrer dans le débat côté client/côté serveur, il est important que nous suivions également les meilleures pratiques générales pour l’une ou l’autre de ces approches de fonctionnement :

  • Ne bloquez pas les ressources JavaScript via Robots.txt ou les règles du serveur.
  • Évitez le blocage du rendu.
  • Évitez d’injecter du JavaScript dans le DOM.

Qu’est-ce que le rendu côté client et comment ça marche ?

Le rendu côté client est une approche relativement nouvelle du rendu de sites Web.

Il est devenu populaire lorsque les bibliothèques JavaScript ont commencé à l’intégrer, Angular et React.js étant parmi les meilleurs exemples de bibliothèques utilisées dans ce type de rendu.

Il fonctionne en affichant le JavaScript d’un site Web dans votre navigateur plutôt que sur le serveur.

Le serveur répond avec un document HTML simple contenant les fichiers JS au lieu d’obtenir tout le contenu du document HTML.

Bien que le temps de téléchargement initial soit un peu lent, les chargements de pages suivants seront rapides car ils ne dépendent pas d’une page HTML différente par itinéraire.

De la gestion de la logique à la récupération de données à partir d’une API, les sites rendus par les clients font tout « indépendamment ». La page est disponible après l’exécution du code car chaque page visitée par l’utilisateur et son URL correspondante sont créées dynamiquement.

Le Démarche RSE est la suivante :

  • L’utilisateur saisit l’URL qu’il souhaite visiter dans la barre d’adresse.
  • Une demande de données est envoyée au serveur à l’URL spécifiée.
  • Lors de la première requête du client sur le site, le serveur délivre les fichiers statiques (CSS et HTML) au navigateur du client.
  • Le navigateur client téléchargera d’abord le contenu HTML, suivi de JavaScript. Ces fichiers HTML connectent le JavaScript, démarrant le processus de chargement en affichant les symboles de chargement que le développeur définit à l’utilisateur. A ce stade, le site Internet n’est toujours pas visible par l’utilisateur.
  • Une fois le JavaScript téléchargé, le contenu est généré dynamiquement sur le navigateur du client.
  • Le contenu Web devient visible à mesure que le client navigue et interagit avec le site Web.

Qu’est-ce que le rendu côté serveur et comment ça marche ?

Le rendu côté serveur est la technique la plus courante pour afficher des informations sur un écran.

Le navigateur Web soumet une demande d’informations au serveur, récupère les données spécifiques à l’utilisateur à remplir et envoie une page HTML entièrement rendue au client.

Chaque fois que l’utilisateur visite une nouvelle page du site, le serveur répétera l’ensemble du processus.

Voici comment se déroule le processus SSR étape par étape :

  • L’utilisateur saisit l’URL qu’il souhaite visiter dans la barre d’adresse.
  • Le serveur fournit une réponse HTML prête à être restituée au navigateur.
  • Le navigateur affiche la page (maintenant visible) et télécharge JavaScript.
  • Le navigateur exécute React, rendant ainsi la page interactive.

Quelles sont les différences entre le rendu côté client et côté serveur ?

La principale différence entre ces deux approches de rendu réside dans les algorithmes de leur fonctionnement. CSR affiche une page vide avant le chargement, tandis que SSR affiche une page HTML entièrement rendue lors du premier chargement.

Cela donne au rendu côté serveur un avantage en termes de vitesse par rapport au rendu côté client, car le navigateur n’a pas besoin de traiter de gros fichiers JavaScript. Le contenu est souvent visible en quelques millisecondes.

Les moteurs de recherche peuvent explorer le site pour un meilleur référencement, facilitant ainsi l’indexation de vos pages Web. Cette lisibilité sous forme de texte est précisément la façon dont les sites SSR apparaissent dans le navigateur.

Cependant, le rendu côté client est une option moins coûteuse pour les propriétaires de sites Web.

Il soulage la charge de vos serveurs, en transférant la responsabilité du rendu au client (le bot ou l’utilisateur essayant de visualiser votre page). Il offre également des interactions riches sur le site en fournissant une interaction rapide sur le site Web après le chargement initial.

Moins de requêtes HTTP sont adressées au serveur avec CSR, contrairement à SSR, où chaque page est rendue à partir de zéro, ce qui entraîne une transition plus lente entre les pages.

SSR peut également céder sous une charge élevée du serveur si le serveur reçoit de nombreuses requêtes simultanées de différents utilisateurs.

L’inconvénient de CSR est le temps de chargement initial plus long. Cela peut avoir un impact sur le référencement ; les robots d’exploration peuvent ne pas attendre que le contenu se charge et quitte le site.

Cette approche en deux phases augmente la possibilité de voir du contenu vide sur votre page en manquant du contenu JavaScript après la première exploration et indexation du HTML d’une page. N’oubliez pas que, dans la plupart des cas, la RSE nécessite une bibliothèque externe.

Quand utiliser le rendu côté serveur

Si vous souhaitez améliorer votre visibilité sur Google et obtenir un classement élevé dans les pages de résultats des moteurs de recherche (SERP), le rendu côté serveur est le choix numéro un.

Les sites Web d’apprentissage en ligne, les marchés en ligne et les applications dotés d’une interface utilisateur simple avec moins de pages, de fonctionnalités et de données dynamiques bénéficient tous de ce type de rendu.

Quand utiliser le rendu côté client

Le rendu côté client est généralement associé à des applications Web dynamiques telles que les réseaux sociaux ou les messageries en ligne. En effet, les informations de ces applications changent constamment et doivent gérer des données volumineuses et dynamiques pour effectuer des mises à jour rapides afin de répondre à la demande des utilisateurs.

L’accent est ici mis sur un site riche avec de nombreux utilisateurs, en privilégiant l’expérience utilisateur sur le référencement.

Quel est le meilleur : le rendu côté serveur ou côté client ?

Pour déterminer quelle approche est la meilleure, vous devez non seulement prendre en compte vos besoins en matière de référencement, mais également la manière dont le site Web fonctionne pour les utilisateurs et offre de la valeur.

Pensez à votre projet et à l’impact du rendu choisi sur votre position dans les SERP et sur l’expérience utilisateur de votre site Web.

Généralement, la RSE convient mieux aux sites Web dynamiques, tandis que la SSR convient mieux aux sites Web statiques.

Fréquence d’actualisation du contenu

Les sites Web qui présentent des informations très dynamiques, tels que les sites de jeux d’argent ou de FOREX, mettent à jour leur contenu toutes les secondes, ce qui signifie que vous choisirez probablement la RSE plutôt que la SSR dans ce scénario – ou choisirez d’utiliser la RSE pour des pages de destination spécifiques et non pour toutes les pages, en fonction de votre stratégie d’acquisition d’utilisateurs.

Le SSR est plus efficace si le contenu de votre site ne nécessite pas beaucoup d’interaction de l’utilisateur. Cela influence positivement l’accessibilité, les temps de chargement des pages, le référencement et la prise en charge des médias sociaux.

D’un autre côté, CSR est excellent pour fournir un rendu rentable pour les applications Web, et il est plus facile à créer et à maintenir ; c’est mieux pour le First Input Delay (FID).

Une autre considération RSE est que les balises méta (description, titre), les URL canoniques et les balises Hreflang doivent être rendues côté serveur ou présentées dans la réponse HTML initiale pour que les robots d’exploration puissent les identifier dès que possible, et non seulement apparaître dans le rendu. HTML.

Considérations sur la plate-forme

La technologie RSE a tendance à être plus coûteuse à entretenir car le taux horaire des développeurs compétents en React.js ou Node.js est généralement plus élevé que celui des développeurs PHP ou WordPress.

De plus, il existe moins de plugins prêts à l’emploi ou de solutions prêtes à l’emploi disponibles pour les cadres RSE par rapport au plus grand écosystème de plugins auquel les utilisateurs de WordPress ont également accès.

Pour ceux qui envisagent une configuration WordPress sans tête, comme l’utilisation Frontièreil est important de noter que vous devrez embaucher à la fois des développeurs React.js et des développeurs PHP.

En effet, WordPress sans tête s’appuie sur React.js pour le front-end tout en nécessitant toujours PHP pour le back-end.

Il est important de se rappeler que tous les plugins WordPress ne sont pas compatibles avec les configurations sans tête, ce qui pourrait limiter les fonctionnalités ou nécessiter un développement personnalisé supplémentaire.

Fonctionnalité et objectif du site Web

Parfois, il n’est pas nécessaire de choisir entre les deux puisque des solutions hybrides sont disponibles. La SSR et la RSE peuvent être mises en œuvre sur un seul site Web ou une seule page Web.

Par exemple, sur un marché en ligne, les pages contenant des descriptions de produits peuvent être affichées sur le serveur, car elles sont statiques et doivent être facilement indexées par les moteurs de recherche.

En ce qui concerne le commerce électronique, si vous disposez de niveaux élevés de personnalisation pour les utilisateurs sur un certain nombre de pages, vous ne pourrez pas rendre le contenu SSR pour les robots. Vous devrez donc définir une forme de contenu par défaut pour Googlebot qui explore sans cookie et apatride.

Les pages telles que les comptes d’utilisateurs n’ont pas besoin d’être classées dans les pages de résultats des moteurs de recherche (SERP), donc une approche CRS pourrait être meilleure pour l’UX.

CSR et SSR sont des approches populaires pour le rendu de sites Web. Vous et votre équipe devez prendre cette décision dès la phase initiale du développement du produit.

Plus de ressources :

Image en vedette : TippaPatt/Shutterstock