Questions
23 of 33
1Explain server-side rendering (SSR) in Next.js.
2List the benefits of Server-Side Rendering in Next.js.
3What are server components?
4How to use server components in next js?
5What is the React Server Component Payload (RSC)?
6Describe how server components are rendered.
7Describe server rendering strategies
8How can you keep Server-only Code out of the Client Environment
9What are the issues of using context provider at the root of the application?
10List dynamic functions available to server components.
11List all Dynamic APIs.
12How do we opt for Static Rendering, Dynamic Rendering and Streaming?
13Explain the difference between SSR, SSG, ISR, and CSR in Next.js. When would you choose each?
14How does getServerSideProps work internally? What is its execution context?
15What are the performance trade-offs of SSR vs SSG in a high-traffic production app?
16How does Next.js handle hydration? What is a hydration mismatch, and how do you debug it?
17What happens when getServerSideProps throws an error? How do you handle it gracefully?
18How would you architect a Next.js app that needs both personalised (SSR) and cacheable (SSG) pages at scale?
19Explain the App Router vs Pages Router SSR model differences. How does React Server Components change the SSR paradigm?
20How do React Server Components (RSC) differ from traditional SSR? Can they be used together?
21How does streaming SSR work in Next.js 13+? What role does Suspense play?
22How would you implement partial hydration or Islands Architecture in Next.js?
23Explain how Next.js handles data fetching waterfall problems in SSR and how you'd mitigate them.
24How would you implement partial hydration or Islands Architecture in Next.js?
25How do you implement caching strategies for SSR responses in Next.js? (CDN, Cache-Control, stale-while-revalidate)
26How would you reduce TTFB (Time to First Byte) in an SSR-heavy Next.js app?
27What's the difference between fetch caching in the App Router vs traditional getServerSideProps?
28How do you avoid redundant database/API calls across multiple server components on the same page?
29How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?
30How do you prevent sensitive server-side data from leaking to the client bundle?
31How would you implement role-based rendering on the server without exposing protected routes to the client?
32How do you debug SSR-only issues that don't appear in local development?
33How can we control dynamic rendering behaviour in next js?
23 / 33

Explain how Next.js handles data fetching waterfall problems in SSR and how you'd mitigate them.

Next.js SSR waterfalls occur when nested components fetch data sequentially; mitigate using parallel data fetching, React Suspense, streaming SSR, and data loading libraries like SWR or TanStack Query

Data fetching waterfalls are a critical performance issue in Server-Side Rendering (SSR). They occur when components fetch data sequentially—one request must complete before the next begins—delaying page rendering and increasing Time to First Byte (TTFB). In Pages Router with getServerSideProps, waterfalls often happen when multiple API calls are made sequentially or when nested components fetch data after the parent completes. In App Router, Server Components can create waterfalls when imports or data fetching are chained. Next.js provides several mitigation strategies: parallel data fetching, Suspense boundaries with streaming, and integration with data-fetching libraries that support concurrent requests.

Types of Waterfalls in Next.js
  1. 1

    Request waterfalls: Sequential API calls where the second depends on data from the first (e.g., fetch user, then fetch their orders).

  2. 2

    Component waterfalls: Parent component completes before child component starts fetching its data.

  3. 3

    Import waterfalls: Dynamically imported components load only after parent renders, delaying their data fetching.

  4. 4

    Render-as-you-fetch waterfalls: Without Suspense, the server blocks rendering until all data is available.

The Waterfall Problem in Pages Router
Solution 1: Parallel Data Fetching in Pages Router

The App Router introduces a fundamental solution to waterfalls through Suspense and streaming SSR. Instead of blocking the entire page on all data, you can wrap each data-dependent component in Suspense. The server sends the static shell immediately, then streams each component as its data resolves. This eliminates the perception of waterfalls because users see content progressively, even if data fetching happens sequentially on the server. For example, a dashboard could show the user info first, then orders when ready, then recommendations—all without blocking the initial paint.

Solution 2: App Router with Suspense Boundaries
Solution 3: Parallel Data Fetching in Server Components
  1. 1

    Use Promise.all inside Server Components to fetch multiple independent data sources concurrently.

  2. 2

    Move data fetching to child components that can run in parallel with Suspense boundaries.

  3. 3

    For dependent data, consider whether the dependency is truly necessary or if you can restructure.

  4. 4

    Leverage React's cache() function to deduplicate identical requests across multiple components.

  5. 5

    Implement a data loader pattern where parent components fetch common data and pass via props.

Solution 3: Parallel Fetching in Server Components

For pages that can tolerate showing loading states, moving data fetching to the client can eliminate server-side waterfalls entirely. Libraries like SWR and TanStack Query (React Query) provide powerful caching, deduplication, and parallel fetching capabilities. Combined with a static shell (SSG), this approach gives you the best of both worlds: fast initial load from CDN and fresh data fetched in parallel on the client. This is particularly effective for authenticated pages or dashboards where SEO isn't critical.

Solution 4: Client-Side Parallel Fetching with SWR
Solution 5: Preload Patterns and Early Initiation
  1. 1

    Use React's preload API: <link rel="preload" href="/api/data" as="fetch"> in head to start requests early.

  2. 2

    Implement route-based prefetching: Use Next.js router.prefetch() to load data before navigation completes.

  3. 3

    Create a data router pattern: In App Router, lift data fetching to layouts so child routes don't refetch.

  4. 4

    Use React cache() to deduplicate: export const getUser = cache(() => fetchUser()); ensures one request per render.

Solution 5: Preload and Cache Patterns

To effectively mitigate waterfalls, you need to measure them. Use browser DevTools Network tab to see request timing and sequence. In Next.js, enable logging with logging: { fetches: { fullUrl: true } } in next.config.js to see server-side fetch timing. Tools like @next/bundle-analyzer can show if large dependencies are causing import waterfalls. For production, consider using OpenTelemetry or platforms like Vercel Analytics to track TTFB and identify pages with waterfall issues. The key metrics to watch are Time to First Byte (TTFB) and how it correlates with data fetching patterns.