---
title: "08 — Loading, Streaming, and Error States — Handling the Slow and the Broken"
uid: loading-streaming-errors
tags: ["roadmap:nextjs", "streaming", "loading", "error-handling", "suspense", "nextjs"]
excerpt: "Three files handle the async and the broken: loading.tsx shows an instant placeholder, streaming sends HTML as it's ready, error.tsx catches the rest."
date: 2026-08-13T03:28:01+0000
source: https://www.aveshina.my.id/en/blog/loading-streaming-errors
---
"This takes time" and "this threw" are the two moments every route eventually hits, and the App Router ships three conventions for them. The model that clicked: **loading.tsx is the instant placeholder Suspense swaps in while a route segment loads; streaming sends HTML chunks to the browser as they're ready instead of waiting for the whole page; error.tsx is the boundary that catches what breaks** [1][2][3]. Together they're how the App Router handles "this takes time" and "this threw."
## loading.tsx — the instant placeholder
The special file loading.tsx creates a meaningful loading UI powered by React Suspense [1]. The behavior is the part worth internalizing: the moment a route segment starts loading, the server instantly sends the loading UI — *before* the slow work (a database query, a fetch) finishes. When the real content is ready, it's swapped in automatically.
```
// app/blog/[slug]/loading.tsx
export default function Loading() {
return ; // shown instantly while the page's data loads
}
```
The payoff is perceived performance. The user sees *something* immediately instead of staring at a blank screen while the server waits on a slow query. And because each route segment can have its own loading.tsx, the granularity is fine — a slow blog post doesn't block the rest of the layout from rendering.
## Streaming — HTML as it becomes ready
Streaming is the mechanism underneath. Instead of the server waiting for the entire page's data to resolve before sending anything, it sends HTML in chunks as each piece becomes available [1][4]. Suspense boundaries mark the seams: the server streams the static shell and the loading placeholders immediately, then fills in the dynamic content when it's ready.
The way of thinking that helped: think of the page as a tree of Suspense boundaries. Each boundary can resolve independently and stream its result when ready. The slow parts don't block the fast parts.
```
// wrapping a slow component in a Suspense boundary manually
import { Suspense } from 'react';
export default function Page() {
return (
<>
{/* static, renders immediately */}
Loading posts…}>
{/* streams in when ready */}
);
}
```
The roadmap is clear that this works on both Node.js and Edge runtimes — streaming isn't a Node-only feature in the App Router [1].
```figure
```
## error.tsx — the recovery boundary
Errors are the other thing every route has to handle, and the App Router splits them into two categories [2]:
- **Expected errors** — things that happen during normal operation, like a failed form submission or a validation error. These should be handled explicitly in the code and returned to the client gracefully.
- **Uncaught exceptions** — unexpected bugs that shouldn't occur in normal flow. These are caught by an **error boundary**, which is what error.tsx creates.
```
// app/blog/[slug]/error.tsx — must be a client component
'use client';
export default function Error({ error, reset }: { error: Error; reset: () => void }) {
return (
Something broke: {error.message}
);
}
```
The boundary isolates the failure: a thrown error in a route segment renders its error.tsx instead of crashing the whole page. The reset function lets the user attempt to re-render the segment. Crucially, error boundaries must be Client Components, because React's error-boundary mechanism relies on client-side state.
## How I use this
For any route that does async work, I add a loading.tsx so the user gets an instant placeholder instead of a blank screen — perceived performance is the whole game. For anything that can throw (and most code can), I add an error.tsx so a failure in one segment doesn't blank the whole page. And for slow sub-components inside a page, I wrap them in explicit boundaries so the fast parts render first. The pattern is: cover the async with loading, cover the broken with error, and let streaming do the rest.
## References
[1] Vercel, "Loading UI and streaming," Next.js Docs, 2024. [Online]. Available: [https://nextjs.org/docs/14/app/building-your-application/routing/loading-ui-and-streaming](https://nextjs.org/docs/14/app/building-your-application/routing/loading-ui-and-streaming)
[2] Vercel, "Error handling," Next.js Docs, 2024. [Online]. Available: [https://nextjs.org/docs/app/getting-started/error-handling#handling-expected-errors](https://nextjs.org/docs/app/getting-started/error-handling#handling-expected-errors)
[3] React, "Suspense," React Docs, 2024. [Online]. Available: [https://react.dev/reference/react/Suspense](https://react.dev/reference/react/Suspense)
[4] "Next.js 15 tutorial — Streaming," YouTube, 2024. [Video]. Available: [https://www.youtube.com/watch?v=oSf1gUDGJOA](https://www.youtube.com/watch?v=oSf1gUDGJOA)
[5] "Next.js 15 tutorial — Error handling," YouTube, 2024. [Video]. Available: [https://www.youtube.com/watch?v=fWV5WPSbgdg](https://www.youtube.com/watch?v=fWV5WPSbgdg)
```quiz
Q: What does a loading.tsx file create?
- A full-page spinner that blocks rendering
- An instant Suspense fallback shown while the route segment's content loads, swapped out when ready
correct: 1
explain: loading.tsx creates a Suspense-powered loading UI. The server sends it immediately, then swaps in the real content when the segment's data resolves.
Q: Streaming in the App Router means…
- the client streams keystrokes to the server
- the server sends HTML chunks as they become ready, instead of waiting for the whole page
correct: 1
explain: Streaming sends the static shell and placeholders first, then fills in dynamic content as each Suspense boundary resolves. Slow parts don't block fast parts.
Q: Error boundaries created by error.tsx must be…
- Server Components
- Client Components
correct: 1
explain: React's error-boundary mechanism relies on client-side state, so error.tsx files must use the 'use client' directive.
Q: The two categories of errors the App Router distinguishes are…
- recoverable and unrecoverable
- expected errors (handled explicitly) and uncaught exceptions (caught by error boundaries)
correct: 1
explain: Expected errors like failed validation are returned gracefully. Uncaught exceptions are caught by the error.tsx boundary, which isolates the failure to that segment.
```