Server-Side Rendering generates the full HTML for a page on the server in response to each request, then sends the complete markup to the browser. The user sees content immediately without waiting for JavaScript to download and execute. Once the HTML arrives, the framework "hydrates" it by attaching event listeners and making it interactive.
How It Works
When a user requests a page, the server runs your component code, fetches any needed data, and produces the final HTML string. This arrives at the browser ready to display. Meanwhile, the JavaScript bundle downloads in the background. Once loaded, the framework takes over the pre-rendered HTML, binding click handlers, form logic, and state management. This process is called hydration.
In Next.js, any page that uses getServerSideProps or server components runs on each request. The data fetching happens server-side with direct database access, API calls, or file system reads, none of which expose secrets to the client.
Why It Matters
SSR solves two critical problems. First, it gives search engines fully rendered HTML to crawl, improving SEO significantly over client-rendered SPAs. Second, it improves perceived performance: users see meaningful content in milliseconds rather than staring at a loading spinner while JavaScript boots up.
SSR is well-suited for content that changes frequently and must be fresh on every request, such as personalized dashboards, search results, e-commerce product pages with real-time pricing, and social feeds.
In Practice
An e-commerce product page needs SSR because pricing, stock levels, and reviews change constantly. The server fetches current data, renders the page with accurate information, and sends it ready to display. The page is indexable by Google, shareable on social media (with proper meta tags), and visible within 200-400ms even on slow connections.
Pro Tips
SSR adds server load since every request triggers rendering. Cache aggressively where possible. Consider streaming SSR (React 18+) to send HTML in chunks as data resolves, improving time-to-first-byte. For pages that do not need per-request freshness, static generation is faster and cheaper.