Google a déployé les Core Web Vitals en juin, dans le cadre de sa mise à jour Page Experience, tous les spécialistes du marketing qui n’ont pas encore examiné de plus près le SEO technique vont vouloir le faire maintenant.
Et lorsque votre site Web est construit sur des frameworks JavaScript, l’une des parties à creuser est le rendu côté serveur.
Qu’est-ce que le rendu côté serveur ?
On parle de rendu côté serveur lorsque le processus de récupération d’une page Web, de saisie du code, d’affichage du contenu sur un écran – tout cela se passe sur le serveur.
Dans SSR :
- Le serveur envoie une réponse prête à être rendue au navigateur ;
- Le navigateur rend la page, la rendant prête à être visualisée, puis le navigateur télécharge le JavaScript ;
- Le navigateur exécute ensuite React lorsque la page est prête à être visualisée, et
- La page Web est alors prête pour l’interactivité.
La façon dont tout cela se déroule en fait une meilleure option que les autres types de rendu : le rendu côté client (où le JavaScript est rendu par le navigateur, c’est-à-dire le client) et le rendu dynamique (où les utilisateurs obtiennent un contenu rendu côté client-serveur et les moteurs de recherche un contenu rendu côté serveur). Même Google encourage les développeurs web à choisir le rendu côté serveur.
Pourquoi le SSR est-il pertinent pour les CWV ?
Les développeurs Web et les spécialistes du SEO travaillent depuis des mois en prévision du déploiement de CWV. Environ 60 % des agences SEO interrogées ont été occupées à améliorer les scores CWV de leurs clients. Si vous utilisez le SSR, vous n’aurez peut-être pas à faire un travail considérable pour répondre aux attentes.
Étant donné que le SSR facilite la vitesse, votre site Web pourrait déjà obtenir de bons résultats avec l’une des mesures : le Largest Contentful Paint (LCP).
Le LCP se concentre sur l’expérience de chargement perçue. Il mesure le temps de chargement de la page lorsque la plus grande image ou le plus grand texte d’une page Web est visible dans la fenêtre d’affichage. L’objectif à atteindre pour obtenir un bon score est un chargement de page de 75 % à <2,5 secondes.
Les principaux obstacles à l’obtention d’un bon LCP sont les JS et CSS qui bloquent le rendu, la lenteur du chargement des ressources, la lenteur de la réponse du serveur et le rendu côté client.
Le passage au RSS n’est qu’une solution parmi d’autres pour améliorer le score LCP, car votre problème ne se limite peut-être pas au RSS. Vous voudrez travailler avec vos développeurs web pour identifier d’abord ce qui cause le retard de votre LCP.
Si la source de la page révèle un code qui n’a pas de sens (et votre développeur vous le dira), le problème peut être le CSR. Si votre développeur découvre que le TTFB est médiocre, alors vous avez peut-être affaire à un temps de réponse lent du serveur.
Les autres mesures de CWV sont les suivantes :
- First Input Delay, qui se concentre sur la réactivité, et
- Cumulative Layout Shift, qui se concentre sur la stabilité visuelle.
Ces deux mesures ne sont pas pertinentes pour le SSR, et vous devriez donc y consacrer plus d’efforts puisque le SSR prend partiellement en charge le LCP.
Comment savoir si le SSR rend correctement les pages Web ?
La meilleure façon de savoir si le SSR rend bien vos pages est d’utiliser des outils. L’un d’entre eux est le test « Mobile Friendly ». Il s’agit d’un outil qui vous fournit un instantané de la façon dont vos pages Web apparaîtront aux robots Google et vous indique les erreurs de rendu, le cas échéant.
Google Search Console dispose également d’un outil d’inspection des URLs qui vous permet de voir si le moteur de recherche rend vos pages. Utilisez-le pour vérifier l’absence de contenu ou toute erreur liée à un JavaScript ou CSS bloqué.
Vous pouvez également consulter l’outil View Render Source, qui est une extension Chrome gratuite. Elle vous indiquera comment le navigateur effectue le rendu d’une page, de son HTML d’origine à un DOM fonctionnel. L’extension illustrera la différence entre une version brute et une version rendue, en mettant en évidence la façon dont le JS a modifié les pages au moment du rendu.
Une autre extension Chrome à essayer est SiteCrawler. Ce robot capable de lire les JS parcourt les plans de site, les liens et les images et compare les pages en HTML uniquement et celles en JS.
La conclusion
Une grande partie du travail de SEO consiste à optimiser des pages qui ont déjà été « livrées » au client ou au navigateur. Mais lorsque vous examinez comment ces pages « arrivent » au client et comment vous pouvez améliorer ce processus, les utilisateurs passent un meilleur moment sur votre site Web.
Les robots explorent vos pages correctement. Vos pages sont indexées. Votre site est mieux positionné dans les moteurs de recherche.
Les mises à jour des moteurs de recherche ainsi que les changements de comportement des consommateurs nécessitent également des modifications de votre site Web. Avec le déploiement des CWV, c’est le moment de s’intéresser à la RSS, un aspect technique qui affectera vos efforts de SEO.
