ReviseAlgo Logo

Rendering

SSR

Learn server-side rendering in Next.js, how request-time data works, and when fresh server-rendered HTML is the right tradeoff.

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

    ConceptMeaning
    Request-time renderHTML is generated when a request arrives.
    Server ComponentComponent that runs on the server and can await data.
    Dynamic routeRoute that depends on request data or uncached fetches.
    Personalized HTMLHTML that may differ per user or request.
    TTFBTime 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

    MistakeWhy It HappensCorrect Approach
    Using SSR for content that never changesFresh rendering feels safe.Use SSG for stable content.
    Doing slow work before rendering anythingSSR waits for server work.Use streaming or split slow sections.
    Reading browser APIs in Server ComponentsSSR 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

    FeatureBrowser ImpactNotes
    SSR HTMLBroad supportBrowser receives normal HTML.
    HydrationRequires JavaScript for interactivityStatic content remains visible.
    Server-only APIsNo browser impactRun 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

    SituationSSR Fit
    Account dashboardStrong
    Public docsWeak
    User-specific settingsStrong
    Marketing homepageDepends
    Real-time-ish server dataStrong

    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.