Partial Prerendering (PPR) represents a significant evolution in Next.js rendering strategies, combining static and dynamic content within the same page. As of Next.js 15, PPR allows developers to define static shells with dynamic holes that stream in at runtime, offering an optimal balance between performance and interactivity.

PPR works by identifying which parts of a page can be statically generated at build time and which require runtime data. The framework generates a static HTML shell containing layout, navigation, and other unchanging elements, while marking dynamic sections with Suspense boundaries. When a request arrives, Next.js immediately serves the static shell and streams dynamic content as it resolves.

This approach differs fundamentally from traditional SSR or SSG. Rather than choosing between fully static or fully dynamic rendering for an entire route, PPR enables granular control at the component level. The static portions benefit from edge caching and instant delivery, while dynamic sections maintain real-time data without blocking the initial paint.

Next.js 15 requires explicit opt-in for PPR. The feature can be enabled at the application level through next.config.js:

The 'incremental' value allows selective adoption per route, while true would enable PPR across the entire application. For production deployments, incremental adoption provides safer rollout with the ability to test specific routes first.

Individual routes can opt into PPR by exporting a configuration constant:

Implementing Static Shells with Dynamic Sections

The core pattern involves wrapping dynamic components with React Suspense boundaries. Next.js analyzes these boundaries during build time to determine what should be prerendered versus what requires runtime execution.

Consider an e-commerce product page that displays static product information alongside dynamic inventory status and personalized recommendations:

The ProductDetails component renders statically because it depends only on the product data fetched during prerendering. The inventory and recommendations components stream in after the initial response, as they require real-time data or user-specific information.

PPR becomes particularly valuable when dealing with authenticated experiences. The static shell can include public navigation and layout, while user-specific content streams in based on session data:

This pattern ensures the page shell delivers instantly while personalized content populates progressively. The wrapper components handle authentication checks within Suspense boundaries, preventing the entire page from blocking on session validation.

PPR works best when data fetching aligns with rendering boundaries. Components should fetch their own data rather than passing props through multiple layers, enabling Next.js to accurately determine what can be prerendered.

Instead, colocate data fetching with consumption:

This approach gives Next.js clear signals about what depends on runtime data. The framework can prerender ParentComponent and StaticHeader while deferring OrdersList execution until request time.

PPR interacts with Next.js caching mechanisms to control how long static shells remain valid. The revalidate export defines the revalidation period for prerendered content:

The static shell (post content) regenerates hourly via ISR, while comments stream fresh on every request. This combination ensures blog posts load instantly with up-to-date engagement metrics.

Dynamic sections can implement their own caching strategies using fetch with cache options or React's cache function for deduplication across components.

PPR introduces complexity in reasoning about what renders when. Developers must understand Suspense boundaries and their impact on build output. Over-suspending creates many small chunks that increase overhead, while under-suspending forces more content into dynamic rendering.

The approach works best for pages with clear static/dynamic divisions. Highly interactive applications where most content depends on user state may not benefit significantly. Similarly, fully static marketing sites gain little from PPR since they lack dynamic sections.

Build times increase with PPR enabled, as Next.js must analyze component trees and generate static shells. For applications with thousands of routes, incremental adoption helps manage build performance.

Edge runtime compatibility requires careful attention. Components using Node.js-specific APIs must run in the Node.js runtime, limiting edge deployment benefits. The static shell can still be edge-cached, but dynamic sections execute closer to the origin.

PPR represents a sophisticated rendering model that requires understanding React Server Components, Suspense, and Next.js caching. Teams should validate that the performance gains justify the architectural complexity for their specific use case. When applied appropriately, PPR delivers exceptional user experiences by combining instant static shells with real-time dynamic content.

Partial Prerendering in Next.js 15: A Complete Guide

Parallel Routes in Next.js 15 provide a powerful pattern for rendering multiple pages simultaneously within the same layout, enabling sophisticated split-view interfaces and conditional rendering scenarios. This feature leverages the App Router's slot-based architecture to compose complex UIs without client-side state management overhead.

Understanding Parallel Routes Architecture

Parallel Routes use a special folder naming convention with the @ prefix to define named slots. Each slot acts as an independent route segment that can render different content simultaneously. The parent layout receives these slots as props, allowing precise control over their composition and positioning.

In this structure, @analytics and @team are parallel route slots. The parent layout.tsx receives them as props and can render them independently:

Each slot maintains its own loading and error states, providing granular control over the user experience. When navigation occurs, Next.js determines which slots need to update based on the route match, leaving others unchanged.

Consider a dashboard application that displays a main content area alongside real-time metrics and notifications. Parallel Routes enable this pattern without complex state synchronization.

Each slot can then implement its own data fetching and rendering logic:

This separation means the metrics panel can refresh independently without affecting the main content or notifications panel. Each slot's loading state renders separately, preventing the entire page from showing a loading spinner when only one section updates.

Handling Unmatched Routes with Default Fallbacks

Parallel Routes introduce a challenge: what happens when a slot doesn't have a matching route segment? Next.js solves this with default.tsx files that serve as fallback content.

Without a default file, Next.js returns a 404 for the unmatched slot, which often isn't the desired behavior. The default file ensures graceful degradation when navigating to routes that don't have corresponding slot content.

This becomes particularly important with nested routing. Consider a dashboard with different views:

When navigating to /dashboard/overview, the @metrics/overview/page.tsx renders. But navigating to /dashboard/settings (which doesn't have a metrics slot) will use @metrics/default.tsx instead of breaking the layout.

Conditional Rendering with Intercepting Routes

Parallel Routes combine powerfully with Intercepting Routes to create modal-like experiences. This pattern allows displaying content in a slot while maintaining the URL structure for deep linking.

The (.) prefix intercepts the route when navigating from within the dashboard. Clicking a settings link opens the modal overlay while updating the URL to /dashboard/settings. Refreshing the page or accessing the URL directly bypasses the interception and renders the full settings page.

Performance Considerations and Trade-offs

Parallel Routes introduce server-side complexity that requires careful consideration. Each slot performs independent data fetching, which can increase initial page load time if not optimized properly. The framework doesn't automatically deduplicate requests across slots, so multiple slots fetching similar data will make redundant network calls.

Streaming provides a solution for this. Each slot can stream its content independently, allowing the page to become interactive before all slots finish loading:

The main trade-off centers on complexity versus flexibility. Parallel Routes add architectural overhead that may not be justified for simpler layouts. Teams often find that client-side state management or simple component composition suffices for basic split views. The pattern shines when slots need independent routing, loading states, or error handling—scenarios common in complex dashboards, admin panels, or multi-pane applications.

Another consideration involves caching behavior. Each slot's cache strategy operates independently, which provides fine-grained control but requires explicit configuration to maintain consistency across related data. Developers need to coordinate revalidation strategies when slots display interdependent information.

The pattern works best for applications with clear separation of concerns where each view area has distinct data requirements and user interactions. E-commerce product pages with separate review and recommendation panels, analytics dashboards with multiple data sources, or project management tools with concurrent task and timeline views all benefit from this architecture.

How Tos

Partial Prerendering in Next.js 15: A Complete Guide

Parallel Routes in Next.js 15: Building Split View UIs