Rendering strategy matches content type (static pages use SSG, dynamic use SSR/ISR)

A static marketing page with export const dynamic = 'force-dynamic' re-renders on every request — wasting server compute on content that hasn't changed, adding 100–500ms of server processing time compared to serving a cached HTML file, and forcing the CDN to bypass its edge cache entirely. Conversely, a personalized dashboard statically generated at build time serves stale data that doesn't reflect the current user's state. Mismatched rendering strategies cause either unnecessary cost (static content served dynamically) or incorrect behavior (dynamic content served statically). ISO 25010 performance-efficiency.time-behaviour requires that system response time reflect the minimum work necessary.

Audit every route's rendering directive and align it with whether the content is static or user-specific. In Next.js App Router, pages are static by default — only add force-dynamic or cache: 'no-store' when the page genuinely requires fresh data per request.

// app/page.tsx — marketing homepage: static by default, no config needed
export default function HomePage() {
  return <MarketingContent />
}

// app/dashboard/page.tsx — user-specific: needs dynamic
export const dynamic = 'force-dynamic'
export default async function Dashboard() {
  const user = await getAuthenticatedUser()
  return <DashboardView user={user} />
}

// app/blog/[slug]/page.tsx — blog post: ISR (cached, revalidated every 60s)
export const revalidate = 60
export default async function BlogPost({ params }) {
  const post = await fetchPost(params.slug)
  return <PostView post={post} />
}

For Pages Router, use getStaticProps for blog/marketing and getServerSideProps only for pages needing per-request user data.