Next.js App Router: Performance Patterns We Use on Every Project

The single biggest performance win in Next.js App Router is the default: server components. Every component that doesn't need interactivity should stay on the server. This means zero JavaScript shipped for layout, navigation, data display, and static content.

The mistake we see most often: wrapping entire page sections in 'use client' because one child needs a click handler. Instead, push client boundaries to the smallest possible component.

Streaming lets you show UI progressively as data loads. The key insight: place Suspense boundaries around slow data fetches, not around everything.

Our pattern: the page shell (navigation, layout, headings) renders instantly. Each data-dependent section wraps in its own Suspense with a skeleton loader. Users see a complete page structure immediately, with content filling in as APIs respond.

Parallel routes (@slot convention) let you render multiple page sections independently. We use them for dashboard layouts where sidebar, main content, and modals all have their own loading states and error boundaries.

The benefit: if one section fails, others still render. And each section can stream independently, so the fastest data shows first.

Next.js caching is powerful but confusing. Our simplified mental model:

• Static data (rarely changes) → force-cache with revalidation intervals
• User-specific data → no-store, always fresh
• Semi-dynamic data (changes hourly) → revalidate: 3600

Don't fight the cache — understand it and set explicit strategies for each data source.