Stratégies de rendu dans Next.js

Bonjour, ça fait longtemps que je ne vois pas ! Comment va tout le monde ?

Récemment, j'ai plongé profondément dans Next.js 15, révisant certains concepts fondamentaux et explorant un nouveau sujet favori : les stratégies de rendu. Celui-ci s'adresse à toute personne curieuse de connaître les tenants et les aboutissants du SSR (Server-Side Rendering) et de toutes ses stratégies sœurs dans Next.js. Que vous débutiez ou que vous ayez besoin d'un rappel, considérez ceci comme votre mémo incontournable sur les stratégies de rendu !

SSR (rendu côté serveur) dans Next.js vs CSR (rendu côté client)

Comment fonctionne la RSS

En SSR, Next.js pré-rend la page sur le serveur à chaque requête. Si vous avez déjà ajouté une requête de récupération en haut d'un composant fonctionnel dans Suivant, puis cliquez sur Actualiser pour mettre à jour les données, vous utilisez déjà SSR.

Ce qui change la donne avec les dernières mises à jour est la fonctionnalité serverComponentsHmrCache. Cela nous permet de mettre en cache les réponses de récupération dans les composants du serveur lors des actualisations HMR (remplacement de module à chaud) en mode développement. Ainsi, chaque actualisation devient une expérience plus rapide, moins chère et plus efficace, en particulier lorsque des appels API facturés sont impliqués.

Avantages de la RSS :

1. Temps de chargement initial amélioré : plus rapide que CSR, en particulier pour les nouveaux visiteurs.
2. Optimisé pour le référencement : les moteurs de recherche adorent le SSR car le contenu est prêt lorsqu'ils sont explorés.
3. FCP (First Contentful Paint) réduit : expérience de chargement perçue plus rapide pour les utilisateurs.
4. Appels directs à la base de données : avec SSR, la logique de récupération des données peut rester côté serveur, ce qui rend les appels directs à la base de données possibles sans avoir besoin de créer des points de terminaison d'API.
5. Déduplication automatique des demandes : un avantage moins connu : lorsque les mêmes données sont demandées plusieurs fois, une seule demande est envoyée.
6. Sécurité améliorée : conserve les données sensibles côté serveur, sans jamais exposer les clés API sur le client.
7. Cascade réseau réduite : SSR récupère les données en parallèle, évitant ainsi les retards séquentiels.
8. JS facultatif : les utilisateurs peuvent toujours accéder au contenu si JavaScript est désactivé dans leur navigateur.

RSE (rendu côté client)

En CSR, vous commencez par déclarer un état vide et effectuez une requête de récupération dans useEffect. Une fois les données arrivées, vous mettez à jour l'état et l'interface utilisateur.

Compromis :

1. Page vide au début : les utilisateurs voient une coque vide jusqu'à ce que les données soient chargées, ce qui peut avoir un impact sur l'expérience utilisateur et le référencement.
2. Contrôle total de l'état : idéal pour les pages interactives où les actions des utilisateurs déclenchent des mises à jour.

Présentation des stratégies de rendu

Passons en revue chacune de ces méthodes de rendu, en soulignant quand et pourquoi vous choisiriez l'une plutôt que l'autre.

SSG (génération de sites statiques)

SSG génère du HTML au moment de la construction, qui peut être diffusé très rapidement à partir d'un CDN. Cependant, il ne convient pas aux sites Web dont le contenu est fréquemment mis à jour. C'est aussi la stratégie de rendu par défaut de Next.js.

ISR (régénération statique incrémentielle)

ISR est le frère flexible de SSG. Il permet de mettre à jour le contenu même après la création initiale, ce qui le rend parfait pour les sites Web qui changent occasionnellement mais ne nécessitent pas de données en temps réel. Ajoutez simplement export const revalidate = pour le configurer par page, ou utilisez revalidatePath et revalidateTag pour une revalidation plus ciblée.

SSR (rendu côté serveur)

SSR affiche les pages sur le serveur pour chaque demande de l'utilisateur, ce qui signifie que le contenu est toujours frais. Il est idéal pour les contenus très dynamiques, même s’il peut être plus lent que SSG puisque les pages sont générées à la demande. SSR brille dans les scénarios où le contenu à jour est important mais où l’interactivité côté client n’est pas cruciale.

PPR (rendu progressif des pages)

PPR introduit une approche hybride. Il fonctionne au niveau des composants plutôt qu'au niveau de la page, ce qui le rend unique. Un shell SSR statique sert initialement, tandis que le contenu dynamique est diffusé sous forme de composants enveloppés dans Suspense qui se chargent de manière asynchrone. Cela vous permet de mélanger et de faire correspondre SSR et CSR sur la même page, en servant immédiatement un shell statique et en le remplissant progressivement de contenu interactif.

Conclusion

Et c’est le tour d’horizon ! Chaque stratégie de rendu offre des avantages distincts en fonction des exigences de votre application. Jouez, expérimentez et trouvez la solution la mieux adaptée à votre cas d'utilisation !
Bon codage !

Crédits : Réalisé sur la base des ressources JS Mastery et avec une touche de formatage AI

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!