Composants serveur et clients, l'impact SEO

Commençons par ce qui se passe vraiment quand un robot arrive sur une page. Sans ça, le reste ne veut rien dire.

Il demande une adresse et reçoit un document HTML. Si votre texte, vos titres et vos liens sont dans ce document, tout est lu en une fois. C'est le rendu serveur, et c'est le comportement par défaut de l'App Router.

Dans le cas contraire, le robot reçoit une coquille presque vide, avec une instruction de télécharger du code qui remplira la page. Google sait le faire. Il place la page dans une file d'attente et la traite dans une seconde vague de rendu.

3 conséquences, et ce sont elles qui comptent.

• Le délai. Cette seconde vague arrive plus tard. Sur un site d'actualité ou une fiche produit dont le prix bouge, ce décalage a un coût direct.
• L'incertitude. Rien ne garantit que cette étape ait lieu pour toutes vos pages. Elle coûte cher à Google, qui arbitre.
• Les autres robots. Bing est moins constant sur ce point, et les robots des intelligences artificielles le sont encore moins. Beaucoup ne lisent que le HTML reçu, sans jamais exécuter de code.

La conclusion est nette. Le rendu serveur ne sert pas à pouvoir être lu, il sert à être lu tout de suite, par tout le monde, sans condition.

Voici le geste qui règle 90 % du problème, et il est simple à appliquer.

Le réflexe naturel est mauvais. Une page a besoin d'un bouton avec un gestionnaire de clic, le développeur ajoute use client en haut du fichier, et le problème disparaît. Sauf qu'il vient de faire basculer la page entière, texte compris, du côté du navigateur.

La bonne méthode consiste à isoler l'interactivité.

• Créez un composant séparé qui ne contient que la partie interactive, le bouton, le champ de recherche, l'accordéon.
• Placez use client dans ce fichier-là, et nulle part ailleurs.
• Importez ce composant dans votre page, qui reste un composant serveur.

Le rendu visuel est strictement identique. La différence est invisible pour l'utilisateur et considérable pour les robots, puisque tout le contenu reste dans la réponse initiale.

Ce qui oblige réellement à passer côté client. Un gestionnaire d'événement, un état local, un effet, un accès au stockage du navigateur, ou n'importe quel hook React. Rien d'autre.

Une conséquence pratique à connaître, et elle est vicieuse. Une page en composant client ne peut pas exporter de metadata. L'export est simplement ignoré, sans le moindre message d'erreur. C'est la première cause de pages sans titre, comme nous le détaillons dans notre article sur la metadata Next.js.

Ce problème ne se voit pas à l'écran. Il se voit dans les journaux de votre base de données, et il finit par se voir sur la facture.

Le scénario est d'une banalité totale. Un tableau de bord affiche 5 blocs. Chacun a besoin de l'utilisateur courant, chacun le redemande. La même requête part 5 fois pour afficher une seule page. Sur un site à trafic, la base sature bien avant que quiconque comprenne pourquoi.

2 réponses selon votre outil d'accès aux données.

• Avec fetch, Next.js déduplique automatiquement. Le même appel vers la même adresse pendant un rendu ne part qu'une fois.
• Avec un ORM comme Prisma, ou avec Axios, cette déduplication n'existe pas. Il faut envelopper votre fonction d'accès dans cache, importé de React. Le résultat est mémorisé pour la durée du rendu, et les appels suivants avec les mêmes paramètres le réutilisent.

Le gain est immédiat et il se mesure. 5 requêtes deviennent 1, sans toucher une ligne de vos composants.

Un détail d'organisation qui évite des heures de débogage. Placez ces fonctions enveloppées dans un fichier séparé. Mélangées avec du code appelé depuis des actions serveur, l'import de React provoque des comportements incohérents.

Dernier levier sur le même thème, ne demandez que les champs utiles. Charger un objet complet avec toutes ses relations parce que c'est plus simple à écrire, c'est transporter des données inutiles jusqu'au navigateur. Et parfois y transporter des informations qui n'auraient jamais dû sortir du serveur.

Ce point n'a rien de spécifique à Next.js, mais il se perd toujours dans les projets React.

Une interface construite entièrement avec des blocs génériques oblige le robot à deviner ce que chaque zone contient. Les balises structurantes lui donnent la réponse sans effort.

Les 5 qui changent quelque chose.

• nav pour la navigation principale.
• header pour l'en-tête de page.
• main pour le contenu principal, une seule fois par page.
• article pour un contenu qui se tient seul, un billet, une fiche.
• footer pour le pied de page.

L'affichage est rigoureusement le même. Le gain porte sur la compréhension, pour les moteurs comme pour les technologies d'assistance, sujet que nous abordons dans notre article sur l'accessibilité numérique.

Ajoutez-y la hiérarchie des titres. Un seul titre principal par page, puis des intertitres qui descendent d'un niveau à la fois. Un intertitre choisi pour sa taille de police plutôt que pour son rang est une erreur classique, et elle brouille la lecture automatique de la page.

Pour vérifier tout cela d'un coup, l'audit Lighthouse des outils de développement note la partie référencement technique et l'accessibilité. Lancez-le sur le site déployé, jamais sur votre poste, où les chiffres sont toujours flatteurs.