Why Rendering Strategy Matters for Web Applications
The web application rendering model — where computation happens to produce the HTML that the browser displays — has evolved significantly over the past decade and the choices available to developers have proliferated in ways that make understanding each model’s trade-offs more important than ever. The single-page application (SPA) model that dominated the 2010s put all rendering on the client: the server delivered a mostly empty HTML file with JavaScript, the JavaScript loaded in the browser and fetched data from APIs, and the browser rendered the UI from the fetched data. This model is simple from a server perspective and enables rich interactive experiences, but it has significant drawbacks: search engines and social media crawlers cannot easily index the content (it does not exist until JavaScript runs), the initial page load is slow (the user sees nothing useful until JavaScript loads, parses, executes, and fetches data), and performance on slow devices or slow networks degrades significantly.
The rendering strategy landscape that Next.js navigates: server-side rendering (SSR), which generates the full HTML on the server for each request and sends it to the browser; static site generation (SSG), which generates the full HTML at build time and serves pre-built pages from a CDN; incremental static regeneration (ISR), which combines the performance of static pages with the freshness of server rendering by rebuilding static pages at defined intervals; and React Server Components (RSC), which render some components entirely on the server while others run on the client, enabling fine-grained control over which code runs where.
Server-Side Rendering: When to Generate HTML on Each Request
Server-side rendering generates the complete HTML for each page request on the server, using the request’s context (the URL, query parameters, cookies, and headers) to produce a page that is immediately meaningful when delivered to the browser. The SSR approach produces excellent SEO (the HTML is fully rendered when crawlers request it), good initial load experience (the user sees rendered content as soon as the HTML arrives, before JavaScript runs), and the ability to include personalised or real-time data that cannot be pre-built at deploy time.
The SSR use cases that most clearly justify the server computation cost per request: pages that contain user-personalised content that changes per user (the authenticated dashboard, the user profile page, the personalised recommendation feed), pages that depend on data that changes frequently enough that static generation would produce stale content (news articles, product inventory, stock prices), and pages that depend on request-specific information (the page behind authentication, the page that depends on geolocation or cookie values). The page that can be pre-built as identical for all users at build time or served from a CDN cache is better served by static generation than by SSR.
Static Generation: Pre-Building for Maximum Performance
Static site generation produces the complete HTML for each page at build time — when the code is deployed, not when users request pages. The pre-built HTML is uploaded to a CDN and served to every user from the CDN edge node closest to them, with no server-side computation required for each request. The result is the fastest possible page delivery — the HTML is pre-computed and served from the CDN, with latency limited only by the network path from the CDN edge to the user’s device.
The static generation limitation that most determines its applicability: the staleness of the pre-built content. The static page built at deploy time reflects the data available at that moment; any data changes after the build are not reflected until the next build and deployment. The product catalogue page where products are added or removed infrequently may be adequately fresh if rebuilt daily; the news homepage where articles are published continuously would be unacceptably stale if rebuilt only once per day. Incremental Static Regeneration addresses this limitation by rebuilding specific static pages on a defined schedule or in response to specific events, enabling static-quality delivery with more manageable freshness trade-offs for pages with moderate update frequency.
React Server Components: The New Mental Model
React Server Components, introduced in React 18 and deeply integrated into Next.js App Router, represent the most significant shift in how React applications are structured since the introduction of hooks. Server Components are React components that render exclusively on the server and are never sent to the client as JavaScript — they produce HTML that is streamed to the client, but the component code itself never runs in the browser. This enables a new pattern: Server Components can directly access databases, file systems, and server-side APIs without the API route intermediary that client-side data fetching requires, and the result of that data access is rendered to HTML on the server without the corresponding JavaScript being shipped to the client.
The React Server Components benefit that most changes the architecture of complex web applications: the ability to compose server-side data fetching directly into the component tree rather than in API routes, getServerSideProps, or useEffect hooks. The Server Component that directly queries a database and renders the result ships no data-fetching JavaScript to the client, exposes no API endpoints that could be queried by unauthorized requests, and eliminates the loading state that client-side data fetching requires. The component tree can include a mix of Server Components (for data-fetching and rendering that does not require client interactivity) and Client Components (for the interactive elements that require event handlers and browser APIs), with the boundary between them explicitly declared using the use client directive.
Deploying and Operating Next.js Applications
The Next.js deployment options that most reflect the trade-offs between simplicity, control, and cost: Vercel (the company that develops Next.js provides a deployment platform with first-class support for all Next.js features including Edge Functions, ISR, and Image Optimisation — the simplest deployment path at a cost that scales with usage), self-hosted deployment on a Node.js server (which provides full control over the runtime environment and infrastructure costs, at the expense of configuration and operations overhead), and containerised deployment using Docker (which provides the portability to deploy on any infrastructure — cloud VMs, Kubernetes, or managed container services — with predictable resource consumption).
The Next.js production performance optimisation that most developers implement too late: the bundle analysis that reveals which JavaScript packages are contributing the most to the client-side bundle size. The large client-side bundle that must download and parse before the page becomes interactive is a significant performance bottleneck, and it is almost always caused by a small number of large packages. The @next/bundle-analyzer package provides the visualisation that makes the largest bundle contributors visible, enabling targeted replacement (with smaller alternatives) or lazy loading (with dynamic imports that load the package only when it is needed) that can reduce bundle size significantly.