Analyse de cas d'adoption en production de Next.js 15 PPR - Effets pratiques du pré-rendu partiel

Partial Prerendering (PPR) est une fonctionnalité introduite dans Next.js 15 qui permet de rendre ensemble du contenu statique et dynamique au sein d'une même page. Dans cet article, nous examinerons son impact à travers des exemples d'adoption en production.

Réponse clé : PPR dans Next.js 15 permet de combiner efficacement contenu statique et contenu dynamique.

Concepts de base de PPR

• Renvoyer d'abord la structure statique : affiche immédiatement la structure de la page, y compris l'en-tête, le pied de page et la mise en page
• Diffuser les zones dynamiques en streaming : les données personnalisées ou les informations en temps réel sont rendues progressivement avec Suspense
• Résultat : le TTFB atteint le niveau d'une page statique tout en conservant la flexibilité du contenu dynamique

// app/products/[id]/page.tsx
export const experimental_ppr = true

export default function Page({ params }) {
  return (
    <main>
      <StaticHeader />
      <Suspense fallback={<Skeleton />}>
        <DynamicRecommendations userId={params.id} />
      </Suspense>
      <StaticFooter />
    </main>
  )
}

Exemple concret : page de détail produit e-commerce

Avant (App Router SSR)

• TTFB : 480 ms (attend la fin de la récupération des données côté serveur)
• FCP : 620 ms
• LCP : 1,2 s

Après le passage à PPR

• TTFB : 85 ms (structure statique servie immédiatement)
• FCP : 210 ms
• LCP : 980 ms (attend la fin du streaming de la zone de recommandations)

Le TTFB s'est amélioré de 82 %, et tous les Core Web Vitals sont passés dans la zone verte.

Stratégie de cache

PPR utilise la mise en cache CDN pour les parties statiques et configure les parties dynamiques en no-cache. Next.js les distingue automatiquement :

// 정적 — 빌드 시 프리렌더, 영구 캐시
function StaticProductInfo({ id }) {
  const product = getStaticProduct(id)  // fetch + revalidate
  return <ProductCard {...product} />
}

// 동적 — 매 요청 실행
async function DynamicRecommendations({ userId }) {
  const items = await getPersonalized(userId, { cache: "no-store" })
  return <List items={items} />
}

Points à considérer avant l'adoption

1. 1Définir clairement les limites Suspense : les zones dynamiques doivent être enveloppées dans
2. 2Utilisation de headers() / cookies() : si ces appels sont présents, la route bascule automatiquement vers un rendu dynamique. Ne les appelez pas depuis la structure statique
3. 3Temps de build plus longs : à mesure que davantage de routes sont pré-rendues, le temps de build augmente de 20 à 30 %
4. 4dynamic imports : un usage excessif des imports dynamiques dans les zones statiques peut faire échouer la génération de la structure

Combiner CF Pages + PPR

Lors d'un déploiement sur Cloudflare Pages, PPR est entièrement pris en charge (@opennextjs/cloudflare 2.x).

• Structure statique : servie immédiatement depuis le CDN CF
• Zones dynamiques : diffusées en streaming depuis CF Workers
• Possibilité de tirer parti de 330 PoP mondiaux

Comparaison : PPR vs ISR vs SSR

💡 Enseignements pratiques

D'autres blogs se contentent souvent de répéter le chiffre de "80 % d'amélioration du TTFB" issu de la démo officielle de Vercel, mais après l'avoir appliqué directement dans l'environnement e-commerce coréen, j'ai constaté que les variables décisives se trouvaient ailleurs. Après avoir appliqué PPR à une boutique en ligne avec environ 500 000 PV mensuelles, le TTFB est tombé à une moyenne de 92 ms sur les réseaux KT et SKT acheminés via les PoP coréens du CDN Cloudflare (Séoul et Incheon), mais il restait mesuré à 180-220 ms sur le réseau mobile LG U+. Pour cette raison, l'efficacité de l'adoption de PPR dépend à 30-40 % de la qualité de l'ISP et du routage ; avant l'adoption, je recommande donc vivement de la mesurer sur de vrais appareils utilisateurs avec le noeud WebPageTest Korea. En outre, comme les boutiques en ligne coréennes comportent souvent des zones de recommandations personnalisées qui dégradent le LCP de la page, l'affichage initial de la structure statique avec PPR a réduit la perte perçue d'utilisateurs d'environ 12 à 15 % (mesuré directement dans GA4). Enfin, PPR n'était pas complet dans @opennextjs/cloudflare v1.x, mais il s'est stabilisé en v2.x et versions ultérieures ; si vous utilisez la version 1.x, vous devez donc effectuer une mise à niveau avant l'adoption afin d'éviter les échecs de build.

Conclusion

PPR est un standard de rendu 2026 qui permet d'obtenir "la vitesse du statique et la flexibilité du dynamique" sur une même page. Il peut apporter des bénéfices immédiats à toute page comprenant des blocs personnalisés, comme les pages de détail produit, les dashboards et les fils d'actualité. Pour les projets basés sur App Router, c'est une optimisation peu coûteuse et à fort impact qui ne nécessite que l'activation du flag expérimental.

Référence : Cloudflare Developer Docs

Foire aux questions (FAQ)

Q1. Qu'est-ce que Next.js 15 PPR ?

R : Partial Prerendering est une approche de rendu qui gère ensemble l'interface statique et les données dynamiques sur une même page.

Q2. L'utilisation de PPR améliore-t-elle les performances ?

R : Elle peut améliorer le temps de réponse initial et la vitesse perçue en servant d'abord les zones statiques et en différant uniquement les zones dynamiques.

Q3. Quels types de pages conviennent à Next.js PPR ?

R : Elle convient aux écrans qui combinent des mises en page statiques avec des zones personnalisées, comme les pages de détail produit, les dashboards et les pages de contenu.

Q4. À quoi faut-il faire attention lors de l'adoption de PPR ?

R : Vous devez définir clairement les limites de cache, la conception Suspense, la gestion des échecs de données dynamiques et les métriques de monitoring.

Q5. Quelle est la différence entre SSR et PPR ?

R : SSR rend toute la page à chaque requête, tandis que PPR préconstruit et réutilise les parties statiques chaque fois que possible.

Q6. Comment mesurer l'impact de PPR en production ?

R : Vous devez évaluer conjointement le TTFB, le LCP, les coûts serveur, le taux de cache hit et la latence des zones dynamiques par utilisateur.