Rendering Strategies (App Router)

Priority: P0 (CRITICAL)

Choose rendering strategy based on data freshness and scaling needs. See Strategy Matrix.

Implementation Guidelines

• SSG (Static Site Generation): Default for App Router. Use

  generateStaticParams

  to pre-render routes at build time. Triggered by

  fetch

  with

  cache: 'force-cache'

  .
• SSR (Server-Side Rendering): Triggered by

  cookies()

  ,

  headers()

  , or

  fetch

  with

  cache: 'no-store'

  . Use for personalized or high-freshness data.
• ISR (Incremental Static Regeneration): Update static content after build. Use

  revalidate

  (time-based) or

  revalidatePath

  /

  revalidateTag

  (on-demand).
• Streaming: Use

  Suspense

  to wrap slow async components and prevent them from blocking the initial page load. Use

  loading.tsx

  for route-level skeletons.
• PPR (Partial Prerendering): Combine static shell with dynamic regions in a single HTTP request. Enable

  ppr: true

  in

  next.config.js

  .
• Strategies: Choose rendering based on SEO (SSG/ISR) vs Interactivity (Client) vs Personalization (SSR). Utilize

  dynamicParams

  to control fallback behavior for uncached routes.
• Hydration: Avoid Hydration Errors by not using browser-only values (

  window.innerWidth

  ,

  Date.now()

  ) in the initial render. Use the

  mounted

  useEffect pattern.
• Edge Runtime: Use

  runtime: 'edge'

  for low-latency globally distributed execution where full Node.js APIs are not required.

Anti-Patterns

• No root awaits in

  page.tsx

  : Wrap slow components in

  <Suspense>

  to stream.
• No SSR for static content: Use SSG or ISR; reserve SSR for truly dynamic data.
• No

  typeof window

  in initial render: Use

  useEffect

  to avoid hydration errors.

References

• Strategy Selection Matrix
• Implementation Details
• Scaling Patterns