Explain streaming with Server Components, Suspense, and loading.js
Tests progressive HTML streaming through Suspense boundaries. Strong answers state loading.js auto-wraps a route segment in Suspense so the server can stream the shell instantly and defer slow data without blocking first paint.
What's really being asked
This question probes whether you understand the difference between traditional SSR all-or-nothing rendering and React's streaming model in the Next.js App Router. The interviewer wants to see that you know Server Components can suspend on async IO, that the server can emit HTML in chunks, and that loading.js is a framework convention rather than a client-side state management pattern. They are also checking if you can connect architecture to user experience metrics like TTFB and LCP.
The full answer
First, define streaming as the progressive transmission of HTML from the server to the browser. The shell renders immediately while slow data fetches are pending. Second, explain that loading.js is a special file in the App Router that Next.js automatically wraps around the route segment as a Suspense fallback. Third, describe the lifecycle: the server sends the static shell plus the loading UI first, then when the suspended Server Component resolves its data, Next.js streams a small inline script and the final HTML chunk to replace the fallback. Fourth, tie this to UX by noting that TTFB stays fast because the browser does not wait for the slow query, and LCP improves because meaningful pixels paint earlier. Fifth, mention that because the work stays on the server, the client bundle does not bloat with data fetching logic.
The mistakes people make
A major red flag is describing loading.js as a client-side spinner driven by useState or useEffect. Another is saying you must manually wrap every page in a Suspense boundary; loading.js exists precisely to avoid that boilerplate. Candidates sometimes claim streaming requires client components, when in fact it is Server Components that suspend and stream. Confusing this with the older pages router getServerSideProps pattern is also a signal of shallow experience, since that model blocked rendering until all data resolved.
What usually comes next
The interviewer may ask how you would handle a nested route where both a parent and a child have loading.js files. They might also ask about error.js and how it interacts with Suspense boundaries. Another common pivot is asking whether you can stream from a client component, or how you would opt out of streaming for a specific route. You should also be ready to discuss the fallback waterfall problem and why granular Suspense boundaries beat a single page-level loader.
A concrete example
Imagine a dashboard at app/dashboard/page.js that awaits a slow analytics query taking 800 milliseconds. Without streaming, the user stares at a blank screen until the entire HTML arrives. By adding app/dashboard/loading.js that exports a skeleton chart, Next.js wraps the page in a Suspense boundary automatically. The server sends the layout, sidebar, and skeleton within 50 milliseconds. When the query resolves, Next.js streams the remaining HTML and a tiny inline script that swaps the skeleton for the real chart. The user perceives the page as instant, and Core Web Vitals improve because the browser can paint the shell and hydrate incrementally.
Interview question
During streaming SSR in the Next.js App Router, what does loading.js do when a Server Component suspends on a slow data fetch?
- a.It blocks HTML emission until all data promises resolve, similar to getServerSideProps.
- b.It provides a client-side fallback using useState and useEffect while the server request completes.
- c.It requires the developer to manually wrap the route in a Suspense boundary to display the fallback.
- d.It automatically wraps the route segment in a Suspense boundary so the server streams the shell first.Correct
Why? this is the answer
loading.js is a framework convention that automatically wraps the route segment in a Suspense fallback, enabling the server to stream the shell instantly while deferring slow data. Option B is a common misconception because loading.js is not a client-side spinner driven by useState or useEffect; it is part of the server streaming architecture.
Just read this? Test yourself on what you have been reading.
Read the original → nextjs.org
- #react
- #next.js
- #server components
- #suspense
- #streaming
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles