Q233: Streaming, Suspense and Perceived Performance

What Interviewers Want To Evaluate

Interviewers want to know whether you can design loading experiences that reveal useful UI progressively without causing jank or confusion.

They check streaming, Suspense boundaries, skeletons, loading states, perceived performance, progressive rendering, layout stability, error boundaries, and trade-offs between fast shell and complete content.

Short Interview Answer

Streaming and Suspense let an app show stable useful UI before every async dependency is ready. I use boundaries around parts that can load independently, keep skeletons dimensionally close to final content, avoid hiding the whole route behind one slow request, and pair loading boundaries with error handling. The goal is not just earlier pixels; it is earlier useful and stable progress.

Detailed Interview Answer

Perceived performance is about what the user can see and do while work continues.

Bad loading experience:

blank page
large spinner
everything waits for one slow request
layout jumps when content arrives
errors replace the whole page

Better:

stable shell appears
main content streams early
secondary panels load later
skeletons reserve space
errors stay localized

Streaming Mental Model

Streaming sends UI progressively.

Instead of waiting for every dependency, the server can send available parts earlier.

This helps when:

some data is fast
some data is slow
the shell is useful immediately
secondary content can arrive later

The route should not block entirely on non-critical work.

Suspense Boundaries

Suspense defines loading boundaries.

<QuestionContent />
<Suspense fallback={<RelatedQuestionsSkeleton />}>
  <RelatedQuestions />
</Suspense>

The user can read the main content while related questions load.

Boundary placement is a design decision.

Good Boundary Placement

Place boundaries around independently useful sections.

Good candidates:

related content
recommendations
comments
activity feed
secondary analytics
large preview panels

Poor candidates:

every tiny text node
one boundary around the whole page
core content that must appear together

Too many boundaries can make loading feel fragmented.

Skeleton Quality

Skeletons should match final layout.

Good skeletons:

reserve height
match card density
avoid shifting final content
communicate structure
stay visually calm

Weak skeletons:

wrong height
too many animations
generic blocks unrelated to final UI
cause CLS
hide what is actually loading

Skeletons are layout tools, not decoration.

Error Boundaries

Streaming needs localized error strategy.

If recommendations fail, the article should still work.

If practice history fails, the practice console may still run.

Design failure boundaries around product value.

critical content failure: route-level error
secondary panel failure: localized retry
optional analytics failure: silent fallback

Perceived vs Actual Performance

Perceived performance is not fake performance.

It is about sequencing.

show stable structure early
prioritize primary task
avoid blocking on secondary work
keep controls responsive
explain progress where needed

The final total load time may not change, but the user gets value earlier.

Avoid Spinner Traps

Spinners can be acceptable for short waits.

For longer waits, they are vague.

Prefer:

skeleton structure
progressive content
specific pending labels
retry options
partial results

A spinner says "wait."

A good loading state says "here is what is happening."

Common Mistakes

Common mistakes include:

wrapping the whole page in one loading boundary
using skeletons that cause layout shifts
streaming secondary content before primary content
not pairing Suspense with error handling
over-fragmenting the page into many loading islands
loading client JavaScript for skeletons unnecessarily

The loading strategy should match the reading path.

Senior Trade-Offs

Streaming adds complexity.

Trade-offs:

faster first useful UI vs more boundary design
localized loading vs visual fragmentation
skeletons vs implementation effort
server streaming vs cache strategy
progressive data vs consistency concerns

Use it where independent sections exist.

Interview Framing

In an interview, say:

I use Suspense and streaming to reveal the stable shell and primary content early while slower secondary sections load behind localized boundaries. I keep skeletons layout-stable and pair boundaries with error recovery.

Revision Notes

• Streaming reveals UI progressively.
• Suspense boundaries define loading sections.
• Boundaries should match independently useful product areas.
• Skeletons must reserve stable space.
• Localized errors preserve the rest of the route.
• Perceived performance is about useful sequencing.

Follow-Up Questions

• Where would you place Suspense boundaries?
• How can skeletons hurt CLS?
• What is the difference between spinner and skeleton UX?
• Why pair Suspense with error boundaries?
• When is streaming not worth the complexity?

How I Would Answer This In A Real Interview

I would say streaming and Suspense are useful when the page has independent sections with different data speeds. I would render the stable shell and primary content first, put slower secondary panels behind Suspense, use skeletons that match final dimensions, and keep failures localized. I would verify that this improves useful progress without introducing layout shifts or visual fragmentation.