Server-side rendering (SSR) is a web rendering technique where HTML is generated on the server for each incoming request. The fully rendered page is then sent to the browser, where it becomes interactive through a process called hydration.
SSR combines the SEO benefits of traditional server-rendered websites with the interactivity of modern JavaScript frameworks.
How SSR Works
- User requests a page — browser sends a request to the server
- Server processes the request — fetches data, runs logic, generates HTML
- Full HTML is sent — browser receives a complete page with content
- Hydration — JavaScript loads and makes the page interactive
- Page is fully interactive — user can interact with all elements
The key difference from client-side rendering: users see content immediately, before JavaScript loads.
SSR vs Other Rendering Methods
| Method | HTML Generated | Best For | Trade-off |
|---|---|---|---|
| SSR | On each request, on server | Dynamic, personalized content | Server load per request |
| SSG | At build time | Static content, blogs | Stale content between builds |
| CSR | In browser | SPAs, dashboards | Poor initial load, SEO issues |
| ISR | At build time + revalidation | Best of SSR + SSG | Slight complexity |
Benefits of SSR
SEO Performance
Search engines receive fully rendered HTML with all content, meta tags, and structured data. No reliance on JavaScript execution for indexing.
Faster First Contentful Paint
Users see meaningful content immediately because HTML arrives pre-rendered. No blank white screen while JavaScript loads and executes.
Dynamic Content Support
Every request can return fresh data. User-specific content, real-time pricing, and personalized experiences are all possible.
Social Media Previews
Open Graph and Twitter Card meta tags are present in the initial HTML, ensuring correct previews when pages are shared.
Trade-offs of SSR
Server Load
Every request requires server processing. High traffic means more server resources needed, increasing costs.
Time to First Byte (TTFB)
Server processing adds latency before the first byte reaches the browser. Complex pages with many data fetches take longer.
Infrastructure Complexity
SSR requires a running server (Node.js, edge functions, etc.), unlike static sites that can be served from a simple CDN.
SSR with Next.js
Next.js makes SSR straightforward with Server Components (default in the App Router):
// app/products/[id]/page.tsx
// This component runs on the server by default
export default async function ProductPage({ params }) {
const product = await fetchProduct(params.id);
return (
<div>
<h1>{product.name}</h1>
<p>{product.description}</p>
<span>${product.price}</span>
</div>
);
}
With Next.js App Router, every component is server-rendered by default unless you explicitly opt into client-side rendering with "use client".
When to Use SSR
SSR is the right choice when:
- SEO is critical — content must be immediately indexable
- Content changes frequently — real-time data, personalized pages
- Social sharing matters — correct previews on social platforms
- First load speed matters — users need to see content fast
When to Choose Alternatives
- Content rarely changes → Use SSG or ISR instead
- Fully interactive app → CSR might be simpler
- Extremely high traffic on static pages → SSG + CDN is more efficient
SSR vs SSG: pick by data freshness
If the page content changes every hour or less → use SSR. If it changes daily or weekly → use SSG with ISR. If it's user-specific → SSR is the only option. Next.js Server Components make SSR the default without extra config.
How Moydus Implements SSR
At Moydus, we use Next.js Server Components for optimal rendering:
- SSR for dynamic pages (product listings, search results, personalized content)
- SSG/ISR for content pages (blog posts, landing pages, documentation)
- Edge rendering via Cloudflare Workers for global low-latency delivery
- Streaming SSR for progressive page loading
This hybrid approach gives every page the optimal rendering strategy.