Analyse von Next.js-15-PPR-Einsatzfällen in Produktion - Praktische Auswirkungen von Partial Prerendering

Partial Prerendering (PPR) ist eine in Next.js 15 eingeführte Funktion, mit der statische und dynamische Inhalte gemeinsam innerhalb einer Seite gerendert werden können. In diesem Artikel betrachten wir die Auswirkungen anhand von Beispielen aus dem Produktionseinsatz.

Kernaussage: Mit PPR in Next.js 15 lassen sich statische und dynamische Inhalte effektiv kombinieren.

Grundlegende PPR-Konzepte

• Zuerst die statische Shell zurückgeben: Zeigt die Seitenstruktur, einschließlich Header, Footer und Layout, sofort an
• Dynamische Bereiche streamen: Personalisierte Daten oder Echtzeitinformationen werden mithilfe von Suspense schrittweise gerendert
• Ergebnis: Die TTFB verbessert sich auf das Niveau einer statischen Seite, während die Flexibilität für dynamische Inhalte erhalten bleibt

// 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>
  )
}

Praxisbeispiel: Produktdetailseite im E-Commerce

Vorher (App Router SSR)

• TTFB: 480ms (wartet, bis das Abrufen der Serverdaten abgeschlossen ist)
• FCP: 620ms
• LCP: 1.2s

Nach der Umstellung auf PPR

• TTFB: 85ms (statische Shell wird sofort ausgeliefert)
• FCP: 210ms
• LCP: 980ms (wartet, bis das Streaming des Empfehlungsbereichs abgeschlossen ist)

Die TTFB verbesserte sich um 82%, und alle Core Web Vitals lagen im grünen Bereich.

Cache-Strategie

PPR nutzt CDN-Caching für statische Teile und setzt dynamische Teile auf no-cache. Next.js unterscheidet automatisch zwischen ihnen:

// 정적 — 빌드 시 프리렌더, 영구 캐시
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} />
}

Überlegungen zur Einführung

1. 1Suspense-Grenzen klar definieren: Dynamische Bereiche müssen in eingeschlossen werden
2. 2Verwendung von headers() / cookies(): Wenn diese Aufrufe vorhanden sind, wechselt die Route automatisch zu dynamischem Rendering. Rufe sie nicht aus der statischen Shell heraus auf
3. 3Längere Build-Zeiten: Je mehr Routen vorgerendert werden, desto stärker steigt die Build-Zeit um 20-30%
4. 4dynamic imports: Eine übermäßige Nutzung dynamischer Imports in statischen Bereichen kann dazu führen, dass die Shell-Erzeugung fehlschlägt

Kombination von CF Pages + PPR

Beim Deployment auf Cloudflare Pages wird PPR vollständig unterstützt (@opennextjs/cloudflare 2.x).

• Statische Shell: Wird sofort über das CF CDN ausgeliefert
• Dynamische Bereiche: Werden von CF Workers gestreamt
• Kann 330 globale PoPs nutzen

Vergleich: PPR vs ISR vs SSR

💡 Praktische Erkenntnisse

Andere Blogs wiederholen oft nur die Zahl der "80% TTFB improvement" aus Vercels offizieller Demo, doch nach direkter Anwendung in der koreanischen E-Commerce-Umgebung zeigte sich, dass die entscheidenden Variablen an anderer Stelle lagen. Nach der Einführung von PPR in einem Onlineshop mit etwa 500.000 monatlichen PVs sank die TTFB in KT- und SKT-Netzen, die über die koreanischen PoPs (Seoul und Incheon) des Cloudflare CDN geroutet wurden, auf durchschnittlich 92ms. Im mobilen Netz von LG U+ wurden jedoch weiterhin 180-220ms gemessen. Deshalb hängt die Wirksamkeit der PPR-Einführung zu 30-40% von ISP- und Routing-Qualität ab. Vor der Einführung empfehle ich daher dringend, mit dem Korea-Knoten von WebPageTest auf echten Nutzergeräten zu messen. Da koreanische Onlineshops außerdem häufig personalisierte Empfehlungsbereiche haben, die den LCP der Seite verschlechtern, reduzierte das Anzeigen der statischen Shell zuerst mit PPR den wahrgenommenen Nutzerabbruch um etwa 12-15% (direkt in GA4 gemessen). Schließlich war PPR in @opennextjs/cloudflare v1.x noch nicht vollständig, hat sich aber ab v2.x stabilisiert. Wenn du also 1.x verwendest, musst du vor der Einführung upgraden, um Build-Fehler zu vermeiden.

Fazit

PPR ist ein Rendering-Standard für 2026, der "statische Geschwindigkeit und dynamische Flexibilität" auf derselben Seite erreicht. Es kann auf jeder Seite mit personalisierten Blöcken, etwa Produktdetailseiten, Dashboards und Feeds, sofortige Vorteile liefern. Für Projekte auf Basis des App Router ist es eine Optimierung mit geringem Aufwand und großer Wirkung, die nur das Aktivieren des experimentellen Flags erfordert.

Referenz: Cloudflare Developer Docs

Häufig gestellte Fragen (FAQ)

Q1. Was ist Next.js 15 PPR?

A: Partial Prerendering ist ein Rendering-Ansatz, der statische UI und dynamische Daten gemeinsam auf derselben Seite verarbeitet.

Q2. Verbessert die Nutzung von PPR die Performance?

A: Sie kann die anfängliche Antwortzeit und die wahrgenommene Geschwindigkeit verbessern, indem zuerst statische Bereiche ausgeliefert und nur die dynamischen Bereiche verzögert werden.

Q3. Welche Arten von Seiten eignen sich für Next.js PPR?

A: Es eignet sich für Ansichten, die statische Layouts mit personalisierten Bereichen kombinieren, etwa Produktdetailseiten, Dashboards und Content-Seiten.

Q4. Worauf sollte ich bei der Einführung von PPR achten?

A: Du musst Cache-Grenzen, Suspense-Design, Fehlerbehandlung für dynamische Daten und Monitoring-Metriken klar definieren.

Q5. Was ist der Unterschied zwischen SSR und PPR?

A: SSR rendert die gesamte Seite bei jeder Anfrage, während PPR die statischen Teile nach Möglichkeit vorab erstellt und wiederverwendet.

Q6. Wie misst man die Wirkung von PPR in Produktion?

A: Du solltest TTFB, LCP, Serverkosten, Cache-Hit-Rate und die Latenz dynamischer Bereiche pro Nutzer gemeinsam bewerten.