Server Rendering vs Client Rendering vs Static: The 2026 Map

What you need to know

• Static generation produces the best raw performance metrics and is appropriate for content that does not change per-user or per-request.
• Server-side rendering serves fresh data for each request and is appropriate for user-specific content, real-time data, and SEO-critical pages with dynamic content.
• Client-side rendering is appropriate for pages behind authentication where interactivity is the priority and initial load performance is secondary.
• ISR bridges static generation and server rendering by pre-rendering with background revalidation. Use it for content that changes regularly but not in real time.
• Modern Next.js App Router defaults to server rendering and allows granular control per component or route segment.

The core argument

The rendering strategy question used to be simpler: SPA or server-rendered? The modern answer is "it depends per page, and possibly per component." Next.js and similar frameworks have made it practical to use different strategies for different parts of the same application, which is the right architecture for most products but requires a clearer mental model to implement correctly.

The performance case for SSG and ISR is straightforward: a file served from a CDN is faster than any dynamic rendering, regardless of server performance. The performance case for SSR over CSR is less obvious but meaningful: SSR delivers rendered HTML to the browser, which can display it before JavaScript executes; CSR delivers a blank page and requires JavaScript to run before the user sees anything. On a fast device and connection, the difference is negligible. On a slow mobile connection, the LCP difference between SSR and CSR on a marketing page can be 2 to 4 seconds, which is the difference between a good and bad Core Web Vitals score.

The principle that guides the decision in practice: pages that need SEO, are public-facing, and have content determinable at request time should be server-rendered or statically generated. Pages that are behind authentication and are dashboards or tools where interactivity is primary can use client-side rendering without any performance penalty, because SEO is irrelevant behind a login wall and the user is already engaged when they reach those pages.

Common mistakes

1. Using client-side rendering for marketing pages and SEO-critical content. A React SPA where the homepage, about page, and blog are all client-rendered has poor SEO (search engines see empty divs before JavaScript runs) and poor initial load performance. Marketing and content pages that need to rank in search results must have their content in the initial HTML response. Use SSG or SSR for these pages.

1. Over-using server-side rendering for pages that are identical for all users. A blog post that is the same for every reader does not need to be generated fresh on every request. Generating it at build time (SSG) and serving it from a CDN is faster and cheaper. Reserve SSR for pages where the content actually varies by request or user.

1. Not configuring ISR revalidation windows appropriately. A high-traffic landing page with ISR set to revalidate every 5 seconds will trigger a background regeneration for every 5-second window with traffic, which can exceed the expected cost of the static approach. Set revalidation windows based on how frequently the content actually changes, not based on wanting it to "feel fresh."

1. Blocking the initial render with large client-side JavaScript bundles. Even on server-rendered pages, large client-side JavaScript bundles delay Time to Interactive. Use dynamic imports to code-split heavy components, defer non-critical scripts, and audit the bundle size regularly with tools like @next/bundle-analyzer. A fast TTFB from SSR is undermined by a 2 MB JavaScript bundle that blocks interactivity.

1. Not testing Core Web Vitals in field conditions. Lighthouse scores in development are not representative of production performance on real user devices. Monitor Core Web Vitals using real user monitoring (Google Search Console, Vercel Speed Insights) to understand actual LCP, FID/INP, and CLS scores across device types. Field data reveals problems that lab testing misses.

Where to start

1. Categorize every page in the application by rendering requirement. For each page: is it behind authentication? Is it user-specific? Does it need SEO? Does it change frequently? The answers determine the appropriate rendering strategy. This audit takes one hour and produces a clear roadmap for rendering strategy changes.

1. Move all public marketing and content pages to SSG if they are currently SSR or CSR. Run next build with the default SSG output for static pages and verify that the content builds correctly. Check the generated HTML to confirm that the critical SEO content is present. Deploy to a CDN and measure the TTFB improvement compared to the server-rendered version.

1. Measure LCP and INP in production using real user monitoring. Install Vercel Speed Insights or the Web Vitals library to measure Core Web Vitals from real user sessions. Set up alerts for pages where LCP exceeds 2.5 seconds. The real user data identifies the pages where rendering strategy or bundle size improvements will have the most impact.

Related reading

• Server Components in Practice: A Founder Engineer Story
• Real User Monitoring vs Synthetic Monitoring: Both, Not Either
• Responsive Design vs Adaptive Design vs Mobile First
• Server Actions, Edge Functions, and the Modern Backend Surface