SSR

## 1. Learning Objectives By the end of this lesson, you will be able to: - Explain server-side rendering in the App Router. - Fetch request-time data in a Server Component. - Identify when SSR is better than CSR or SSG. - Understand the performance tradeoff of rendering on each request. Difficulty: Beginner. ## 2. Prerequisites - App Router pages. - Server Components. - Basic data fetching. ## 3. Overview Server-side rendering means the server creates HTML for a request before sending it to the browser. In the App Router, Server Components make SSR feel natural: pages can directly `await` data and return UI. ## 4. Why This Topic Matters SSR is important for personalized pages, authenticated dashboards, frequently changing data, and SEO pages that must reflect current state. It gives users useful HTML before client JavaScript runs. ## 5. Real-World Analogy SSR is like ordering food from a kitchen that cooks it fresh for you. It may take a little longer than grabbing a pre-packed meal, but the result can match your exact request. ## 6. Core Concepts | Concept | Meaning | |---|---| | Request-time render | HTML is generated when a request arrives. | | Server Component | Component that runs on the server and can await data. | | Dynamic route | Route that depends on request data or uncached fetches. | | Personalized HTML | HTML that may differ per user or request. | | TTFB | Time to first byte; SSR work can affect it. | ## 7. Syntax & API Reference

Request-bound APIs such as cookies and headers make a route dynamic:

## 8. Visual Diagram

## 9. Live Example - Full Working Code

What just happened? `cache: 'no-store'` asks Next.js to fetch fresh data for the request instead of reusing a cached result. ## 10. Interactive Playground Try this locally: - Render request headers in a Server Component. - Change `cache: 'no-store'` to a cached fetch and compare behavior. - Add a Client Component button inside the server-rendered page. ## 11. Common Mistakes | Mistake | Why It Happens | Correct Approach | |---|---|---| | Using SSR for content that never changes | Fresh rendering feels safe. | Use SSG for stable content. | | Doing slow work before rendering anything | SSR waits for server work. | Use streaming or split slow sections. | | Reading browser APIs in Server Components | SSR code runs on the server. | Move browser APIs to Client Components. | ## 12. Best Practices - Use SSR for personalized or highly fresh data. - Keep request-time work fast. - Cache expensive shared data when possible. - Stream slow sections instead of blocking the whole page. - Validate authorization on the server, not only in middleware. ## 13. Browser Compatibility | Feature | Browser Impact | Notes | |---|---|---| | SSR HTML | Broad support | Browser receives normal HTML. | | Hydration | Requires JavaScript for interactivity | Static content remains visible. | | Server-only APIs | No browser impact | Run before response is sent. | ## 14. Interview Questions **Easy:** What is SSR? Answer: Server-side rendering generates HTML on the server for a request. **Medium:** When should you choose SSR? Answer: Use SSR for personalized, request-specific, or frequently changing data that should appear in initial HTML. **Hard:** What is the main tradeoff of SSR? Answer: It improves freshness and initial HTML but can increase server load and TTFB if request-time work is slow. ## 15. Debugging Exercise Bug report: "Our account page shows stale data for different users." The page fetches account data with a shared cached request. Solution Use request-specific data access, include the authenticated user in the query, avoid sharing private cached responses, and validate authorization in the server code. ## 16. Practice Exercises - Easy: Render a server timestamp on each request. - Medium: Read a cookie and customize a page. - Hard: Build a server-rendered account page with a small client-only settings toggle. ## 17. Scenario-Based Challenge A pricing page changes once a month, but an account dashboard changes every request. Which rendering strategy fits each? Walkthrough Use SSG or ISR for the pricing page. Use SSR for the account dashboard because it is personalized and request-specific. ## 18. Quick Quiz 1. Where does SSR render HTML? Answer: On the server. 2. Can Server Components await data? Answer: Yes. 3. Is SSR best for stable docs pages? Answer: Usually no. 4. What metric can SSR server work affect? Answer: TTFB. 5. What option forces fresh fetch data? Answer: `cache: 'no-store'`. ## 19. Summary & Key Takeaways - SSR renders fresh HTML per request. - App Router Server Components make SSR straightforward. - SSR is best for personalized or frequently changing pages. - Slow SSR work can delay the first byte. - Streaming can reduce the pain of slow server sections. ## 20. Cheat Sheet | Situation | SSR Fit | |---|---| | Account dashboard | Strong | | Public docs | Weak | | User-specific settings | Strong | | Marketing homepage | Depends | | Real-time-ish server data | Strong | ## 21. Further Reading - Next.js Docs: Server Components. - Next.js Docs: Fetching and Caching. - web.dev: Server-side rendering. ## 22. Next Lesson Preview Next, you will learn SSG, where pages are generated ahead of time for maximum speed.