SSR
Cheat Sheet
Prime Use Case
Use SSR when SEO is a primary requirement, initial page load performance (FCP/LCP) is critical for conversion, or when users are likely on low-powered devices with slow network connections.
Critical Tradeoffs
- Improved First Contentful Paint (FCP) vs. Increased Time to First Byte (TTFB)
- Better SEO and Social Sharing vs. Increased Server Load and Complexity
- Faster perceived performance vs. 'Uncanny Valley' (UI visible but not interactive during hydration)
Killer Senior Insight
SSR is fundamentally a strategy to trade server-side compute and latency for client-side execution time; in the modern era, the 'Hydration Gap' is the real bottleneck, not the rendering itself.
Recognition
Common Interview Phrases
Common Scenarios
- E-commerce product listing and detail pages.
- Public-facing marketing sites and blogs.
- Personalized dashboards that require SEO (e.g., public profiles).
- News and media publishing platforms.
Anti-patterns to Avoid
- Using SSR for internal, authenticated-only admin tools where SEO is irrelevant.
- Implementing SSR for highly stateful, 'app-like' experiences (e.g., a complex photo editor) where the initial HTML is negligible compared to the JS bundle.
- SSR without a caching layer (CDN/Edge) for high-traffic global sites.
The Problem
The Fundamental Issue
The 'Empty Div' problem of Client-Side Rendering (CSR), where the browser receives a blank HTML shell and must wait for large JavaScript bundles to download and execute before the user sees any content.
What breaks without it
Search engine rankings suffer due to slow or failed indexing of dynamic content.
High bounce rates on mobile due to long 'white screen' durations.
Social media platforms fail to scrape metadata for rich link previews.
Why alternatives fail
CSR requires a full round-trip for JS plus additional round-trips for data fetching before rendering.
Static Site Generation (SSG) fails when content is highly dynamic or personalized per user request.
Pre-rendering services are often brittle and difficult to maintain compared to integrated SSR frameworks.
Mental Model
The Intuition
Imagine a restaurant: CSR is like giving the customer a recipe and raw ingredients to cook at their table. SSR is the chef cooking the meal in the kitchen and serving it ready-to-eat, though the customer still needs to wait for the waiter to bring the silverware (JavaScript) to start eating.
Key Mechanics
Request Interception: The server receives the URL and headers (cookies/auth).
Data Fetching: The server fetches all necessary data for the specific route.
String Serialization: The UI framework (e.g., React) renders the component tree to an HTML string.
State Dehydration: The fetched data is serialized into the HTML (e.g., window.__PRELOADED_STATE__).
Hydration: The client-side JS 'wakes up' the static HTML by attaching event listeners and synchronizing state.
Framework
When it's the best choice
- When content changes frequently (every minute/second) and must be reflected immediately in SEO.
- When the application has a large number of dynamic routes that make SSG build times prohibitive.
- When user-specific personalization is required on the initial render.
When to avoid
- When the server infrastructure cannot scale to handle the compute-intensive task of rendering HTML for every request.
- When the application is behind a strict login and has zero SEO requirements.
- When the 'Uncanny Valley' (TTI vs FCP gap) creates a frustrating user experience.
Fast Heuristics
Tradeoffs
Strengths
- Optimal SEO: Content is immediately available to all crawlers.
- Faster First Contentful Paint: Users see content almost instantly after the HTML arrives.
- Consistent performance across devices: The heavy lifting of rendering is moved to the server.
Weaknesses
- Increased TTFB: The server must wait for data and rendering before sending the first byte.
- Hydration Overhead: The browser must still download and execute JS to make the page interactive.
- Server Complexity: Requires a Node.js environment and careful management of memory/CPU.
Alternatives
When it wins
When content is the same for all users and doesn't change per request.
Key Difference
HTML is generated at build time, not request time.
When it wins
When you have millions of pages and want the benefits of SSG with the freshness of SSR.
Key Difference
Revalidates static pages in the background on a per-route basis.
When it wins
For highly interactive dashboards or SPAs where SEO is irrelevant.
Key Difference
The browser handles all rendering; the server only serves static assets.
Execution
Must-hit talking points
- Mention the 'Uncanny Valley' where the page looks ready but clicks don't work.
- Discuss 'Streaming SSR' to improve TTFB by sending HTML chunks as they are ready.
- Explain 'Hydration' and the importance of matching the server-rendered HTML with client-side state.
- Address data fetching strategies (e.g., getServerSideProps vs. React Server Components).
Anticipate follow-ups
- Q:How do you handle authentication in SSR?
- Q:What happens if the server-side data fetch fails but the client-side render succeeds?
- Q:How do React Server Components (RSC) differ from traditional SSR?
- Q:How do you optimize the 'Hydration' phase to reduce TTI?
Red Flags
Accessing browser-only globals like 'window' or 'document' in the render path.
Why it fails: The Node.js server environment does not have these globals, causing the server to crash or throw errors during rendering.
Ignoring the 'Double Data' problem.
Why it fails: Sending the data both as HTML and as a JSON payload for hydration doubles the byte size of the response if not managed correctly.
Not implementing a timeout for server-side data fetching.
Why it fails: A single slow API dependency can hang the entire server request, leading to terrible TTFB and potential cascading failures.