Des temps de chargement de pages Web plus rapides 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 pour l'algorithme de Google.
Un développeur Web front-end doit décider de la meilleure façon de restituer 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. Par conséquent, comprendre la différence entre le rendu côté client et côté serveur peut vous aider à rendre votre site Web conforme à 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 sur JavaScript via différents formats, à la fois officiels et non officiels.
Par exemple, dans un podcast Search Off The Record, il a été discuté du fait que Google restitue toutes les pages pour la recherche, y compris celles qui utilisent beaucoup de JavaScript.
Cela a suscité une conversation substantielle sur LinkedIn, et quelques autres points à retenir du podcast et des discussions qui ont suivi sont les suivants :
- Google ne suit pas le coût du rendu de pages spécifiques.
- Google rend toutes les pages pour voir le contenu, qu'il utilise JavaScript ou non.
La conversation dans son ensemble a contribué à dissiper de nombreux mythes et idées fausses sur la façon dont Google pourrait avoir approché JavaScript et alloué des ressources.
Le commentaire complet de Martin Splitt sur LinkedIn à ce sujet était :
« Nous ne nous demandons pas combien cette page nous a coûté ou autre chose. Nous savons qu'une grande partie du Web utilise JavaScript pour ajouter, supprimer et modifier le contenu des pages Web. Il nous suffit de le restituer 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 restitué. »
Martin a également confirmé l'existence d'une file d'attente et d'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.
Bonnes pratiques générales JavaScript
Avant d'entrer dans le débat côté client ou côté serveur, il est important que nous suivions également les meilleures pratiques générales pour que l'une ou l'autre de ces approches fonctionne :
- 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 fonctionne-t-il ?
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 rendant le JavaScript d'un site Web dans votre navigateur plutôt que sur le serveur.
Le serveur répond avec un document HTML basique 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 des données à partir d'une API, les sites rendus par le client font tout « de manière indépendante ». 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 de manière dynamique.
Le processus RSE est le suivant :
- L'utilisateur entre 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 livre les fichiers statiques (CSS et HTML) au navigateur du client.
- Le navigateur client télécharge d'abord le contenu HTML, suivi du JavaScript. Ces fichiers HTML connectent le JavaScript, démarrant le processus de chargement en affichant les symboles de chargement définis par le développeur à l'utilisateur. À ce stade, le site Web n'est toujours pas visible pour 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 lorsque le client navigue et interagit avec le site Web.
Qu’est-ce que le rendu côté serveur et comment fonctionne-t-il ?
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 des données spécifiques à l'utilisateur à renseigner 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ète l'ensemble du processus.
Voici comment se déroule le processus SSR étape par étape :
- L'utilisateur entre l'URL qu'il souhaite visiter dans la barre d'adresse.
- Le serveur fournit au navigateur une réponse HTML prête à être rendue.
- Le navigateur rend 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 confère au rendu côté serveur un avantage 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, ce qui facilite l'indexation de vos pages Web. Cette lisibilité sous forme de texte correspond précisément à la manière dont les sites SSR apparaissent dans le navigateur.
Cependant, le rendu côté client est une option moins chère pour les propriétaires de sites Web.
Il allège la charge sur vos serveurs, en transférant la responsabilité du rendu au client (le robot ou l'utilisateur qui essaie de visualiser votre page). Il offre également des interactions de site enrichies en fournissant une interaction rapide avec 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.
Le SSR peut également céder sous une charge de serveur élevée si le serveur reçoit de nombreuses requêtes simultanées de différents utilisateurs.
L'inconvénient de la 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 quitter le site.
Cette approche en deux phases peut entraîner l'apparition de contenu vide sur votre page en raison de l'absence de contenu JavaScript après la première exploration et indexation du code HTML d'une page. N'oubliez pas que, dans la plupart des cas, la CSR 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 bon classement 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 mis ici sur un site riche avec de nombreux utilisateurs, privilégiant l'expérience utilisateur par rapport au référencement.
Qu'est-ce qui 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 positionnement dans les SERP et sur l'expérience utilisateur de votre site Web.
En général, le CSR est plus adapté aux sites Web dynamiques, tandis que le SSR est mieux adapté aux sites Web statiques.
Fréquence de rafraîchissement du contenu
Les sites Web qui présentent des informations très dynamiques, tels que les sites Web de jeux d'argent ou de FOREX, mettent à jour leur contenu toutes les secondes, ce qui signifie que vous choisirez probablement le CSR plutôt que le SSR dans ce scénario – ou choisirez d'utiliser le CSR 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 la part de l'utilisateur. Il influence positivement l'accessibilité, les temps de chargement des pages, le référencement et le support des médias sociaux.
D'autre part, le CSR est excellent pour fournir un rendu rentable pour les applications Web, et il est plus facile à créer et à entretenir ; il est meilleur pour le First Input Delay (FID).
Une autre considération CSR 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 les identifient le plus rapidement possible, et n'apparaissent pas seulement dans le HTML rendu.
Considérations relatives à la plateforme
La technologie CSR a tendance à être plus coûteuse à entretenir car le taux horaire des développeurs qualifiés 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 frameworks CSR par rapport à l'écosystème de plugins plus vaste auquel les utilisateurs de WordPress ont accès.
Pour ceux qui envisagent une configuration WordPress sans tête, comme l'utilisation de Frontity, il est important de noter que vous devrez embaucher à la fois des développeurs React.js et des développeurs PHP.
C'est parce que WordPress headless s'appuie sur React.js pour le front-end tout en nécessitant PHP pour le back-end.
Il est important de se rappeler que tous les plugins WordPress ne sont pas compatibles avec les configurations headless, ce qui peut limiter les fonctionnalités ou nécessiter un développement personnalisé supplémentaire.
Fonctionnalité et objectif du site Web
Parfois, vous n'avez pas à choisir entre les deux, car des solutions hybrides sont disponibles. La SSR et la CSR peuvent toutes deux être mises en œuvre sur un seul site Web ou une seule page Web.
Par exemple, sur une place de marché en ligne, les pages contenant des descriptions de produits peuvent être rendues sur le serveur, car elles sont statiques et doivent être facilement indexées par les moteurs de recherche.
En restant dans le commerce électronique, si vous avez des niveaux élevés de personnalisation pour les utilisateurs sur un certain nombre de pages, vous ne pourrez pas restituer 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 sans état.
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.
La CSR et la SSR sont toutes deux des approches populaires pour le rendu des sites Web. Vous et votre équipe devez prendre cette décision au stade initial du développement du produit.
Plus de ressources :
