Loading UI, Streaming and Suspense

When a Server Component awaits slow data, the user would otherwise stare at a blank screen until everything resolves. The App Router solves this with streaming: it sends the parts of the page that are ready immediately and streams in the slower parts as they finish, showing fallback UI in the meantime. You opt into this with a loading.js file or React Suspense boundaries. This exists because perceived performance matters as much as actual performance — a page that shows its shell and a spinner in two hundred milliseconds feels far faster than one that shows nothing for two seconds even if both finish at the same time. Understanding loading UI, streaming, and Suspense is what lets you turn unavoidable data latency into a smooth progressive reveal instead of a frozen wait.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.