Question 1

What is SSR in Next.js?

Accepted Answer

HTML is generated on the server per request (or as dynamic render), then hydrated on the client as needed. SSR helps SEO and first paint with up-to-date data. Cost is server compute and TTFB. In App Router, dynamic rendering is the SSR analogue.

Question 2

When is SSR preferable to static generation?

Accepted Answer

When content is personalized, highly request-specific, or must always be fresh without revalidation complexity. Authenticated dashboards, A/B gated pages, and frequently changing inventory may need SSR. Still cache fragments where possible.

Question 3

How do you SSR with authentication cookies?

Accepted Answer

Read cookies on the server, fetch user-scoped data, and avoid caching personalized responses as public. Use cookies() which marks the route dynamic. Set Cache-Control carefully. Never store session HTML in a shared CDN cache without Vary/private.

Question 4

What are SSR performance pitfalls?

Accepted Answer

Waterfall fetches, blocking the whole page, large server work on the critical path, and no streaming. Parallelize data loading, stream with Suspense, cache shared lookups, and move rare work off the request path.

Question 5

How does SSR interact with third-party scripts?

Accepted Answer

Prefer next/script strategies; don't block HTML on non-critical scripts. Server HTML should remain useful without scripts. Hydration cost grows with client JS — keep client islands small even on SSR pages.

Question 6

Compare classic getServerSideProps SSR to App Router dynamic rendering.

Accepted Answer

Both render per request; App Router uses async components/caching primitives instead of a single page props function. App Router encourages finer-grained data fetching and streaming. Migration requires rethinking cache boundaries rather than 1:1 API mapping.

SSR Next.js Interview Questions

Other Next.js interview topics