Overview
- 1Next.js 15 (Oct 2024) is a major release that stabilises Turbopack and embraces React 19.
- 2Turbopack replaces Webpack as the default dev server — up to 76% faster HMR on large apps.
- 3fetch() requests are now uncached by default — opt-in caching is the new mental model.
- 4Partial Prerendering (PPR) ships stable in 15.2 — static shell + streaming dynamic slots.
- 5Params and searchParams are now async (Promises) to support streaming rendering.
Key Features in 15.3
Turbopack stable — Rust-based bundler, up to 76% faster HMR than Webpack
Partial Prerendering (PPR) — static HTML shell streams dynamic content into slots
React 19 integration — Server Actions, use(), useActionState all work natively
Async params/searchParams — page props are now Promises, enabling streaming
next/after() — runs code after response is sent (logging, analytics, cleanup)
connection() API — reads request headers/cookies in deeply nested Server Components
Caching overhaul — fetch uncached by default; explicit cache: "force-cache" opt-in
Use Cases
- →Production full-stack React applications
- →E-commerce and content-heavy sites needing SSG + ISR
- →SaaS dashboards mixing public (static) and private (dynamic) routes
- →APIs and backend routes co-located with the frontend
What's New in Next.js 15
- Turbopack is the default for `next dev` — no config change needed
- fetch() cache default changed from `force-cache` to `no-store`
- layout.tsx and page.tsx params are now `Promise<{ slug: string }>` — use await
- next/after(() => log()) schedules work after streaming response finishes
- Static Indicator in dev mode shows which routes are static vs dynamic
- Enhanced Forms with next/form — prefetches on hover, client-side navigation, pending state
- instrumentation.ts hooks: onRequestError, register for observability setup
App Router Architecture
- File-system routing: each folder = a route segment; page.tsx = the route UI
- layout.tsx wraps nested routes without remounting on navigation
- loading.tsx renders a Suspense fallback during page data fetching
- error.tsx is a React Error Boundary for the route segment
- Route Groups with (folder) — group routes without affecting the URL
- Parallel Routes (@slot) — render multiple pages in the same layout simultaneously
- Intercepting Routes — modal patterns using (.) and (..) conventions
Rendering Strategies
- Static: page has no dynamic functions or uncached fetches — pre-rendered at build
- Dynamic: page calls cookies(), headers(), or has uncached fetch — rendered per request
- Streaming: Suspense boundaries stream HTML progressively to the client
- PPR: export const experimental_ppr = true — static shell + Suspense-bounded dynamic parts
- ISR: fetch with next: { revalidate: 60 } — static with time-based background refresh
- On-demand revalidation: revalidatePath() and revalidateTag() invalidate cached data
Data Fetching & Server Actions
- Server Components fetch directly — `const data = await fetch(url)` inside async components
- Server Actions: `"use server"` async functions called from forms and Client Components
- useActionState(action, initialState) — manages action state in Client Components
- Data mutations: call revalidatePath() or redirect() inside Server Actions
- Route Handlers (app/api/route.ts) — GET, POST, PUT, DELETE handlers
- Middleware (middleware.ts) — runs before request routing for auth, redirects, rewrites
Frequently Asked Questions
What is Partial Prerendering in Next.js 15?
PPR combines static and dynamic rendering in a single route. Next.js pre-renders a static HTML shell instantly, then streams dynamic content into Suspense boundaries. Enable it per-page with `export const experimental_ppr = true`. It shipped stable in Next.js 15.2.
Why did Next.js change fetch() caching defaults?
In Next.js 14 and earlier, fetch() was cached by default (force-cache), which surprised developers when data appeared stale. Next.js 15 flips this: fetch() is uncached by default (no-store). Opt into caching explicitly with `cache: "force-cache"` or `next: { revalidate: n }`.
Pages Router vs App Router — which to use?
Use the App Router for all new projects. It supports React Server Components, streaming, nested layouts, and Server Actions. The Pages Router is still maintained and suitable for brownfield migrations, but the App Router is the strategic direction for Next.js.