Beginner Q&A

1. What is Server-Side Rendering (SSR)?

Server-Side Rendering (SSR) means HTML is generated on the server for each request (or based on caching strategy), then sent to the browser as ready-to-view content.

2. What is Static Site Generation (SSG)?

Static Site Generation (SSG) means HTML pages are generated at build time and stored as static files. Users are served those prebuilt files directly.

3. What is Pre-rendering?

Pre-rendering is the process of rendering pages before users request them. In practice, this usually means generating HTML during build time for known routes.

4. What is the difference between CSR and SSR?

• CSR (Client-Side Rendering): Browser gets a mostly empty HTML shell and JavaScript builds the page on the client.
• SSR (Server-Side Rendering): Server sends fully rendered HTML first, then client JavaScript adds interactivity.

5. Why do we use SSR or SSG instead of CSR?

SSR and SSG improve first-load content visibility and search engine crawlability, especially for content-heavy pages and public marketing pages.

6. What are the advantages of SSR?

• Better first meaningful content for users on slower devices/networks.
• Strong SEO because content exists in initial HTML.
• Better social sharing previews (Open Graph/Twitter cards).
• Works better for dynamic pages that still need SEO.

7. What are the advantages of SSG?

• Very fast page delivery via CDN/static hosting.
• Lower hosting complexity and cost.
• Strong SEO with prebuilt HTML.
• High reliability since output is static files.

8. What are the disadvantages of SSR?

• Higher server complexity and infrastructure cost.
• Slower response under heavy load if not cached well.
• More moving parts (render server, caching, hydration, monitoring).

9. What are the disadvantages of SSG?

• Content updates require rebuild and redeploy.
• Build times can grow for large sites with many pages.
• Not ideal for highly personalized per-request content without hybrid patterns.

10. What types of websites benefit most from SSR?

• E-commerce product/category pages.
• News and publishing sites with frequently updated public content.
• SEO-critical apps with dynamic content.
• Web apps needing fast first paint plus personalization after load.

11. What types of websites benefit most from SSG?

• Blogs.
• Documentation sites.
• Marketing/landing pages.
• Portfolios and mostly static company websites.

12. What is hydration in SSR?

Hydration is when browser JavaScript attaches event handlers and app logic to server-rendered HTML so the page becomes fully interactive.

13. What happens after the browser receives an SSR page?

1. Browser parses and paints the server-rendered HTML.
2. CSS and JS assets load.
3. Framework bootstraps on the client.
4. Hydration connects components/events.
5. Page transitions into full client-side interactivity.

14. What is the difference between rendering on server vs rendering on browser?

• Server rendering: HTML is created on the server, then sent ready for display.
• Browser rendering: HTML is assembled in the browser using JavaScript after initial load.

Server rendering prioritizes initial content delivery. Browser rendering prioritizes rich client control after scripts load.

15. What is SEO advantage of SSR/SSG?

SSR and SSG provide indexable HTML content immediately, making it easier for search engines to crawl page text, headings, links, and metadata without waiting for heavy client-side JavaScript execution.

16. Which one will be faster: CSR, SSR, or SSG?

It depends on what "faster" means:

• Fastest initial page delivery: SSG (prebuilt static HTML served from CDN).
• Fast first content for dynamic pages: SSR (HTML rendered on server per request or cache miss).
• Fast after first load in app-like navigation: CSR (once JS is loaded, transitions can feel very quick).

So for most public content pages, SSG is usually fastest overall for first load.

Beginner-Intermediate Q&A

Rendering Flow

1. How does SSR work internally?

In SSR, the server runs the framework rendering pipeline for each request (or each cache miss), generates HTML for the route, and sends that HTML to the browser. After that, client-side JavaScript hydrates the page to make it interactive.

2. How does SSG work during build time?

During build, the framework renders selected routes ahead of time and writes them as static HTML files. These files are then deployed to static hosting/CDN and served directly to users.

3. What is the difference between build time rendering and request time rendering?

• Build time rendering: HTML is generated once during build/deploy (SSG).
• Request time rendering: HTML is generated when a user requests a page (SSR).

4. What happens when a user requests a page in SSR?

1. Browser sends a request for a route.
2. Server runs render logic and prepares HTML.
3. Server returns rendered HTML.
4. Browser paints content quickly.
5. JS loads and hydrates for interaction.

5. What happens when a user requests a page in SSG?

1. Browser requests a route.
2. CDN/server returns prebuilt static HTML instantly.
3. Browser displays content.
4. JS (if included) hydrates/enhances interactivity.

Framework Specific

6. How does Angular SSR (Angular Universal) work?

Angular SSR uses server-side Angular runtime (@angular/ssr) to render routes on the server. For each matching request, Angular resolves route data, renders components to HTML, and sends that HTML response. Then Angular hydrates on the client.

7. How does Next.js SSR work?

In Next.js SSR mode, the server renders the page per request (commonly via server components/data fetching on request) and returns HTML with serialized data required for hydration.

8. How does Next.js SSG work?

In Next.js SSG mode, pages are generated at build time (next build) using known routes/data and shipped as static assets. Users then receive these pre-generated pages with very fast initial response.

9. What is pre-rendering in Angular?

Pre-rendering in Angular means generating static HTML for routes at build time. It is essentially Angular’s SSG approach for routes you can determine ahead of deployment.

10. What is hydration in Angular SSR?

Hydration in Angular SSR is the client process where Angular attaches event listeners and restores app behavior on top of server-rendered HTML without rebuilding the full DOM from scratch.

SEO

11. Why does Google prefer SSR or SSG?

SSR/SSG provide content in initial HTML, which reduces dependence on client-side JavaScript execution and makes crawling/indexing faster and more reliable.

12. Does Google index CSR websites properly?

Google can index many CSR sites, but reliability varies with script loading, rendering complexity, and crawl budget. SSR/SSG usually give more predictable indexing outcomes.

13. How does SSR help social media previews (OpenGraph tags)?

With SSR, metadata like og:title, og:description, and og:image is present in server-rendered HTML at response time, so social crawlers can read preview tags immediately.

Intermediate Q&A

Architecture

1. What is the difference between SSR, SSG, and Pre-rendering?

• SSR renders HTML at request time on the server.
• SSG renders HTML at build time and serves static files.
• Pre-rendering usually means generating static HTML in advance for selected routes (often equivalent to SSG for those routes).

2. When would you choose SSR over SSG?

Choose SSR when content must be fresh per request, depends on user/session, or changes too frequently for practical rebuild cycles.

3. When would you choose SSG over SSR?

Choose SSG when routes are known ahead of time and content changes are periodic, not per-request. It gives simpler ops and better raw delivery speed.

4. Can SSR and SSG be used together?

Yes. Many systems use hybrid rendering: SSG for stable pages (home, docs, blog) and SSR for dynamic pages (search, personalized catalog, live pricing).

5. What is Incremental Static Regeneration (ISR)?

ISR is a hybrid strategy where static pages are generated once, then selectively regenerated in the background after a revalidation window, combining static speed with fresher content.

6. What is fallback rendering in static generation?

Fallback rendering handles routes not generated at build time. On first request, the framework can render a fallback/loading state or generate the page on-demand, then cache it for later requests.

7. What is dynamic SSR vs static SSR?

• Dynamic SSR: server generates HTML per request using live data.
• Static SSR (cached SSR): server-rendered output is cached and reused for a TTL, reducing render frequency.

Performance

8. Which is faster: SSR or SSG?

For first-byte and delivery speed, SSG is usually faster because no server render is needed at request time. SSR can still be very fast with strong caching and edge strategy.

9. What are the performance bottlenecks in SSR?

• Slow backend/API calls during render.
• Heavy server-side computation.
• No or poor cache strategy.
• Hydration cost on client for large pages.

10. Why can SSR increase server cost?

SSR shifts render work to servers on each request or cache miss, increasing CPU/memory usage, autoscaling needs, and operational complexity.

11. How does CDN improve SSG performance?

CDN serves static HTML/assets from edge locations near users, reducing latency and origin load while improving global consistency.

12. What is TTFB (Time to First Byte) in SSR?

TTFB is the time from request start until the first response byte arrives. In SSR it includes network time plus server render time and data-fetch latency.

Angular Specific

13. What is the role of server.ts in Angular SSR?

server.ts is the Node/Express entry that serves static assets and forwards route requests to Angular SSR engine for server rendering.

14. What is Angular prerender builder?

It is the Angular build pipeline mode that generates static HTML for routes at build time, using server rendering during build instead of request runtime.

15. How does Angular detect route completion during prerendering?

Angular waits for app stability signals (Zone stabilization) and router navigation completion before finalizing HTML output.

16. What is TransferState in Angular SSR?

TransferState is a server-to-client data bridge that serializes fetched data in SSR HTML and reuses it during hydration.

17. Why do we need TransferState?

To avoid duplicate API calls on the client right after SSR and reduce hydration-time latency and backend load.

Advanced Q&A

Deep Technical

1. What happens during hydration mismatch?

The client-rendered virtual/component tree does not match server HTML. Frameworks may patch, discard, or re-render parts of DOM, causing flicker, warnings, and potential event binding inconsistencies.

2. What causes hydration errors?

• Non-deterministic rendering (Date.now(), random values).
• Browser-only APIs used during server render.
• Different data between server response and client boot.
• Conditional rendering that diverges between environments.

3. How does SSR handle browser-only APIs like window or document?

Server runtime has no real browser globals. Code must guard access (platform checks) or defer browser-only logic until client lifecycle hooks.

4. How do you avoid SSR errors caused by browser APIs?

Use isPlatformBrowser, dependency abstraction layers, lazy imports for browser-only modules, and move DOM operations to client-only execution paths.

5. How does SSR handle authentication or session-based content?

SSR can read cookies/headers on request, resolve user context server-side, and render personalized HTML. Cache keys must vary by auth/session constraints to prevent data leaks.

6. How does SSR handle API calls?

Server performs data fetches during render pipeline, often with timeouts/retries and edge caching. The rendered HTML includes resolved data or placeholders if fetch fails gracefully.

7. How do you prevent duplicate API calls during SSR + hydration?

Serialize server-fetched data into HTML and hydrate from that payload (for Angular, via TransferState) so client does not refetch immediately.

8. What is streaming SSR?

Streaming SSR sends HTML chunks progressively as parts are ready, reducing perceived latency and improving first paint before entire page render completes.

9. What is partial hydration?

Only selected interactive parts are hydrated on client; static regions remain inert HTML, reducing JS execution and hydration cost.

10. What is island architecture?

Page is mostly static HTML with isolated interactive "islands" hydrated independently. This minimizes client JS while retaining interactive components where needed.

Angular Advanced

11. How does Angular handle Zone.js during SSR?

Angular SSR uses Zone.js to track async work. Rendering completes when Zone reports stability (no pending micro/macro tasks relevant to app boot/render).

12. How does Angular know when rendering is complete before sending HTML?

Angular waits for application stabilization and router/data resolution; once stable, server serializer outputs final HTML.

13. What is the role of renderModule() in Angular SSR?

Historically, renderModule() rendered Angular module trees to HTML on server. Modern Angular SSR APIs build on similar server-render concepts with updated runtime integrations.

14. What is APP_INITIALIZER impact in SSR?

APP_INITIALIZER runs during server boot/render too. Heavy async initializers can increase TTFB and should be bounded/optimized.

15. What are platform-server and platform-browser in Angular?

platform-server provides Angular runtime adapters for Node/server rendering. platform-browser provides browser runtime adapters for DOM-based client execution.

Expert and Architect Q&A

System Design Thinking

1. How would you design a large-scale website using SSR and SSG together?

Use a hybrid architecture: SSG for static/high-cache pages, SSR for dynamic and user-context pages, API layer for data composition, CDN edge for caching, and observability across render + API + client metrics.

2. When should SSR pages be cached?

Cache SSR output when data freshness allows short TTL or event-driven invalidation. Do not share cache across users for personalized content unless keys include user segmentation constraints.

3. How would you implement SSR caching?

Use multi-layer caching:

• Application cache (in-memory/Redis) for rendered HTML fragments or full pages.
• CDN edge cache with Cache-Control, s-maxage, stale-while-revalidate.
• Data cache for backend API responses.

4. How does CDN caching work with SSR?

CDN caches SSR responses when headers permit it. Cache key can include path, locale, device class, and selected query params. Personalization requires careful vary policies.

5. How do you scale SSR servers for millions of requests?

Stateless SSR workers behind load balancers, autoscaling, aggressive caching, render budget controls, queue protection, and precomputation for hot routes.

Tradeoffs

6. Compare SSR vs SSG vs CSR for a large e-commerce site.

• SSG: best for stable catalog/landing pages, great edge speed.
• SSR: best for frequently changing inventory/pricing and SEO-critical dynamic pages.
• CSR: best for logged-in user flows (account, cart interactions) after initial load.

7. How would you choose rendering strategy for blog?

SSG first, with optional ISR for freshness.

8. How would you choose rendering strategy for e-commerce?

Hybrid: SSG for category/evergreen product content, SSR for volatile pricing/stock/search, CSR for account/cart-heavy interaction zones.

9. How would you choose rendering strategy for dashboard?

Mostly CSR (auth-heavy, real-time interactions), optionally SSR shell for faster first paint.

10. How would you choose rendering strategy for SaaS platform?

Marketing/public docs via SSG, app shell via SSR or CSR depending auth/data needs, feature modules mostly CSR.

DevOps

11. How does CI/CD change when using SSG?

Build pipeline includes full prerender generation, content-triggered rebuilds, artifact deployment to CDN/static host, and preview environments for content validation.

12. Why can SSG increase build times?

Because rendering scales with route count and data-fetch volume at build time. Large route sets require parallelization, incremental builds, or on-demand generation.

13. How do you handle thousands of dynamic routes in SSG?

Prioritize top routes at build, use ISR/on-demand generation for long tail, shard build jobs, and keep deterministic route manifests.

Debugging

14. How do you debug SSR memory leaks?

Use heap snapshots, allocation profiling, request-level memory tracking, and identify retained objects in render/data layers (global caches, closures, unbounded maps).

15. Why might SSR cause slow server response times?

Slow upstream APIs, synchronous CPU-heavy rendering, missing caches, contention under load, and expensive initialization on each request.

16. What logs should be monitored in SSR production systems?

Render time percentiles, TTFB, error rates, timeouts, cache hit ratio, memory/CPU, upstream API latency, and hydration error counts from client telemetry.

Ultra-Advanced Q&A

1. How does Angular SSR detect asynchronous tasks completion before rendering HTML?

Angular SSR relies on application stability signals from Zone.js and Angular testability hooks. Rendering finalization waits until pending async tasks relevant to app boot settle.

2. How does Zone.js track microtasks and macrotasks in SSR?

Zone.js patches async APIs and keeps task bookkeeping. Microtasks (promises) and macrotasks (timers, IO callbacks) are tracked so Angular can determine stability boundaries.

3. What happens if SSR sends HTML before all async tasks finish?

Response may miss required data or metadata, leading to incomplete HTML, hydration divergence, layout shifts, or client-side refetch/re-render spikes.

4. How would you implement custom prerendering pipeline?

Create a route manifest generator, batch rendering workers, deterministic data-fetch layer, failure retries, output validation, and deploy-time artifact indexing for selective invalidation.

5. How would you implement hybrid rendering architecture?

Classify routes by freshness/personalization/SEO requirements, then assign SSG, SSR, or CSR per route. Add shared cache contracts, unified observability, and policy-driven invalidation.

6. How do modern frameworks optimize hydration cost?

They reduce client JS, split bundles aggressively, stream HTML/data, use partial/progressive hydration, and defer low-priority interactivity until idle.

7. What is resumability vs hydration (Qwik concept)?

Hydration replays component boot on client to attach behavior to HTML. Resumability serializes app state so client resumes execution from server snapshot with minimal re-execution.

Tricky Conceptual Q&A

1. Why is SSG usually faster than SSR?

SSG pages are precomputed at build time, so request-time work is minimal: no server render, lower CPU usage per request, and easier full-page CDN caching. SSR performs rendering during request handling (or cache misses), adding compute and data-fetch latency to response time.

2. If SSR already gives HTML, why do we still need hydration?

SSR HTML is mostly static output. Hydration attaches client-side event handlers, restores framework runtime state, and enables dynamic interactions (click handlers, form logic, client navigation). Without hydration, page content is visible but behavior is limited.

3. Can SSR work without hydration?

Yes, for fully static read-only pages. You can return server-rendered HTML and skip client framework boot. But interactive components will not function unless you add separate progressive enhancement scripts.

4. What happens if JavaScript fails after SSR?

Users still see the server-rendered content (good graceful degradation), but interactivity breaks: buttons relying on framework handlers, client-side routing, and dynamic widgets may stop working. This is why critical flows should degrade safely and not depend exclusively on client boot.

5. Why does SSR sometimes cause double rendering?

One render happens on the server to produce HTML. Another render/hydration phase happens on the client to attach runtime behavior. If server and client data paths are not coordinated, the client can refetch and rerender, creating the perception of "double rendering".

Scenario-Based Q&A

1. Your website has 1M daily visitors. Should you use SSR or SSG?

Use a hybrid strategy.

• Prefer SSG for stable, high-traffic pages to maximize CDN cache hit and reduce origin cost.
• Use SSR only where per-request freshness or personalization is required.

At 1M daily visitors, fully dynamic SSR for everything is usually expensive. Route-level strategy plus aggressive edge caching is the practical approach.

2. Your product pages update every 5 minutes. What rendering strategy?

Use SSR with caching, or SSG + ISR/on-demand revalidation if framework supports it.

• If freshness SLA is strict and data changes frequently, SSR with short TTL cache is safer.
• If slight staleness is acceptable, incremental static regeneration can give near-SSG speed with periodic refresh.

3. Your site has 100k blog pages. Should you prerender them?

Not all at once by default.

• Pre-render top/evergreen pages first.
• Generate long-tail pages incrementally (ISR/on-demand) or in sharded build batches.
• Keep route manifests deterministic and monitor build duration.

Full prerender of 100k pages can make build time and CI cost too high unless optimized heavily.

4. Your dashboard is user-specific. Should it use SSR or CSR?

Usually CSR-first.

• User-specific dashboards are auth-heavy, highly interactive, and less SEO-sensitive.
• CSR reduces server render cost and simplifies personalization in the client app.
• SSR can still be used for a fast initial shell if needed, but core dashboard interactions are typically CSR.