Part I of the series "Don't Let the User Wait - Render Quickly to Keep Their Attention."

The problem hiding inside SSR

Server-Side Rendering promises the world: fast first paint, SEO-friendly markup, no content flash. For simple pages, it delivers. But real product pages are rarely simple. They need authentication checks, user details and live data to name a few - a cascade of API calls that all have to resolve before the server can respond.

If the page only renders after all data are fetched, the server is just the new bottleneck and the user experience is hurt.

Lets consider the case of a chat based application. The page needs to check user authentication before calling for the user details and user chats. All three API calls - auth, user details, chats - must complete before a single pixel is painted. Meanwhile, the user only sees a white screen and their experience is indistinguishable from a slow client-side app, regardless of whether the work is happening on the server.

"We moved to SSR and our Lighthouse score went up, but users still complain it feels slow." - every other engineering team.

The fix: Render the shell, let components own their data

The key insight is that not all data is equally critical for the initial render. In the case depicted by the image above, auth is critical to determine what the user is shown - you need a valid session before you send anything. But userDetails and chats? Those are content. The page can exist without them, and they can load in after the shell is already painted.

This article explores this using React and Next.js. If you're working with a different stack, the same principle applies at the BFF layer - framework-agnostic and without any dependency on Server Components. That's covered in Part II - coming 27 May.

React Server Components and Suspense make this the natural way to build. The idea splits into two clear phases:

Phase 1 - Render the shell immediately.
The page render is only blocked for auth. Once the session is confirmed, the HTML shell - with navigation, layout and skeleton placeholders - is sent to the browser and rendered. The user sees something real and fast.

Phase 2 - Each component fetches its own data.
UserDetails and Chats are asynchronous Server Components wrapped in Suspense boundaries. They each independently fetch their own data on the server and render their resolved HTML into the page as they complete - no waiting for each other, no coordinating through a parent.

The user lands on a page that is already painted - navigation is visible, layout is in place, skeleton loaders hold the space where content will appear. Then UserDetails and Chats swap in, each one independently, as soon as its data is ready.

Suspense as the rendering contract

React Suspense is the mechanism that wires this process together. Each data-dependent section of the page is wrapped in a <Suspense> boundary with a skeleton fallback. React renders the skeleton immediately and replaces it with the resolved content the moment the component is ready to render.

// app/home/page.tsx (Next.js App Router)
import { Suspense } from 'react'
import { UserDetailsSkeleton, ChatsSkeleton } from './skeletons'

export default async function HomePage() {
  // Only auth blocks here — this is the only awaited call
  const session = await getSession()
  if (!session) return redirect('/login')

  return (
    <main>
      {/* Renders immediately — no data dependency */}
      <Header user={session} />

      {/* Skeleton shown instantly, swapped when data arrives */}
      <Suspense fallback={<UserDetailsSkeleton />}>
        <UserDetails userId={session.id} />
      </Suspense>

      {/* Resolves independently — doesn't wait for UserDetails */}
      <Suspense fallback={<ChatsSkeleton />}>
        <ChatList userId={session.id} />
      </Suspense>
    </main>
  )
}

Each Suspense boundary is independently resolvable. UserDetails can swap in before ChatList is ready and vice versa. The user sees a progressively enriched page rather than a binary flip from white screen to full content.

Each component owns its own fetch

The other half of the pattern is that each async Server Component fetches only what it needs, independently. There's no parent component collecting all the data and passing it down:

// components/UserDetails.tsx
async function UserDetails({ userId }: { userId: string }) {
  const details = await fetch(`/api/users/${userId}/details`)
    .then(r => r.json())

  return <ProfileCard {...details} />
}

// components/ChatList.tsx
async function ChatList({ userId }: { userId: string }) {
  const chats = await fetch(`/api/users/${userId}/chats`)
    .then(r => r.json())

  return <ChatFeed chats={chats} />
}

What React does under the hood:
renderToPipeableStream sends the HTML shell to the browser first. As each Suspense boundary resolves, React emits an inline script chunk over the same open connection. The browser swaps the skeleton for the real content without a full page reload or a separate network request.

Don't forget the error boundary

While Suspense handles the loading state, pair it with an ErrorBoundary to handle failure. This ensures that a broken API call degrades at the component level rather than crashing the whole page:

<ErrorBoundary fallback={<ChatsErrorCard />}>
  <Suspense fallback={<ChatsSkeleton />}>
    <ChatList userId={session.id} />
  </Suspense>
</ErrorBoundary>

Now if ChatList fails - network timeout, downstream 500, or anything else - the rest of the page is completely unaffected. Failed components can be retried either manually or automatically using exponential backoff strategy. Now the page has a significant improvement over the old SSR model where a single API failure would crash the entire render.

What this does to your metrics

When to apply this pattern

Your page has a mix of critical and non-critical data. The pattern shines when there's a clear hierarchy - shell first, primary content second, secondary content third.

Backend calls have variable latency. If auth is fast but recommendations or chat APIs are slow, don't hold up the whole page. Let the slow sections render independently.

You're on Next.js App Router. Pages Router with getServerSideProps doesn't support this model - all data fetching is centralised and blocking. App Router's async Server Components and loading.tsx files are designed precisely for this pattern.

Summary

The old SSR model treats the page as a single blocking unit - nothing goes to the browser until everything is ready. Server Components and Suspense treat the page as a composition of independently resolvable sections, each with its own data timeline.

Block render only on auth, and render the shell immediately. Let each component own its data and render its content when ready. Pair every Suspense with an ErrorBoundary so failures stay local and can be retried.

The result is a page that feels genuinely fast - not because you moved computation around, but because you changed when the user sees something.

Not on React or Next.js?
The same principle applies - but the fix lives in the BFF, not the frontend framework. Part II covers the framework-agnostic approach using HTTP streaming. Works with Vue, Svelte, Angular, or anything else.

Part II - Don't Wait for APIs. Send What You Have. → Coming 27 May.