1.Le problème fondamental du rendu web
Depuis les débuts du web moderne, les développeurs font face à un dilemme fondamental : vitesse ou personnalisation. Les pages statiques (HTML pré-généré) se chargent en un éclair, mais ne peuvent pas afficher de contenu personnalisé. Les pages dynamiques (générées à la volée sur le serveur) offrent une expérience sur mesure, mais au prix d'un temps de chargement plus long.
Ce compromis a donné naissance à une succession de stratégies de rendu, chacune tentant de résoudre l'équation : SSG (Static Site Generation), SSR (Server-Side Rendering), ISR (Incremental Static Regeneration), puis les React Server Components. Chaque approche apporte des améliorations, mais aucune n'élimine complètement le compromis.
Prenons l'exemple d'une page e-commerce. Le header de navigation, le footer, les descriptions produit et les images sont identiques pour tous les visiteurs. Mais le panier, les recommandations personnalisées et le prix affiché (qui peut varier selon la géolocalisation) sont dynamiques. Avec les approches traditionnelles, vous devez choisir : soit tout est statique et vous perdez la personnalisation, soit tout est dynamique et vous sacrifiez le LCP (Largest Contentful Paint).
C'est exactement ce problème que le Partial Prerendering (PPR) de Next.js 16 vient résoudre. Et la solution est aussi élégante qu'audacieuse : pourquoi choisir quand on peut avoir les deux ?
2.Le Partial Prerendering expliqué
Le Partial Prerendering est une nouvelle stratégie de rendu introduite par Vercel dans Next.js. Son principe est simple mais révolutionnaire : une même page peut être partiellement statique et partiellement dynamique. Le shell statique (layout, navigation, contenu fixe) est pré-rendu au moment du build et servi instantanément depuis le CDN, tandis que les parties dynamiques (données utilisateur, contenu personnalisé) sont streamées en parallèle depuis le serveur.
Concrètement, lorsqu'un utilisateur accède à une page PPR, voici ce qui se passe en coulisses :
Étape 1 — Réponse instantanée du CDN
Le shell HTML statique est servi immédiatement depuis l'edge, sans aucun calcul serveur. Le navigateur commence à afficher le contenu visible (header, texte, images) en quelques millisecondes.
Étape 2 — Placeholders pour le contenu dynamique
Les zones dynamiques affichent un état de chargement (skeleton, spinner) grâce aux Suspense boundaries de React. L'utilisateur voit immédiatement la structure de la page.
Étape 3 — Streaming du contenu dynamique
En parallèle, le serveur calcule les parties dynamiques (données utilisateur, prix, recommandations) et les envoie via HTTP streaming. Chaque partie apparaît dès qu'elle est prête, sans attendre les autres.
Étape 4 — Hydratation sélective
React hydrate uniquement les composants interactifs, pas le contenu statique. Le Time to Interactive (TTI) est réduit car moins de JavaScript doit s'exécuter.
Point technique : Le PPR repose sur deux piliers de React : les Server Components (pour le rendu côté serveur sans JavaScript client) et les Suspense boundaries (pour délimiter les zones statiques et dynamiques). Si vous utilisez déjà l'App Router de Next.js, vous êtes à mi-chemin.
La clé du PPR réside dans sa capacité à servir une réponse HTTP unique qui contient à la fois le HTML statique et les instructions de streaming. Il n'y a pas de requête supplémentaire, pas de waterfall de données, pas de flash of unstyled content. Le navigateur reçoit tout dans un seul flux, progressivement enrichi.
Pour le développeur, l'implémentation est élégante : il suffit d'envelopper les composants dynamiques dans un <Suspense> avec un fallback. Next.js détecte automatiquement quelles parties de la page sont statiques et lesquelles nécessitent un rendu dynamique. Pas de configuration complexe, pas de nouvelle API à apprendre.
3.PPR vs SSR vs SSG vs ISR : le match
Pour bien comprendre l'apport du PPR, comparons-le aux stratégies de rendu existantes. Chacune a ses forces et ses faiblesses, et le PPR ne les remplace pas toutes — il les complète en comblant un vide que les autres ne pouvaient pas remplir.
SSG
Les pages sont générées au moment du build. Le HTML est servi directement depuis le CDN sans calcul serveur.
Avantages
- + LCP ultra-rapide (CDN edge)
- + Coût serveur minimal
- + Sécurité maximale
Limites
- - Contenu figé entre les builds
- - Impossible de personnaliser
- - Builds longs sur gros sites
Impact LCP : Excellent (< 1s)
SSR
Chaque requête déclenche un rendu complet sur le serveur. Le HTML est généré à la volée avec des données fraîches.
Avantages
- + Contenu toujours à jour
- + Personnalisation possible
- + SEO garanti
Limites
- - LCP dépend du serveur
- - Coût CPU élevé
- - Pas de cache CDN natif
Impact LCP : Variable (1-3s)
ISR
Pages statiques régénérées en arrière-plan selon un intervalle de temps ou à la demande (on-demand revalidation).
Avantages
- + Bon compromis vitesse/fraîcheur
- + Cache CDN possible
- + Régénération transparente
Limites
- - Contenu potentiellement stale
- - Pas de personnalisation
- - Complexité de la revalidation
Impact LCP : Bon (< 1.5s)
PPR
Shell statique servi depuis le CDN + parties dynamiques streamées en temps réel depuis le serveur. Le meilleur des deux mondes.
Avantages
- + LCP instantané (shell statique)
- + Personnalisation en streaming
- + Une seule requête HTTP
Limites
- - Nécessite Next.js 16+
- - Architecture Suspense obligatoire
- - Edge runtime recommandé
Impact LCP : Excellent (< 1s)
En résumé : Le SSG reste imbattable pour les pages 100 % statiques (blog, documentation). Le SSR garde sa place pour les pages entièrement dynamiques (dashboards). L'ISR convient aux catalogues à mise à jour périodique. Mais pour les pages qui mélangent contenu fixe et personnalisé — soit la majorité des pages web modernes — le PPR est la réponse définitive.
4.Impact sur les Core Web Vitals
L'impact du PPR sur les Core Web Vitals est considérable, et c'est ce qui en fait un game-changer pour le SEO technique. Voici comment chaque métrique est affectée.
LCP (Largest Contentful Paint)
C'est la métrique la plus impactée. Avec le PPR, l'élément LCP (généralement une image hero ou un titre principal) fait partie du shell statique. Il est donc servi depuis le CDN sans aucun calcul serveur. Le résultat : un LCP systématiquement inférieur à 1 seconde, même sur des connexions mobiles 3G.
Sans PPR, une page qui affiche des données utilisateur doit attendre le rendu SSR complet avant d'envoyer le premier octet. Avec PPR, le shell est envoyé immédiatement pendant que le serveur calcule les données dynamiques. Le gain est typiquement de 40 à 60 % sur le LCP.
INP (Interaction to Next Paint)
Le PPR améliore indirectement l'INP grâce à l'hydratation sélective. Puisque les Server Components ne nécessitent pas d'hydratation côté client, la quantité de JavaScript exécutée au chargement diminue drastiquement. Le thread principal est libéré plus tôt, ce qui rend la page réactive plus rapidement.
De plus, le streaming progressif permet à React de prioriser l'hydratation des composants visibles dans le viewport, repoussant les composants hors écran. Résultat : les premières interactions sont traitées plus vite.
CLS (Cumulative Layout Shift)
Le PPR a un impact positif sur le CLS à condition d'utiliser correctement les Suspense boundaries. Les placeholders (skeletons) doivent avoir exactement les mêmes dimensions que le contenu final pour éviter les décalages de layout au moment où le contenu dynamique remplace le fallback.
La bonne pratique : utilisez des squelettes de chargement qui réservent l'espace exact du composant final. Next.js fournit des utilitaires pour cela, et les design systems modernes incluent des composants Skeleton prêts à l'emploi.
5.Architecture technique du PPR
Comprendre l'architecture sous-jacente du PPR est essentiel pour l'implémenter correctement. Le PPR repose sur trois couches technologiques qui travaillent ensemble.
Couche 1 : React Server Components & Suspense
Les React Server Components (RSC) sont le fondement du PPR. Un Server Component s'exécute exclusivement sur le serveur : il peut accéder directement à la base de données, lire des fichiers, appeler des API internes — sans envoyer un seul octet de JavaScript au client. Combiné avec Suspense, il permet de définir des frontières claires entre contenu statique et dynamique.
La règle est simple : tout ce qui est en dehors d'un <Suspense> est considéré comme statique et pré-rendu au build. Tout ce qui est à l'intérieur d'un <Suspense> est considéré comme dynamique et rendu à la demande par le serveur. Next.js analyse votre arbre de composants au moment du build pour générer le shell statique optimal.
Couche 2 : Edge Runtime & CDN
Le shell statique est déployé sur le CDN edge, au plus près des utilisateurs. Quand une requête arrive, le CDN sert immédiatement le HTML pré-rendu, puis proxifie la connexion vers le serveur d'origine pour le streaming dynamique. Cette architecture élimine le temps de calcul du rendu initial.
Sur Vercel, le PPR est optimisé pour le Edge Runtime, ce qui signifie que même les parties dynamiques bénéficient de la proximité géographique. Mais le PPR fonctionne aussi avec le Node.js Runtime classique si vos dépendances ne sont pas compatibles avec l'Edge.
Couche 3 : HTTP Streaming
Le PPR utilise le HTTP streaming (chunked transfer encoding) pour envoyer le contenu dynamique progressivement. Le navigateur reçoit d'abord le shell complet, puis des chunks HTML additionnels qui viennent remplacer les placeholders Suspense. Tout cela se fait dans une seule requête HTTP, sans WebSocket ni polling.
Ce streaming est rendu possible par le protocole de streaming de React, qui encode les mises à jour dans des balises <script> inline. Le navigateur les exécute au fur et à mesure de leur réception, mettant à jour le DOM sans rechargement. C'est transparent pour l'utilisateur : il voit simplement le contenu apparaître progressivement.
6.Cas d'usage concrets en production
Le PPR brille dans les scénarios où une page mélange contenu universel et contenu personnalisé. Voici les cas d'usage les plus impactants que nous avons observés chez nos clients.
E-commerce : Pages produit avec personnalisation
La fiche produit (titre, description, images, avis) est pré-rendue statiquement. Le prix localisé, la disponibilité en stock, les recommandations « les clients ont aussi acheté » et le bouton panier sont streamés dynamiquement. Résultat : un LCP de 0,8 s au lieu de 2,4 s en SSR pur, avec 15 % de conversions supplémentaires.
SaaS : Dashboards avec données temps réel
Le layout du dashboard (sidebar, navigation, titres de sections) est pré-rendu. Les graphiques, métriques et notifications sont streamés. L'utilisateur voit immédiatement la structure familière de son interface pendant que les données se chargent — éliminant l'effet « page blanche » qui cause 30 % d'abandon.
Médias : Articles avec contenu sponsorisé
Le contenu éditorial (article, images, sidebar) est statique. Les publicités ciblées, les recommandations d'articles personnalisées et les compteurs de partages sociaux sont dynamiques. Le LCP du contenu rédactionnel n'est plus pénalisé par le chargement des ads.
Marketplace : Listings avec filtres géolocalisés
La structure de la page de listing (header, catégories, filtres) est pré-rendue. Les résultats filtrés par localisation de l'utilisateur, les prix en devise locale et la disponibilité régionale sont streamés. L'expérience de navigation est fluide même sur les marchés avec des latences réseau élevées.
7.Migrer vers le PPR : guide pratique
La migration vers le PPR est incrémentale : vous pouvez l'activer page par page, sans refactoriser tout votre projet d'un coup. Voici les étapes clés pour une migration réussie.
Prérequis
- Next.js 16 ou supérieur : le PPR est stable à partir de cette version. Mettez à jour votre projet avec
npx @next/codemod@latest upgrade. - App Router activé : le PPR ne fonctionne pas avec le Pages Router. Si vous utilisez encore le Pages Router, planifiez d'abord votre migration vers l'App Router.
- React 19+ : les fonctionnalités de streaming et d'hydratation sélective nécessitent React 19 minimum.
- Identifier vos composants dynamiques : faites l'inventaire des parties de chaque page qui dépendent de données utilisateur, de cookies, de headers ou de géolocalisation.
Étapes de migration
- 1Activez le PPR dans votre next.config.ts avec l'option ppr: 'incremental'. Cela vous permet d'activer le PPR page par page.
- 2Ajoutez export const experimental_ppr = true dans chaque page que vous souhaitez migrer.
- 3Enveloppez les composants dynamiques dans des <Suspense> boundaries avec des fallbacks appropriés (skeletons qui respectent les dimensions finales).
- 4Utilisez les fonctions dynamiques de Next.js (cookies(), headers(), searchParams) uniquement à l'intérieur des Suspense boundaries pour marquer ces zones comme dynamiques.
- 5Testez avec next build && next start pour vérifier que le shell statique est correctement généré. Le build log indiquera les parties statiques et dynamiques de chaque page.
- 6Mesurez vos Core Web Vitals avant et après avec des données terrain (CrUX) pour quantifier l'amélioration.
Conseil de migration : Commencez par vos pages à plus fort trafic. L'impact sur les Core Web Vitals sera immédiatement visible dans la Search Console, et le ROI de la migration sera le plus élevé. Chez Veridian, nous accompagnons nos clients dans cette transition avec un audit technique préalable qui identifie les pages les plus impactantes.
8.L'avenir du rendu web après le PPR
Le PPR n'est pas un point d'arrivée, mais un point d'inflexion. Il inaugure une nouvelle ère où la frontière entre statique et dynamique devient floue, définie par le développeur au niveau du composant plutôt qu'au niveau de la page.
Plusieurs tendances se dessinent pour les mois et années à venir. L'edge computing va se généraliser, rapprochant le calcul dynamique des utilisateurs finaux. Les caches intelligents pourront invalider sélectivement des portions de pages plutôt que des pages entières. L'IA côté serveur permettra de pré-générer du contenu personnalisé en anticipant les besoins de chaque segment d'audience.
Du côté des frameworks, d'autres acteurs s'inspirent déjà de l'approche PPR. Astro avec ses « Server Islands », SvelteKit avec le streaming partiel, et Remix avec son loader architecture travaillent tous vers le même objectif : éliminer le compromis vitesse/personnalisation.
Pour les équipes techniques, l'implication est claire : investir dans l'architecture Server Components et Suspense est un pari sûr. Ces primitives sont la fondation sur laquelle se construisent toutes les innovations de rendu actuelles et futures. Les compétences acquises aujourd'hui seront directement transférables aux évolutions de demain.
Chez Veridian, nous avons déjà migré plusieurs projets clients vers le PPR avec des résultats mesurables : LCP divisé par 2, taux de rebond en baisse de 18 %, et scores Core Web Vitals systématiquement dans le vert. L'éco-conception bénéficie aussi de cette approche, car moins de calcul serveur signifie moins d'énergie consommée.