next-data-rendering

Next.js rendering strategies include SSG (Static Site Generation) for pre-built pages, SSR (Server-Side Rendering) for dynamic content per request, ISR (Incremental Static Regeneration) for updated static pages on a schedule, and CSR (Client-Side Rendering) for interactive components. Choose SSG for content that changes infrequently, SSR for user-specific data, ISR for content needing periodic updates, and CSR for highly interactive features.

Configure revalidation using the `revalidate` option in getStaticProps for ISR, set cache headers via response objects in route handlers, and leverage Next.js's multi-layer caching: data caching for fetch results, route caching for rendered pages, and router caching for navigation. Combine these to reduce rebuild time and server load.

Yes. Partial prerendering generates static shells while streaming dynamic content on demand, reducing initial load time. Use Suspense boundaries to mark streaming regions and combine with ISR revalidation strategies to balance performance and freshness across mixed static and dynamic sections.

Use Next.js fetch caching by default, specify `cache: 'no-store'` to disable caching for dynamic data, and set `revalidate` tags for fine-grained invalidation. Combine data layer caching with route caching to reduce redundant requests and improve SSR performance.

SSG and SSR are SEO-friendly because content renders server-side before delivery, enabling search engine crawling. Use SSG for static pages and SSR for dynamic content requiring fresh data. Avoid pure CSR for SEO-critical pages; if needed, combine with dynamic sitemap generation and meta tags.

Avoid static generation for pages with frequently changing data, user-specific content, or real-time information. Switch to SSR when content depends on request headers, query parameters, or database values that vary per visitor, and ISR cannot meet freshness requirements.