Overview

While working on a project that integrates Next.js with a headless CMS (microCMS), I noticed that some pages were rendered using Static Site Generation (SSG), while others were unexpectedly falling back to Server-Side Rendering (SSR).

At first, I tried applying Incremental Static Regeneration (ISR) using export const revalidate = 60, expecting the page to be statically regenerated at regular intervals. However, the caching behavior didn’t work as expected on certain pages.

Digging deeper, I realized that how params and searchParams are used in a page has a direct impact on how Next.js infers the rendering strategy for that route.

This discovery prompted me to take a step back and thoroughly investigate how Next.js determines whether a page should be rendered via SSG, SSR, or ISR—and what conditions must be met for each strategy to work correctly.

What I Learned

Rendering Inference in Next.js (App Router)

• In Next.js (App Router), using searchParams in a server component automatically makes the route dynamic, effectively disabling revalidate.
• Similarly, if you use params (for dynamic routing like /news/[id]) without defining generateStaticParams(), the route will be treated as SSR (Server-Side Rendered) by default.
• revalidate only works for statically generated pages, so it has no effect on dynamic routes unless generateStaticParams is used.
• Pages that are SSR by default (because of params or searchParams) can still be converted to SSG or ISR. However, doing so requires that all paths are known ahead of time and statically defined, which introduces maintenance costs—especially after handoff to non-engineers.
• Therefore, unless there’s a strong reason to reduce API/server load, it’s often better to leave those pages as SSR for flexibility and easier long-term maintenance.

ISR vs Webhook: Choosing the Right Strategy for Content Updates

• The revalidate setting only works in page.tsx or layout.tsx. Adding it inside components has no effect.
• If any part of the page tree contains 'use client', the component becomes a client component and revalidate is ignored.
  However, since revalidate can only be applied at the page.tsx or layout.tsx level—and these files are typically expected to remain as server components in line with Next.js’s core design philosophy—this usually isn't an issue.
  In most cases, if client-side logic is needed, it’s implemented in separate components, keeping the page or layout itself server-rendered and compatible with ISR.
• When using a CMS like microCMS, you have two ways to ensure content updates reflect on the site:
  • Use ISR: stale content is served initially, then updated in the background.
  • Use a webhook to trigger a full rebuild when content changes.
• In practice, you often choose between ISR and webhook as mutually exclusive strategies.
• ISR is ideal when:
  • You have frequent updates (e.g., many posts per day)
  • The site has consistent traffic (so cache can be refreshed regularly)
  • Slight delay in content updates are acceptable (e.g., blog posts, reviews)
• Webhooks are better when:
  • The site has low traffic
  • Content updates are infrequent
  • You want guaranteed, immediate reflection of CMS updates
  • You aim to minimize API calls or rendering costs in production