Comment désactiver le rendu côté serveur dans Next.js

RSS dans Next.js

Next.js est devenu très populaire récemment car il est construit sur React. De plus, il possède des fonctionnalités prêtes à l’emploi qui sont parfois redondantes à implémenter sur les applications React telles que le rendu côté serveur, l’optimisation des images, le routage et les routes API.

Contrairement à une application React typique, Next.js prend en charge le SSR prêt à l’emploi. Cela signifie que Next.js permet aux pages d’être pré-compilées en HTML statique, au lieu de tout faire par JavaScript côté client. Le routage Next.js et d’autres configurations intégrées sont conçus principalement pour le SSR (Server Side Rendering) et l’exploration vers SSG (Static Site Generation).

Dans certains cas, vous n’avez pas besoin de SSR pour vos composants Next.js. Dans cet article, nous verrons comment vous pouvez désactiver SSR sur l’application Next.js.

Comprendre les concepts de rendu Next.js tels que SSR (rendu côté serveur), CSR (rendu côté client) et SSG (génération de site statique) peut vous aider à comprendre cet article. Si vous n’êtes pas familier avec ces concepts, vous pouvez lire cette section au bas de cet article.

Le problème

Même si le routage Next.js et d’autres configurations intégrées sont spécifiquement pour SSR et SSG, il peut arriver que vous souhaitiez désactiver SSR (Server-Side Rendering) sur une ou plusieurs pages spécifiques de votre application Next.js. Voici quelques exemples :

• Si le composant a besoin d’accéder à certaines propriétés uniquement disponibles dans le navigateur, comme le window ou localStorage.
• Vous voulez qu’une page se comporte comme une page React autonome sans SSR.
• Votre application a une dépendance externe sur les API du navigateur comme l’objet window.
• Vous préférez l’expérience de développeur de Next.js à React autonome en raison de choses comme le routage basé sur les fichiers et les temps de compilation rapides, mais vous n’avez pas besoin de SSR.
• Vous souhaitez désactiver temporairement SSR à des fins de débogage.
• Vous souhaitez désactiver le rendu côté serveur pour un composant ou une page entière afin de réduire la taille de votre bundle, car tous les utilisateurs n’auront pas besoin de cette fonctionnalité.

Comment désactiver le SSR dans NextJS

1. Ne réagissez pas au paquet ssr

C’est le moyen le plus rapide de désactiver le SSR. React-no-ssr fournit un composant qui encapsule des composants non SSR.

Installation:

Usage:

Supposons que le <AdminPanel /> Le composant doit être rendu côté client. Voici comment nous procédons.

Par ici <AdminPanel /> Le composant ne sera rendu sur le client qu’après avoir été monté. Il ne sera pas rendu pendant le chargement du HTML rendu côté serveur dans le navigateur.

Avec react-no-ssr, vous pouvez également ajouter une image ou un texte de préchargement qui sera rendu avant que le composant ne commence à être rendu.

La <Preloader /> le composant sera rendu jusqu’à <AdminPanel /> est rendu.

2. Utilisez l’importation dynamique

Vous pouvez également utiliser l’importation dynamique. Nous devrons créer un composant wrapper et envelopper toute page où vous souhaitez désactiver le SSR avec ce composant.

Supposons que vous souhaitiez désactiver le SSR sur une page. Importez le composant wrapper que vous avez créé ci-dessus.

Tout ce qui est enveloppé dans <NoSSRWrapper /> composant ne sera pas visible dans la source SSR.

Vérifiez si le rendu côté serveur est activé.

Après avoir effectué l’une des modifications ci-dessus, c’est une bonne idée de vérifier si nous avons réussi à désactiver le SSR. Nous pouvons y parvenir en vérifiant si l’objet window n’est pas défini.

Créons une fonction utilitaire pour vérifier ceci :

Si le SSR est désactivé, nous pourrons voir le <Main /> composant.

Pourquoi ne pouvons-nous pas utiliser la génération de site statique (SSG) ?

Même si SSG offre d’excellentes capacités de référencement, il a sa limite : le manque d’accès aux demandes entrantes. Il ne peut pas lire les en-têtes de requête ou les paramètres de requête d’URL. Sur SSG, toutes les pages de votre application sont générées en tant que fichiers .html individuels au moment de la construction. SSG est généré avant qu’une demande d’utilisateur n’ait lieu. Par conséquent, vous devez connaître à l’avance tous les chemins d’accès de votre application. Ce n’est pas possible avec les applications qui ont des itinéraires dynamiques comme /user/[id]/post/[pid].js.

RSE, SSR, SSG. Qu’est-ce que c’est?

Next.js prend en charge trois formes de rendu : le rendu côté client, la génération de site statique et le rendu côté serveur. La génération de site statique et le rendu côté serveur sont deux formes de méthodes de pré-rendu.

La différence significative entre ces rendus est lorsqu’il génère le code HTML d’une page.

1. Rendu côté client (CSR)

C’est ainsi que nous construisons des applications typiques dans React avec Create React App ou d’autres frameworks JavaScript.

1. Le site demandé par l’utilisateur
2. Le serveur envoie une réponse avec un minimum de HTML
3. Le navigateur télécharge le bundle de l’application JavaScript ou React. La page n’est pas visible.
4. Le navigateur exécute le framework, récupère les données requises et affiche les composants. Toute la logique, la récupération de données, la création de modèles et le routage sont gérés côté client. La page n’est pas visible.
5. La page est chargée et interactive

Avantages:

• Rapide sur le serveur – Parce que le serveur n’envoie qu’une page vierge, son rendu est très rapide.
• Idéal pour les applications à page unique – Le rendu côté client est le seul modèle qui prend en charge les applications à page unique. Nous permet de réutiliser les composants de l’interface utilisateur dans notre application, sans les redemander au serveur.

Les inconvénients:

• Pas de rendu initial – CSR peut prendre du temps pour rendre le site visible aux utilisateurs en cas d’Internet lent ou de grande taille de bundle. Un utilisateur voit une page vierge dans de tels scénarios, ce qui crée une mauvaise expérience utilisateur.
• Pas convivial pour le référencement – Parce qu’il est basé sur JavaScript, les robots d’indexation ne peuvent pas indexer le site vierge.

Cas d’utilisation:

Panneau d’administration – CSR est recommandé pour une page dans laquelle vous ne priorisez pas le référencement, lorsque le contenu n’a pas besoin de mises à jour fréquentes ou lorsque vous n’avez pas besoin de pré-rendre vos données.

2. Rendu côté serveur (SSR)

C’est ainsi que nous avons construit des pages Web à l’époque. Les pages SSR sont générées à chaque requête. Toute la logique, la récupération de données, la création de modèles et le routage sont gérés côté client avant que le site n’atteigne le navigateur.

1. Le site demandé par l’utilisateur
2. Le serveur récupère les données requises à partir d’une API et transmet ces données au composant React en tant qu’accessoires.
3. Le serveur envoie des fichiers HTML prêts à être rendus. Le site est visible mais non interactif.
4. Navigateur analysant l’application React dans le bundle JavaScript.
5. La page est visible et interactive.

Avantages:

• Contenu immédiatement disponible – L’utilisateur commencera à voir le contenu immédiatement car le serveur envoie une page terminée.
• Convivial pour le référencement – Idéal pour la visibilité SEO car le WebCrawler verra une page terminée.

Les inconvénients:

• Demande de serveur plus élevée – Chaque fois que l’utilisateur accède à une autre page du site Web, un nouveau fichier HTML est chargé. Cela nécessite une utilisation importante du serveur, qui a généralement un coût plus élevé.
• Incompatible avec certaines bibliothèques d’interface utilisateur – Certaines bibliothèques d’interface utilisateur dépendent d’un objet Windows qui n’existe pas lorsque la page est rendue par le serveur.

Cas d’utilisation:

Une page de résultats de recherche d’actualités ou un site de commerce électronique. SSR est recommandé pour les applications dans lesquelles vous devez pré-afficher des données fréquemment mises à jour à partir d’autres sources. Il est généralement utilisé lorsque les données ne peuvent pas être générées statiquement avant qu’une demande de l’utilisateur ne se produise.

Génération de site statique (SSG)

SSG est assez similaire au rendu côté serveur à l’exception que le HTML est généré au moment de la construction et sera réutilisé à chaque requête. Vous pouvez réutiliser (et recharger) la page entière à chaque requête.

Avantages:

• Contenu immédiatement disponible – L’utilisateur commencera à voir le contenu immédiatement car le serveur envoie une page terminée.
• Convivial pour le référencement – Idéal pour la visibilité SEO car le WebCrawler verra une page terminée.

Les inconvénients:

• Temps de construction longs – Les temps de construction peuvent être lents si le site est grand et contient beaucoup d’itinéraires.
• Incompatible avec certaines bibliothèques d’interface utilisateur – Certaines bibliothèques d’interface utilisateur dépendent d’un objet Windows qui n’existe pas lorsque la page est rendue par le serveur.

Cas d’utilisation:

Une page de blog ou à propos de nous car le contenu ne change pas très souvent. SSG est recommandé pour une utilisation sur toutes les pages où vous devez pré-afficher des données. Il peut être généré avant qu’une demande d’utilisateur n’ait lieu. Cela signifie que vos données sont disponibles au moment de la construction.