Clerk Demo App

Slow RSC Blocking

This demo shows how Server Components that take a long time to render (2-3 seconds) create loading states but are isolated by Suspense boundaries. Notice how each RSC loads independently.

What to Watch For

• Each RSC has its own Suspense boundary with a loading fallback
• The auth check (2s delay) loads before the user data fetch (3s delay)
• The client-side component hydrates independently and immediately
• Server components render on the server and stream HTML to the client

Server-Side Auth Check (2s delay)

This Server Component uses auth() to check authentication status. Notice how it renders in its own Suspense boundary with a loading state.

Server component rendering (2s delay)...

Server-Side User Data Fetch (3s delay)

This Server Component uses currentUser() to fetch complete user data. Compare its timing and data with the client-side version below.

Server component rendering (3s delay)...

Client-Side User Data (Instant Hydration)

This client component uses useUser() to fetch the same user data. Compare: it shows identical data but hydrates almost instantly, independent of the slow RSCs above.

Client-Side User Data (useUser)

Client

Hydrated in 0ms

No user data available

This fetched the same data client-side and hydrated almost instantly, independent of the slow server component above!

Key Takeaways

Suspense boundaries isolate loading states for each RSC
Slow server components don't block the entire page from rendering
Users see loading states for slow parts while fast parts are already visible
Clerk's server functions like auth() and currentUser() can be used in async RSCs
Client-side hooks like useUser() fetch the same data client-side and hydrate independently without waiting for slow RSCs

← Back to Overview Next: Independent Hook Hydration →

Back to Partial Hydration

Slow RSC Blocking

This demo shows how Server Components that take a long time to render (2-3 seconds) create loading states but are isolated by Suspense boundaries. Notice how each RSC loads independently.

What to Watch For

• Each RSC has its own Suspense boundary with a loading fallback
• The auth check (2s delay) loads before the user data fetch (3s delay)
• The client-side component hydrates independently and immediately
• Server components render on the server and stream HTML to the client

Server-Side Auth Check (2s delay)

This Server Component uses auth() to check authentication status. Notice how it renders in its own Suspense boundary with a loading state.

Slow Server Component (RSC)

Server

Took 2014ms to render on server

Auth Status: Not authenticated

This RSC took 2000ms to complete. Notice how client components below hydrated independently!

Server component rendering (2s delay)...

Server-Side User Data Fetch (3s delay)

This Server Component uses currentUser() to fetch complete user data. Compare its timing and data with the client-side version below.

Slow User Data Fetch (RSC)

Server

Server fetch took 3003ms

No user data available

Even though this took 3000ms, client components using useAuth() and useSession() became interactive immediately!

Server component rendering (3s delay)...

Client-Side User Data (Instant Hydration)

This client component uses useUser() to fetch the same user data. Compare: it shows identical data but hydrates almost instantly, independent of the slow RSCs above.

Client-Side User Data (useUser)

Client

Hydrated in 0ms

No user data available

This fetched the same data client-side and hydrated almost instantly, independent of the slow server component above!

Key Takeaways

Suspense boundaries isolate loading states for each RSC
Slow server components don't block the entire page from rendering
Users see loading states for slow parts while fast parts are already visible
Clerk's server functions like auth() and currentUser() can be used in async RSCs
Client-side hooks like useUser() fetch the same data client-side and hydrate independently without waiting for slow RSCs

← Back to Overview Next: Independent Hook Hydration →