Next.js 15 Features That Actually Change How You Build: The Developer’s Guide

Framework version bumps usually mean a few new APIs and some deprecation warnings. Next.js 15 is different because several of its changes affect fundamental decisions: how you think about server vs. client boundaries, how you manage data freshness, and how you handle performance at scale. Getting these wrong creates bugs that only appear in production.

This guide focuses on the Next.js 15 features that require architecture decisions, not the QoL improvements you can adopt passively.

The features that require intentional decisions

1. Caching behaviour changes (the most impactful breaking change)

Next.js 15 changes the default caching behaviour for fetch requests: the default changed from force-cache to no-store. This means pages that previously cached data by default now fetch on every request unless you explicitly opt into caching.

What to do: audit every data fetch in your application and explicitly set cache behaviour. Don’t rely on the default. Pages serving permissioned content must be particularly careful — incorrect caching can serve stale data or, worse, expose one user’s data to another.

2. React 19 Compiler integration

Next.js 15 ships with React 19 support, including the React Compiler (formerly React Forget) which handles memoisation automatically. This reduces the need for manual useMemo and useCallback — but it also means you need to understand what the compiler is and isn’t doing if performance issues arise.

What to do: remove unnecessary manual memoisation if you adopt the compiler. Don’t mix the compiler with heavy manual memoisation without testing.

3. Async Request APIs

APIs that depend on request-time data (cookies(), headers(), params, searchParams) are now async in Next.js 15. This is a meaningful change to calling conventions.

What to do: Update all code that calls these APIs to await them. This is a mechanical change but easy to miss in a large codebase. Run the Next.js codemods before manually auditing.

4. next/after — executing code after response

A new API that lets you run logic (logging, analytics, cleanup) after the response has been sent. This matters for workflows where you need to perform side effects without blocking the user’s perceived response time.

What to do: Evaluate whether your current logging/analytics approach would benefit from non-blocking execution. Useful for audit logging in document-heavy workflows.

5. Turbopack as stable dev default

Turbopack is now stable and the default for next dev. Faster local iteration is the direct benefit. Check that any custom Webpack plugins or configurations have Turbopack equivalents before upgrading.

Upgrade strategy: don’t skip the codemods

Next.js provides automated codemods for the breaking API changes. Run them before any manual refactoring:

npx @next/codemod@latest upgrade latest

After running codemods:

1. Check the diff carefully — codemods are accurate but may miss edge cases
2. Run your full test suite
3. Audit explicit cache configurations on all data fetches
4. Test authentication flows and permissioned routes

What to test specifically after upgrading

• Caching: verify pages that should be dynamic (auth-gated, user-specific) are not being cached incorrectly
• Streaming: confirm streaming responses work as expected with React 19
• Middleware: Next.js middleware changes — review any middleware that inspects requests for auth or routing
• Image optimisation: test all <Image> components across breakpoints

The security angle

Next.js 15’s explicit caching defaults improve the security posture of applications serving permissioned content. Previous behaviour (defaulting to cache) created risk of serving cached responses from one user’s session to another in misconfigured deployments. Explicit opt-in to caching makes this mistake harder to make.

FAQ