Next.js Advanced Guide: App Router, Server Components, Caching, ISR, and Production Deployment

Master advanced Next.js: App Router architecture with layouts and templates, Server vs Client Components, data fetching with cache and revalidation, Server Actions for mutations, middleware patterns, route handlers and streaming, caching strategies, image and font optimization, internationalization, authentication with NextAuth.js, ISR and on-demand revalidation, parallel and intercepting routes, and production deployment with Docker and OpenTelemetry.

The Next.js App Router represents a fundamental shift in full-stack React development. It introduces React Server Components as the default rendering method, a nested layout system, Server Actions for data mutations, and a multi-layer caching architecture. This guide covers 13 advanced topics, each with production-ready code examples and best practices.

Whether you are migrating from the Pages Router or building a new project from scratch, understanding these concepts will help you fully leverage the App Router. From architecture design to deployment monitoring, let us dive into each topic.

All code examples in this guide are based on Next.js 14+ and React 18+. TypeScript is recommended for optimal type safety and developer experience. If you are still using the Pages Router, this guide includes a migration recommendations section at the end.

Each topic includes a practical code example, key concept explanations, and best practice tips. Reading in order is recommended to build a complete knowledge framework, but you can also jump directly to the sections most relevant to you.

1. App Router Architecture

The App Router builds routing based on file system conventions. Each folder represents a route segment, and special filenames define the UI behavior for that segment. Understanding these conventions is fundamental to using the App Router.

• layout.tsx — Persistent layout that does not re-render on child navigation, preserving scroll position and state
• template.tsx — Remounts on every navigation, ideal for enter/exit animations or per-page analytics tracking
• loading.tsx — Loading fallback component automatically wrapped in React Suspense
• error.tsx — Error boundary catching runtime errors in the segment and children, providing a retry button
• not-found.tsx — 404 page displayed when notFound() is called or the path does not match

// app/dashboard/layout.tsx — persistent layout
export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <section>
      <nav>Dashboard Sidebar</nav>
      <main>{children}</main>
    </section>
  );
}

// app/dashboard/loading.tsx — Suspense fallback
export default function Loading() {
  return <div>Loading dashboard data...</div>;
}

Layouts persist state across child routes and do not re-render. For example, a dashboard sidebar will not flash when switching pages. Templates create a new instance on each navigation — use templates instead of layouts when you need to trigger animations or reset form state on every page visit.

File Hierarchy and Rendering Order

When a request reaches a route segment, Next.js renders special files in this order: layout.tsx wraps template.tsx, template.tsx wraps error.tsx error boundary, error.tsx wraps loading.tsx Suspense fallback, and finally page.tsx contains the actual content. Understanding this nesting helps you place error handling and loading logic correctly.

Note that error.tsx cannot catch errors in the same-level layout.tsx because the error boundary is nested inside the layout. To catch root layout errors, use the global-error.tsx file. This file replaces the entire root layout, so it must include its own html and body tags.

Route groups (folder-name) let you create independent layouts for different parts of the app without affecting URLs. For example, (marketing)/layout.tsx and (app)/layout.tsx can have completely different navbars and footers, while the URL path will not contain marketing or app prefixes.

2. Server Components vs Client Components

In the App Router, all components are Server Components by default. They render on the server, can directly access databases and backend resources, and send zero JavaScript to the client. This is a key architectural decision for reducing bundle size.

Only components that need interactivity (useState, useEffect, event handlers) or browser APIs (window, localStorage) need the "use client" directive. The key principle is pushing Client Components to the leaves of your component tree.

// Server Component (default) — direct database access
async function ProductPage({ id }: { id: string }) {
  const product = await db.product.findUnique({ where: { id } });
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton productId={id} />
    </div>
  );
}

// Client Component — needs 'use client'
'use client';
function AddToCartButton({ productId }: { productId: string }) {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>Add ({count})</button>;
}

Server Components can render Client Components, but not vice versa. If you need server content inside a Client Component, pass it via children or props. This composition pattern, called the "donut pattern", is central to App Router performance optimization.

When to Use Which Component

• Use Server Components for: Data fetching, accessing backend resources, rendering static content, SEO-critical content, sensitive information (API keys)
• Use Client Components for: User interaction (clicks, inputs), useState/useEffect, browser APIs (geolocation, localStorage), third-party interactive libraries

A common mistake is marking an entire page as "use client". This causes that page and all its child components to be bundled into client JavaScript, losing the zero-JS advantage of Server Components. Always ask yourself: does this component really need to run on the client?

Third-party library choice matters too: many React libraries (like state management and animation libraries) depend on client APIs, so they must be used within Client Component boundaries. You can create thin Client Component wrappers to encapsulate these libraries while keeping the rest of the page as Server Components.

3. Data Fetching Patterns

The App Router uses an extended fetch API for data fetching. Use async/await directly in Server Components, with cache and revalidation options to control data freshness. React automatically memoizes and deduplicates requests to the same URL within the same render pass.

// Cached fetch with time-based revalidation
async function getProducts() {
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }, // revalidate every hour
  });
  return res.json();
}

// Parallel data fetching — avoid waterfalls
async function Dashboard() {
  const [users, revenue, orders] = await Promise.all([
    getUsers(),
    getRevenue(),
    getRecentOrders(),
  ]);
  return <DashboardView users={users} revenue={revenue} orders={orders} />;
}

Key options: cache: "no-store" for always-fresh dynamic data. next: { tags: ["products"] } to tag data for on-demand invalidation. next: { revalidate: 60 } for time-based automatic refresh. Avoid fetching data with useEffect in client components — fetch on the server whenever possible.

Using Promise.all to fetch independent data in parallel significantly reduces total load time. If some data is non-critical, combine with Suspense for streaming — let critical parts of the page render first while non-critical parts load asynchronously.

Data Fetching Best Practices

• Fetch data in Server Components; avoid the useEffect + fetch pattern in Client Components
• Use Promise.all to fetch independent data in parallel, reducing total latency
• Leverage Suspense boundaries for streaming — critical content shows first, non-critical loads async
• Set appropriate revalidate times or tags for fetch requests instead of always using no-store
• Wrap database queries with the React cache() function to ensure deduplication within the same render pass

For non-fetch data sources (such as direct database queries), use React cache() function for request memoization. For data requiring real-time client updates (like online status, collaborative editing), you still need WebSocket or polling in Client Components.

4. Server Actions

Server Actions are async functions that run on the server, marked with "use server". They can be called directly from Client Components, replacing traditional API routes for form submissions and data mutations. Their biggest advantage is progressive enhancement — HTML forms submit even before JavaScript loads.

// app/actions.ts
'use server';
import { revalidatePath } from 'next/cache';

export async function createTodo(formData: FormData) {
  const title = formData.get('title') as string;
  await db.todo.create({ data: { title } });
  revalidatePath('/todos');
}

// app/todos/page.tsx — works without JS!
import { createTodo } from '../actions';

export default function TodoPage() {
  return (
    <form action={createTodo}>
      <input name="title" required />
      <button type="submit">Add Todo</button>
    </form>
  );
}

The useOptimistic hook updates the UI immediately while waiting for the server response, providing instant feedback. useActionState provides a pending state for loading indicators and receives server-side validation errors. Server Actions are not limited to forms — they can be called from any client-side event.

Server Actions vs API Routes

Server Actions are ideal for form submissions, data mutations, and operations tightly coupled with the UI. API Routes (Route Handlers) are ideal for third-party webhooks, public API endpoints, file downloads/uploads, and SSE streams. General rule: if the operation is triggered by a user in the frontend, use Server Actions; if it needs to be called by external systems, use Route Handlers.

Another major advantage of Server Actions is type safety — you can directly import and call server functions from client code, and TypeScript automatically infers parameter and return types. This eliminates the boilerplate of manually defining API request and response types.

5. Middleware

Next.js Middleware runs at the edge, executing before a request reaches any route. It is ideal for authentication checks, geolocation-based redirects, header manipulation, A/B testing, and i18n locale detection. The middleware file must be at the project root (alongside the app directory).

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const token = request.cookies.get('session-token')?.value;
  const isProtected = request.nextUrl.pathname.startsWith('/dashboard');

  if (isProtected && !token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  const response = NextResponse.next();
  response.headers.set('x-request-id', crypto.randomUUID());
  return response;
}

export const config = {
  matcher: ['/dashboard/:path*', '/api/:path*'],
};

The matcher config precisely specifies routes for middleware. Avoid matcher: "/(.*)" which matches all routes — this would run middleware on static asset requests too. Keep middleware logic simple and fast; do not perform database queries or external API calls.

Common middleware use cases: checking JWT token validity, redirecting to locale versions based on the Accept-Language header, setting cookies and rewriting URLs for A/B tests, and adding security-related response headers (CSP, CORS).

6. Route Handlers (API Routes)

Route Handlers create RESTful API endpoints in the App Router. Use route.ts files to define GET, POST, PUT, DELETE and other HTTP methods. They use the Web standard Request/Response API, supporting streaming responses and Server-Sent Events.

// app/api/stream/route.ts — Server-Sent Events
export async function GET() {
  const encoder = new TextEncoder();
  const stream = new ReadableStream({
    async start(controller) {
      const events = ['Processing...', 'Analyzing...', 'Done!'];
      for (const event of events) {
        await new Promise(r => setTimeout(r, 1000));
        controller.enqueue(encoder.encode('data: ' + event + '\n\n'));
      }
      controller.close();
    },
  });
  return new Response(stream, {
    headers: { 'Content-Type': 'text/event-stream' },
  });
}

GET Route Handlers are statically cached by default when not using dynamic functions (cookies(), headers(), searchParams). Use export const dynamic = "force-dynamic" to disable caching. Note that route.ts cannot coexist with page.tsx in the same directory — they would conflict.

Route Handlers are ideal for third-party webhook endpoints, file upload handling, SSE streaming, and scenarios requiring custom response headers or status codes. For pure data mutations, prefer Server Actions over Route Handlers.

Advanced Route Handler Patterns

Route Handlers support all Web standard Response types. You can return JSON, plain text, binary streams, redirects, and custom status codes. For file download scenarios, set the Content-Disposition header and correct Content-Type. For CORS requests, return appropriate Access-Control headers in the OPTIONS method.

Use dynamic route segments (like app/api/users/[id]/route.ts) to create RESTful endpoints. Destructure the params argument to get dynamic values. Route Handlers can export GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS methods.

7. Caching Strategies

Caching in Next.js is central to performance optimization and also the most confusing part. The App Router introduces a four-layer caching system, with each layer addressing caching needs at different levels. Understanding the behavior, duration, and invalidation mechanism of each layer is crucial.

• Request Memoization — Identical fetch calls in the same render pass are deduplicated automatically; fetching the same data in multiple places in the component tree triggers only one request
• Data Cache — Persists fetch results across requests and deployments, controlled via revalidate time or tags for invalidation
• Full Route Cache — Caches rendered HTML and RSC Payload at build time for instant responses on static routes
• Router Cache — Client-side cache of prefetched route segments, enabling instant forward/back navigation

// Opting out of caching at each level

// No data cache — always fetch fresh data
const data = await fetch(url, { cache: 'no-store' });

// Time-based revalidation — refresh every 60s
const data = await fetch(url, { next: { revalidate: 60 } });

// Tag-based invalidation
const data = await fetch(url, { next: { tags: ['products'] } });
// Invalidate: revalidateTag('products');

// Route segment config — disable full route cache
export const dynamic = 'force-dynamic';
export const revalidate = 0;

In development, all caching layers are disabled by default for easier debugging. In production, use router.refresh() to manually refresh the client-side Router Cache. If your page data is always stale, first check whether the revalidate option is correctly configured.

Cache Debugging Tips

When caching behavior does not match expectations, debug by: adding custom headers to fetch requests to verify they are actually sent, checking route type markers (static/dynamic) in the Next.js build output, and using the build log to confirm which pages are statically generated.

A common point of confusion: even if you set revalidate: 60 on a fetch call, if the route generateStaticParams does not return the corresponding parameters, the page will still dynamically render on every request. Make sure your static generation parameters are correctly configured.

Pay attention to route markers in the Next.js build output: circle (○) indicates a static route, lambda (λ) indicates a dynamic route. If a route you expect to be static is marked as dynamic, check whether you are using dynamic APIs like cookies(), headers(), searchParams, or cache: "no-store" in that route.

8. Image & Font Optimization

next/image automatically optimizes images: converts to WebP/AVIF formats, generates responsive srcsets, lazy-loads by default, and prevents Cumulative Layout Shift (CLS) by requiring width/height. next/font self-hosts fonts, eliminating external requests and achieving zero layout shift through CSS size-adjust.

import Image from 'next/image';
import { Inter, Fira_Code } from 'next/font/google';

const inter = Inter({ subsets: ['latin'], display: 'swap' });
const firaCode = Fira_Code({
  subsets: ['latin'],
  weight: ['400', '700'],
});

export default function Page() {
  return (
    <div style={{ fontFamily: inter.style.fontFamily }}>
      <Image
        src="/hero.jpg" alt="Hero"
        width={1200} height={630}
        placeholder="blur"
        blurDataURL="data:image/jpeg;base64,/9j/4AAQ..."
        priority
      />
    </div>
  );
}

Use priority on above-the-fold images to improve LCP scores. Use the sizes prop to help browsers pick the correct responsive size. Remote images require allowed domains, protocols, and paths in images.remotePatterns in next.config.js. Generate blurDataURL using the plaiceholder library or the built-in blur feature for static imports.

Image Optimization Checklist

• Add priority={true} to above-the-fold images to trigger preloading
• Provide accurate sizes prop (e.g., "(max-width: 768px) 100vw, 50vw") to avoid downloading oversized images
• Use placeholder="blur" for blur-up placeholders to reduce visual jank
• Set aria-hidden or empty alt text for decorative images
• Consider using the quality prop (default 75) to balance between quality and file size

next/font eliminates runtime external font requests by downloading font files at build time and serving them as static assets. display: "swap" ensures text renders with fallback fonts before the custom font loads. Combined with the variable option, you can create CSS variables to reference fonts across different components.

9. Internationalization (i18n)

The App Router implements i18n through [lang] dynamic route segments and middleware locale detection. This approach requires no external i18n library — translations are managed via dictionary files and loaded through getDictionary(lang) in Server Components.

// middleware.ts — locale detection and redirect
import { match } from '@formatjs/intl-localematcher';
import Negotiator from 'negotiator';

const locales = ['en', 'zh', 'ja', 'de'];
const defaultLocale = 'en';

function getLocale(request: Request): string {
  const headers = {
    'accept-language': request.headers.get('accept-language') || ''
  };
  const languages = new Negotiator({ headers }).languages();
  return match(languages, locales, defaultLocale);
}

// app/[lang]/layout.tsx — generate all locale params
export async function generateStaticParams() {
  return [{ lang: 'en' }, { lang: 'zh' }, { lang: 'ja' }];
}

Use generateStaticParams to pre-render pages for each locale. If too many locales cause long build times, consider pre-rendering only the main locale and using ISR for the rest. Load translation dictionaries in Server Components to avoid bloating the client bundle.

Configure hreflang tags for different language versions to help search engines understand the language relationship between pages. Use the alternates.languages object in metadata to automatically generate these tags.

i18n Performance Optimization

When supporting many locale versions (e.g., 15+), pre-rendering all pages in all locales can cause long build times and excessive output size. The recommended strategy: only pre-render the default locale and the 2-3 highest-traffic locales, using ISR for the rest. This approach can reduce build time from tens of minutes to just a few minutes.

Keep translation dictionary files at a reasonable size. If translations exceed a few hundred KB, consider splitting dictionaries by page or feature module, loading only the relevant parts when needed. Loading dictionaries in Server Components does not add to the client bundle.

10. Authentication

NextAuth.js (Auth.js v5) integrates deeply with the App Router, providing OAuth, Credentials, and Magic Link authentication strategies. Session management supports JWT (stateless, ideal for edge runtimes) and database mode (ideal for server-controlled session management).

// auth.ts — NextAuth.js v5 configuration
import NextAuth from 'next-auth';
import GitHub from 'next-auth/providers/github';

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [GitHub],
  callbacks: {
    authorized({ auth, request: { nextUrl } }) {
      const isLoggedIn = !!auth?.user;
      const isProtected = nextUrl.pathname.startsWith('/dashboard');
      if (isProtected && !isLoggedIn) return false;
      return true;
    },
  },
});

// app/dashboard/page.tsx — protected page
import { auth } from '@/auth';
export default async function Dashboard() {
  const session = await auth();
  return <div>Welcome, {session?.user?.name}</div>;
}

auth() can be used in Server Components, Route Handlers, and Server Actions. The authorized callback combined with middleware protects entire route groups. For finer-grained control, call auth() in pages and conditionally render based on user roles.

For scenarios not using NextAuth, you can verify JWT tokens directly in middleware, or use lightweight libraries like iron-session for encrypted cookie sessions. The core concept remains the same: route-level protection in middleware, fine-grained permission checks in components.

Authentication Security Best Practices

• Store session tokens in HttpOnly + Secure + SameSite=Lax cookies to prevent XSS and CSRF attacks
• Only do quick token existence checks in middleware; put full token validation in Server Components or Route Handlers
• Protect Server Actions with CSRF tokens; NextAuth provides this by default
• Regularly rotate session secrets, manage keys through environment variables
• Implement rate limiting on sensitive operations to prevent brute-force attacks

In multi-tenant applications, ensure authentication middleware not only checks if the user is logged in but also verifies they have permission to access the requested resource. Place authorization logic in Server Components or Server Actions for fine-grained permission checks at the data level.

11. ISR & On-Demand Revalidation

ISR lets you update static pages without rebuilding the entire site. The App Router provides both time-based and on-demand revalidation. revalidatePath invalidates by path, revalidateTag invalidates by data tag — the latter is more flexible since one tag can be associated with multiple fetch calls across multiple pages.

// Time-based ISR — auto-revalidate every 60s
export const revalidate = 60;

async function BlogPost({ slug }: { slug: string }) {
  const post = await fetch('https://cms.example.com/posts/' + slug, {
    next: { tags: ['post-' + slug] },
  }).then(r => r.json());
  return <article>{post.title}</article>;
}

// On-demand revalidation via CMS webhook
// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache';

export async function POST(request: Request) {
  const { slug } = await request.json();
  revalidateTag('post-' + slug);
  return Response.json({ revalidated: true });
}

Typical flow: content editor publishes in CMS -> CMS webhook calls /api/revalidate -> revalidateTag marks related data as stale -> next request triggers regeneration. This is more efficient than time-based revalidation since it only refreshes when data actually changes.

ISR vs SSG Differences

Static Site Generation (SSG) generates all pages once at build time and never updates them. ISR adds background regeneration on top of this — when the revalidate time expires or on-demand revalidation triggers, Next.js generates a new version in the background while the old version continues serving requests. This stale-while-revalidate strategy ensures users never see a loading state.

For sites with massive content (like thousands of product pages on an e-commerce site), generating all pages at build time is impractical. Use dynamicParams: true (the default) to allow paths not listed in generateStaticParams to be generated on-demand upon first request and cached. Combined with revalidate configuration, this achieves a perfect ISR strategy.

If you need to return 404 when content is deleted instead of showing stale content, check whether data exists in the Server Component and call notFound() if it does not. This triggers the nearest not-found.tsx file to render.

12. Parallel & Intercepting Routes

Parallel routes use the @folder convention to render multiple pages simultaneously in the same layout. Each slot loads and errors independently, perfect for independent dashboard panels. Intercepting routes use the (.) convention to show a route in a different context — the most typical scenario is a modal in a photo gallery.

// Parallel routes — dashboard layout
// app/dashboard/layout.tsx
export default function Layout({
  children,
  analytics,
  team,
}: {
  children: React.ReactNode;
  analytics: React.ReactNode;
  team: React.ReactNode;
}) {
  return (
    <div>
      {children}
      {analytics}  {/* @analytics/page.tsx */}
      {team}       {/* @team/page.tsx */}
    </div>
  );
}

Interception level conventions: (.) matches same level, (..) one level up, (..)(..) two levels up, (...) matches root. Combining both creates a modal experience — soft navigation (Link click) shows a modal overlay, hard navigation (direct URL visit or refresh) shows the full page, and the URL remains shareable.

Provide a default.tsx file for each parallel route slot, defining what to render when the slot has no matching active route. This prevents Next.js from returning a 404 when no matching content is found during navigation.

Modal Route Pattern in Practice

Typical structure for a modal route: use an @modal parallel slot with intercepting routes. For example in a photo gallery, /photos/[id] is the full page, and (.)photos/[id] intercepts the route to display it in a modal. Users navigating via Link components see a modal overlay; visiting the URL directly or refreshing shows the full photo detail page. This provides optimal user experience and URL shareability.

Return null in the @modal default.tsx so nothing renders when no modal is active. When handling close logic inside the modal component, use router.back() to go back, maintaining correct browser history.

13. Deployment & Monitoring

Choosing a deployment approach depends on your needs: Vercel provides zero-config deployment, automatically handling edge functions, ISR, image optimization, and global CDN — the easiest choice. Self-hosting offers full control, suitable for teams with specific compliance requirements or existing infrastructure.

For self-hosting, use output: "standalone" to generate a minimal Node.js server including all runtime dependencies. Multi-stage Docker builds minimize image size — typically from 1GB+ down to 100-200MB. OpenTelemetry integration provides request-level tracing and performance monitoring.

# Multi-stage Dockerfile for Next.js
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]

Set output: "standalone" in next.config.js. Create a /api/health endpoint for Kubernetes or load balancers. Nginx reverse proxy handles SSL termination, gzip compression, and long-term caching of static assets. Use PM2 cluster mode to fully utilize multi-core CPUs.

Production Deployment Checklist

• Set output: "standalone" in next.config.js to generate a minimal standalone server
• Create a /api/health endpoint returning 200 for load balancers and Kubernetes probes
• Configure Nginx reverse proxy: SSL termination, gzip/brotli compression, long-term cache headers for _next/static paths
• Set NEXT_SHARP_PATH environment variable to ensure the sharp image library works in Docker
• Run with PM2 cluster mode to fully utilize the server multi-core CPU
• Initialize OpenTelemetry in instrumentation.ts to trace the full lifecycle of each request
• Configure environment variable management (never hardcode secrets in Docker images)
• Set up log aggregation (e.g., Datadog, Grafana Loki) to monitor error rates and response time distribution

For Kubernetes deployment, configure a readiness probe pointing to the health check endpoint, set reasonable CPU and memory limits, and use HPA (Horizontal Pod Autoscaler) for automatic scaling based on load. The Next.js standalone output memory footprint is typically 100-300MB, depending on application size.

Summary

The Next.js App Router represents the future of full-stack React development. Server Components reduce client burden, Server Actions simplify mutations, and four-layer caching provides fine-grained performance control. Middleware handles cross-cutting concerns at the edge, ISR enables on-demand incremental updates. Parallel and intercepting routes support complex UI patterns. Mastering these 13 topics enables you to build truly high-performance modern web applications.

Start small: use the App Router in new projects, gradually adopt Server Components and Server Actions, and introduce caching and ISR strategies as needed. As your understanding of each abstraction layer deepens, you will find that the App Router design decisions provide a solid foundation for building scalable applications.

Migration Recommendations

If you are migrating from the Pages Router, you do not need to rewrite the entire application at once. Next.js supports coexisting app and pages directories. The recommended strategy: start using the App Router for new pages, then gradually migrate existing ones. Replace getServerSideProps with async/await fetch in Server Components, replace getStaticProps with fetch and revalidate, and migrate API routes to Route Handlers.

During migration, note these key changes: useRouter moves from next/router to next/navigation, pathname is obtained via usePathname(), query params use useSearchParams(), and redirect changes from imperative to declarative (import redirect function from next/navigation). These API changes reflect the paradigm shift from client-side to server-first routing.

Performance Optimization Summary

• Default to Server Components and push Client Components to leaves to minimize JS bundle size
• Use Promise.all for parallel data fetching combined with Suspense for streaming
• Configure caching layers appropriately: choose suitable revalidate times or tags for different data sources
• Preload above-the-fold images with priority, auto-optimize all images with next/image
• Self-host fonts with next/font to eliminate external requests
• Only pre-render high-traffic locale versions; use ISR for the rest to shorten build time
• Use standalone output with multi-stage Docker builds to optimize deployment images
• Integrate OpenTelemetry tracing to identify production performance bottlenecks

Frequently Asked Questions

What is the difference between Server Components and Client Components?

Server Components render on the server, send zero JavaScript to the client, and can directly access backend resources. Client Components use "use client" and support interactivity like useState and event handlers. Default to Server Components; use Client Components only when you need interactivity or browser APIs.

How does caching work in the App Router?

Four layers: Request Memoization deduplicates fetch in the same render pass, Data Cache persists results across requests, Full Route Cache stores build-time HTML/RSC Payload, Router Cache stores prefetched segments on the client. Each is independently configured via cache, revalidate, and no-store.

What are Server Actions and how do they work?

Server Actions are async functions marked "use server" that run on the server. They can be called directly from form actions or client events, support progressive enhancement, useOptimistic for instant UI updates, useActionState for loading states, and cache invalidation via revalidatePath/revalidateTag.

How do I implement ISR in the App Router?

Time-based ISR uses fetch with next: { revalidate: 3600 } or route segment config export const revalidate = 3600. On-demand revalidation calls revalidatePath() or revalidateTag() in Server Actions or Route Handlers, typically triggered by CMS webhooks.

How do I set up authentication middleware?

Create middleware.ts at the project root, checking for session tokens or cookies in the request. Redirect unauthenticated users with NextResponse.redirect(). config.matcher precisely specifies route patterns to protect. Middleware runs at the edge, executing before any route renders.

What are parallel and intercepting routes?

Parallel routes (@folder) render multiple independent pages in the same layout, each with their own loading and error states. Intercepting routes ((.) convention) display routes in different contexts like modals. Combined, they create shareable URL modals with soft navigation showing a modal and hard navigation showing the full page.

How do I optimize images and fonts?

next/image handles WebP/AVIF conversion, responsive srcsets, lazy-loading, and layout shift prevention automatically. Add priority for above-the-fold images. next/font self-hosts fonts with zero layout shift and no external requests. Use sizes for responsive loading optimization and remotePatterns for remote image domains.

How should I deploy Next.js with Docker?

Multi-stage Dockerfile: deps stage installs dependencies, builder stage builds (output: "standalone"), runner stage copies only standalone output, public, and .next/static. Add health check endpoint, set NODE_ENV=production, use Nginx reverse proxy for SSL and compression, integrate @vercel/otel for OpenTelemetry tracing.