Next.js 15 App Router — Complete Production Guide for 2026

Next.js 15 is the current production standard for React-based web applications in 2026. Released in late 2025, it introduces several meaningful changes that affect how applications are built, cached, and deployed — including breaking changes that require attention during migration from Next.js 14. For development teams building or maintaining Next.js applications, understanding these changes is essential for production success.

At PapaSiddhi Technologies, our full-stack development team has built several production applications on Next.js 15 since its release. This guide distils what we have learned about its new features, breaking changes, performance characteristics, and deployment considerations.

Next.js 15 Overview: What Changed

Next.js 15 focuses on three themes: improved performance through Partial Prerendering, developer experience improvements through Turbopack and better error messaging, and tightening of the behaviour model by making caching explicit rather than implicit.

For teams migrating from Next.js 14, there are two critical breaking changes that require code updates: async dynamic route params and the caching default change for fetch requests. Both are straightforward to address, but they affect a significant portion of Next.js application code and must be handled before deployment.

For teams starting new projects, Next.js 15 is the clean choice. The App Router is now the mature and recommended approach, the Server Components model is well-established, and Partial Prerendering offers a compelling performance architecture that was not available in earlier versions.

App Router: The Standard in 2026

The Next.js App Router — introduced in Next.js 13 and iterated through 14 — is fully mature in Next.js 15 and is the only recommended routing approach for new projects. The Pages Router is still supported for backward compatibility, but receives no new features and will be deprecated in a future major version.

The App Router architecture in Next.js 15 provides: Server Components by default (components that render on the server with zero client-side JavaScript), Client Components marked explicitly with use client, nested layouts with shared UI that persists across navigation, route-level loading and error states via loading.tsx and error.tsx, and Parallel Routes and Intercepting Routes for advanced UI patterns.

For teams still on the Pages Router, Next.js 15 is a good time to plan the migration. The App Router provides significantly better performance characteristics through Server Components, better code organisation through collocated layouts, and access to features like Partial Prerendering that are App Router-only.

Partial Prerendering: The Killer Feature

Partial Prerendering (PPR) is the headline feature of Next.js 15. It stabilises an approach that combines static and dynamic rendering within a single route in a way that was previously impossible.

Without PPR, a Next.js route is either fully static (rendered at build time and served from CDN edge) or fully dynamic (rendered on each request). A page that has both a static marketing header and a dynamic user-specific content section must be fully dynamic — penalising performance for the sake of one dynamic component.

With PPR, the static shell of the page (the header, navigation, footer, and any non-personalised content) is pre-rendered at build time and served instantly from the CDN edge. The dynamic sections are streamed in after the initial shell loads using React Suspense. The user sees content immediately, and the dynamic sections fill in as they resolve.

This makes PPR the most impactful architectural addition to Next.js since the introduction of Server Components. For content-heavy applications with some personalisation — e-commerce sites, dashboards, marketing sites with dynamic components — PPR delivers meaningfully better Core Web Vitals without requiring separate rendering strategies for different page types.

Enable PPR for a route by adding experimental.ppr = true in next.config.js and wrapping dynamic sections in Suspense boundaries with fallback UI.

Turbopack for Development

Turbopack, the Rust-based JavaScript bundler written by Vercel, reaches stable status for development builds in Next.js 15. Using Turbopack for local development (next dev --turbopack) delivers:

Significantly faster initial development server startup — typically 10-30 seconds faster than Webpack for medium to large applications. Faster Hot Module Replacement (HMR) on file changes — Turbopack's incremental build model means it only recompiles what changed, not the whole application. Better memory efficiency for large applications.

The benchmark chart above shows the improvement across Next.js versions for key metrics including build time, Time to First Byte, Largest Contentful Paint, and First Load JavaScript bundle size. Next.js 15 shows meaningful improvements across all four compared to both Next.js 13 and Next.js 14.

For production builds, next build still uses Webpack in Next.js 15. Turbopack production support is in development and expected in a future version. This means you get faster development iteration with Turbopack while production builds use the proven Webpack pipeline.

Async Params: The Critical Breaking Change

The most impactful breaking change in Next.js 15 is the shift to async dynamic route params. In Next.js 14 and earlier, route params were synchronously accessible as plain objects. In Next.js 15, they are Promises.

Before Next.js 15:
A page component receiving params typed as { slug: string } accessed slug directly as params.slug. This worked synchronously.

After Next.js 15:
The params type changes to Promise<{ slug: string }>. The component must be async, and params must be awaited before accessing slug. The same change applies to searchParams and to generateMetadata functions.

This change affects every dynamic route page component and every generateMetadata function that uses params or searchParams. When migrating from Next.js 14, run a codebase search for params. and searchParams. to identify all affected files. The Next.js 15 migration guide includes a codemod (npx @next/codemod@canary upgrade latest) that can automate many of these updates.

Our development team at PapaSiddhi has applied this migration pattern across multiple codebases. The change is systematic and codemods handle most cases, but complex custom param handling and unusual type patterns may require manual review.

Caching Changes: No-Store by Default

The second major breaking change in Next.js 15 is the caching default for fetch requests. In Next.js 14, fetch inside Server Components defaulted to force-cache — meaning all fetch calls were cached unless explicitly opted out. This caused unexpected stale data in many applications.

In Next.js 15, the default changes to no-store — meaning fetch calls are not cached unless explicitly opted in. This is a more correct default that prevents unexpected caching issues, but it means applications migrating from Next.js 14 that relied on implicit caching need to add explicit cache directives.

To cache data in Next.js 15: add { cache: 'force-cache' } for indefinitely cached data, add { next: { revalidate: 60 } } for ISR-style revalidation, or use { next: { tags: ['my-tag'] } } with revalidateTag() for on-demand revalidation. Both the fetch-based approach and the route-level export const revalidate = 60 pattern continue to work in Next.js 15.

Performance Benchmarks: Next.js 13 vs 14 vs 15

The performance improvements across Next.js versions are meaningful for production applications.

Build time shows the clearest improvement: from 45 seconds on Next.js 13 to 32 seconds on Next.js 14 to 22 seconds on Next.js 15 for a representative medium-sized application. This 51% improvement from 13 to 15 translates to faster CI/CD pipelines and faster deployment cycles.

Time to First Byte (TTFB) improves from 180ms on Next.js 13 to 140ms on Next.js 14 to approximately 95ms on Next.js 15 (with Partial Prerendering enabled for static shells). Largest Contentful Paint improves from 2,400ms to 1,900ms to 1,400ms across the same progression.

First Load JavaScript bundle size decreases from 145KB on Next.js 13 to 128KB on Next.js 14 to 108KB on Next.js 15 — a 26% reduction over two major versions, improving initial page load performance on mobile and slower connections.

Deployment and Production Considerations

Next.js 15 deployments follow the same patterns as earlier versions, with some additional considerations for Partial Prerendering.

Vercel deployment remains the lowest-friction option. Vercel automatically detects the Next.js version, configures edge caching appropriately for PPR, and handles ISR revalidation. For teams deploying to Vercel, upgrading to Next.js 15 requires only a package update.

Self-hosted deployments on AWS, GCP, or Azure require Node.js 18+ (Node.js 22 LTS recommended). The standard next start server works for most deployments. For PPR to fully benefit from edge caching in self-hosted deployments, a CDN layer configured to cache the static shells and stream dynamic portions is required.

Docker deployments should use multi-stage builds with the Next.js standalone output mode (output: 'standalone' in next.config.js) for minimal image sizes. This pattern works identically in Next.js 15.

Our web development team at PapaSiddhi Technologies builds and maintains Next.js 15 applications for clients across the UK, Netherlands, and USA. If you are migrating from an earlier Next.js version or building a new application, contact us to discuss your requirements and timeline.