Streaming SSR or progressive rendering in use
Why it matters
A server that waits for all data fetches to complete before sending a single byte of HTML holds users on a blank screen. If your slowest API call takes 1.5 seconds, every user stares at white for at least that long — regardless of how fast your other data loads. Streaming SSR and Suspense boundaries let the browser start rendering and displaying content from the fast paths while slow paths are still in-flight. ISO 25010:2011 time-behaviour captures the wait; the user experience impact is measured in perceived load time, which drives engagement and retention.
Severity rationale
Medium because blocking SSR multiplies the latency of your slowest data dependency across every page load, but the fix (adding Suspense boundaries) is low-risk and scoped to server components.
Remediation
Wrap slow data-fetching server components in Suspense with a skeleton fallback. Next.js App Router streams each Suspense boundary independently — the shell HTML arrives immediately.
// app/dashboard/page.tsx
import { Suspense } from 'react'
import { ActivityFeedSkeleton } from '@/components/skeletons'
export default function DashboardPage() {
return (
<main>
<HeroStats /> {/* fast — no Suspense needed */}
<Suspense fallback={<ActivityFeedSkeleton />}>
<ActivityFeed /> {/* slow API — streams in separately */}
</Suspense>
</main>
)
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Deep Dive Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · time-behaviour — Time Behaviour (performance efficiency)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-deep-dive·automated