Next.js Rendering Strategies: Choose per Page

Next.js gives you several ways to turn data into web pages: build them in advance, rebuild them in the background on a timer, render them fresh on every request or render parts in the browser. Each choice affects speed, hosting cost, how current the content is and how search engines see it. Picking one approach for the whole site is the most common mistake; the right answer is usually different for the home page, the blog, a pricing page and a logged-in dashboard. This guide explains the main Next.js rendering strategies, how to choose between them page by page, and how to keep content fresh without giving up speed, with a worked rendering plan for a B2B website.

The main Next.js rendering strategies

StrategyWhen HTML is producedContent freshnessSpeedTypical usesStatic renderingAt build timeUntil the next buildFastest; served from a CDNMarketing pages, documentationIncremental static regenerationAt build time, then regenerated in the backgroundWithin a set interval, or on demandNear-staticBlogs, product catalogues, case studiesDynamic server renderingOn each requestAlways currentDepends on data sourcesPersonalised pages, search resultsClient-side renderingIn the browser after loadAlways currentSlower first view; fine afterInteractive dashboards behind loginStreamingServer sends parts of the page as they are readyMixedFast first contentPages combining fast and slow data

In the App Router, pages are rendered on the server by default, and Next.js decides between static and dynamic rendering based on what the page uses. Reading request-specific information such as cookies or headers makes a route dynamic. The documentation on server and client components explains where interactivity fits.

Static and incremental static regeneration

Static pages are the fastest and cheapest to serve, because they are plain files delivered from a content delivery network. Their weakness is freshness: content changes only when you rebuild.

Incremental static regeneration solves most of that. Pages are generated in advance, then regenerated in the background after a set interval or when you trigger it. Visitors always get a fast cached page, and content stays reasonably current. Next.js's ISR guide shows a page that sets a revalidation interval in seconds and pre-builds known paths with generateStaticParams. For content edited in a CMS, on-demand revalidation through functions such as revalidatePath or revalidateTag refreshes a page as soon as an editor publishes, rather than waiting for the timer.

Dynamic rendering and streaming

Dynamic rendering produces HTML on every request. Use it when the page depends on who is asking or on data that must be current to the second: account pages, search results, live availability. It costs more server time, and page speed depends on how quickly your data sources respond.

Streaming improves perceived speed on dynamic pages. The server sends the page shell and fast sections immediately, and slower sections arrive as they are ready, wrapped in loading states. A pricing page might show the plan descriptions at once and stream in a personalised quote calculation.

Choosing Next.js rendering strategies page by page

Ask three questions about each page or route:

1. Does the content differ per visitor? If yes, render dynamically or on the client.
2. How quickly must changes appear? Seconds suggests dynamic or on-demand revalidation; hours suggests ISR with a timer; only at release suggests static.
3. Does the page need to rank in search? If yes, make sure meaningful content is in the server-rendered HTML, not only loaded in the browser.

Caching behaviour has changed between Next.js versions, and recent versions introduce directives such as use cache. Check the caching documentation for your version rather than relying on older articles.

Worked example: a rendering plan for a B2B website

Suppose a software company is rebuilding its site in Next.js. It has marketing pages, a blog with about 300 articles edited in a headless CMS, a pricing page with region-specific prices, a customer story library, a documentation section and a logged-in customer dashboard. The team agrees a plan:

SectionStrategyRevalidationReasonHome and service pagesStaticRebuild on releaseChange rarely; must be fastestBlog articlesISROn demand when published, plus dailyEditors publish often; pages must rankBlog index and categoriesISREvery 10 minutesLists update as articles publishPricingDynamic, streamedNot cached per visitorPrices depend on visitor regionCustomer storiesISROn demandEdited occasionally in the CMSDocumentationStaticRebuild on docs releaseVersioned with the productCustomer dashboardServer-rendered shell with client componentsNot cachedPersonal data behind login

A blog article page following the pattern in the ISR guide looks like this. It is illustrative and untested; the CMS functions are placeholders.

export const revalidate = 86400; // regenerate at most once a day

export async function generateStaticParams() {
  const posts = await getAllPostSlugs();
  return posts.map((slug) => ({ slug }));
}

export default async function Post({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const post = await getPost(slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <PostBody content={post.body} />
    </article>
  );
}

A small webhook route, called by the CMS on publish, triggers on-demand revalidation for the article and the blog index, so changes appear within moments instead of waiting for the daily timer. PostBody stands for the component that renders your CMS's rich text; if your CMS returns raw HTML instead, sanitise it before rendering.

Measuring the result

After launch, compare Core Web Vitals per section, server costs per month and the time from publishing to the change appearing live. If dynamic sections are slow, look first at data sources and caching of upstream calls; if static sections are stale, check that revalidation triggers fire. Log every revalidation request with its result, so a broken CMS webhook is noticed within a day rather than when an editor complains.

Common mistakes

• Rendering every page dynamically because it is the default mental model
• Loading important content only in the browser, so search engines and slow devices see an empty page
• Using short timers everywhere when on-demand revalidation would be fresher and cheaper
• Forgetting that cookies or headers in a shared layout make every page beneath it dynamic
• Following caching advice written for an older Next.js version

The layout and styling side of a Next.js build is covered in our guide to mobile-first web design. If you are still deciding whether a custom build is worth it, our guide to custom website vs template compares the options.

Frequently Asked Questions

What are the main Next.js rendering strategies?

Static rendering, incremental static regeneration, dynamic server rendering, client-side rendering and streaming. Most sites use several, chosen page by page.

When should we use incremental static regeneration?

For content that changes regularly but not per visitor, such as blogs and catalogues. Combine a timer with on-demand revalidation when editors publish.

Is dynamic rendering bad for SEO?

No. Server-rendered dynamic pages deliver full HTML to search engines. The risk for SEO is content loaded only in the browser.

Why is my whole Next.js site rendering dynamically?

Often because a shared layout reads cookies, headers or other request data, which makes every route beneath it dynamic. Move that logic closer to where it is needed.

Plan your Next.js build with us

We design and build Next.js websites and apps with rendering strategies that balance speed, freshness and cost. See our custom app development services, or talk to us about your website.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.