## The Problem with Blocking Server Rendering Imagine you're building a dashboard. It has: ```text Header → 10ms Sidebar → 20ms Revenue Chart → 2 seconds User Table → 5 seconds ``` In a completely blocking rendering model, the server might wait for: ```text Header + Sidebar + Revenue Chart + User Table ``` before sending the completed page. So even though: ```text Header ``` was ready almost instantly... the user could still be staring at: ```text A beautiful blank screen ✨ ``` while the slowest part finishes. 😭 This is the problem **streaming** helps solve. --- # Enter React Suspense and Streaming The [Next.js App Router](/courses/nextjs) integrates deeply with: ```jsx ``` from [React](/courses/reactjs). Instead of thinking: ```text Render entire page ↓ Wait for everything ↓ Send everything ``` you can think: ```text Render what is ready ↓ Send it ↓ Show fallbacks for slow sections ↓ Stream remaining sections later ``` This lets users start seeing useful UI without waiting for every data request on the page. --- > **Definition: Streaming** > > Streaming is a rendering technique where the server sends the page to the browser progressively in smaller chunks instead of waiting for the entire route to finish rendering before sending the response. --- # Traditional Blocking Mental Model Without streaming: ```text Request ↓ Fetch Header Data ↓ Fetch Revenue ↓ Fetch Users ↓ Render Everything ↓ Send HTML ``` If the final request takes: ```text 5 seconds ``` the whole page may be delayed. --- # Streaming Mental Model With Suspense boundaries: ```text Request ↓ Render Page Shell ↓ Revenue not ready ↓ Show Revenue Skeleton ↓ Users not ready ↓ Show User Skeleton ↓ Send available UI ``` Then: ```text 2 seconds later ↓ Revenue ready ↓ Stream Revenue Chart ``` Then: ```text 5 seconds later ↓ Users ready ↓ Stream User Table ``` The page progressively becomes complete. Much better than making the fastest component wait for the slowest one. --- # What Is React Suspense? [React](/courses/reactjs) Suspense lets you define what should appear while part of the UI isn't ready. The basic syntax is: ```jsx import { Suspense } from "react" Loading...

} > ``` Think: ```text Is SlowComponent ready? │ ├── Yes │ ↓ │ Show component │ └── No ↓ Show fallback ``` When the component becomes ready, React replaces the fallback with the real content. --- > **Definition: Suspense Boundary** > > A `` component creates a boundary around UI that may not be ready yet. React can temporarily show its `fallback` while waiting for the wrapped content. --- # Suspense + Server Components Suspense becomes especially powerful with [async](/javascript/promises-asynchronous-javascript) [Server Components](/courses/nextjs). For example: ```jsx async function RevenueChart() { const revenue = await getRevenue() return (

Revenue: ${revenue.total}

) } ``` Now: ```text RevenueChart ``` may suspend while: ```js getRevenue() ``` is waiting. Wrap it: ```jsx } > ``` Now the [rest](/courses/expressjs) of the page doesn't necessarily need to wait for RevenueChart to finish before useful UI can be sent. --- # 1. Route-Level Streaming with `loading.jsx` [Next.js](/courses/nextjs) gives you an extremely convenient special file: ```text loading.jsx ``` or: ```text loading.tsx ``` Suppose your route looks like: ```text src/app/ └── dashboard/ ├── loading.jsx └── page.jsx ``` [Next.js](/courses/nextjs) automatically uses: ```text loading.jsx ``` as fallback UI while the route content is loading. --- # Basic `loading.jsx` ```jsx // src/app/dashboard/loading.jsx export default function Loading() { return (

Loading dashboard...

) } ``` Then: ```jsx // src/app/dashboard/page.jsx export default async function DashboardPage() { await new Promise( resolve => setTimeout( resolve, 3000 ) ) return (

Dashboard Loaded!

) } ``` When the user navigates to: ```text /dashboard ``` they can immediately see: ```text Loading dashboard... ``` instead of waiting three seconds with no feedback. --- # What Next.js Does for You Conceptually, Next.js creates something similar to: ```jsx } > ``` You don't need to manually add that route-level boundary. The: ```text loading.jsx ``` file handles it. --- # Skeleton Loaders Plain: ```text Loading... ``` works. But skeleton loaders often create a better visual experience. Example: ```jsx export default function DashboardLoading() { return (

) } ``` The user sees the approximate page structure before the real data arrives. Conceptually: ```text ████████ ████████████████████ ████████████████████ ↓ Real Dashboard ``` This makes loading feel less jarring. --- # Shared Layouts Can Stay Visible Suppose your structure is: ```text app/ ├── layout.jsx │ └── dashboard/ ├── layout.jsx ├── loading.jsx └── page.jsx ``` Your dashboard layout might contain: ```text Sidebar Navigation Header ``` while: ```text page.jsx ``` contains the slow data. When navigating, the shared layout can remain visible while the page section shows: ```text loading.jsx ``` Conceptually: ```text Sidebar ✅ Ready Navigation ✅ Ready Header ✅ Ready Main Content └── Skeleton ⏳ Loading ``` This is much better UX than replacing the entire application with a giant spinner. --- # Interruptible Navigation Another benefit of route-level loading UI is that navigation remains **interruptible**. Imagine the user clicks: ```text /dashboard ``` and the dashboard begins loading. Then they immediately change their mind and click: ```text /settings ``` They don't necessarily need to wait for the dashboard request to finish first. Next.js can begin navigating to the new destination. Conceptually: ```text Click Dashboard ↓ Dashboard loading... ↓ User clicks Settings ↓ Cancel/leave previous navigation ↓ Navigate to Settings ``` The app feels much more responsive. --- # Important: `loading.jsx` Applies to Nested Routes Suppose: ```text dashboard/ ├── loading.jsx ├── page.jsx ├── users/ │ └── page.jsx └── settings/ └── page.jsx ``` The loading boundary can affect routes beneath that segment too. So: ```text /dashboard /dashboard/users /dashboard/settings ``` may share that loading behavior. Sometimes that's exactly what you want. Sometimes it isn't. --- # Limiting Loading UI with Route Groups Suppose you only want the loading skeleton for: ```text /dashboard ``` but not every dashboard child route. You can use a Route Group. Example: ```text dashboard/ ├── layout.jsx │ ├── (overview)/ │ ├── loading.jsx │ └── page.jsx │ ├── users/ │ └── page.jsx │ └── settings/ └── page.jsx ``` Remember: ```text (overview) ``` doesn't appear in the URL. So: ```text dashboard/(overview)/page.jsx ``` still maps to: ```text /dashboard ``` but its loading boundary can stay scoped to that group. Very useful. --- # 2. Granular Streaming with `` `loading.jsx` is great when the **whole route section** should show fallback UI. But sometimes your page contains several independent pieces. Example: ```text Analytics Dashboard Revenue Chart → 2 seconds Recent Orders → 1 second User Table → 5 seconds ``` You probably don't want: ```text User Table = slow ↓ Everything waits ``` Instead, create multiple Suspense boundaries. --- # Example ```jsx import { Suspense } from "react" import RevenueChart from "./RevenueChart" import UserTable from "./UserTable" import RecentOrders from "./RecentOrders" export default function AnalyticsPage() { return (

Analytics Dashboard

Loading revenue...

} > Loading orders...

} > Loading users...

} >

) } ``` Each section can become available independently. --- # Visual Timeline Imagine: ```text 0 seconds Analytics Dashboard ├── Revenue Skeleton ├── Orders Skeleton └── Users Skeleton ``` Then: ```text 1 second Analytics Dashboard ├── Revenue Skeleton ├── Recent Orders ✅ └── Users Skeleton ``` Then: ```text 2 seconds Analytics Dashboard ├── Revenue Chart ✅ ├── Recent Orders ✅ └── Users Skeleton ``` Then: ```text 5 seconds Analytics Dashboard ├── Revenue Chart ✅ ├── Recent Orders ✅ └── User Table ✅ ``` The user progressively receives useful content. 🔥 --- # Fetch Data Inside the Suspended Component This pattern becomes especially useful when the data fetching lives close to the component that needs it. For example: ```jsx export default async function RevenueChart() { const revenue = await getRevenue() return (

Revenue

${revenue.total}

) } ``` Then: ```jsx } > ``` Now: ```text Revenue data ``` belongs to: ```text RevenueChart ``` rather than forcing the page to fetch everything first. --- # Bad Streaming Structure Imagine: ```jsx export default async function Page() { const revenue = await getRevenue() const users = await getUsers() return ( <> ) } ``` Even if you later wrap: ```jsx ``` and: ```jsx ``` inside Suspense, the data has already been awaited **above those boundaries**. The page cannot stream those components independently because the page itself is waiting first. --- # Better Structure Move the requests downward: ```jsx export default function Page() { return ( <> } > } > ) } ``` Then: ```jsx async function RevenueChart() { const revenue = await getRevenue() return (

...

) } ``` and: ```jsx async function UserTable() { const users = await getUsers() return (

...

) } ``` Now each section can suspend independently. --- # Suspense Does NOT Automatically Remove Data Waterfalls This is an important correction. You may hear: > "Just wrap everything in Suspense and waterfalls disappear." Nope. 😄 Suspense controls: ```text HOW UI waits and appears ``` It does not automatically make sequential data requests parallel. --- # Example of a Waterfall ```js const user = await getUser() const posts = await getPosts() const comments = await getComments() ``` This still means: ```text User ↓ Posts ↓ Comments ``` if each request waits for the previous one. Adding a Suspense boundary somewhere doesn't magically rewrite these operations. --- # Parallel Fetching If requests are independent, use: ```js Promise.all() ``` Example: ```js const [ user, posts, comments ] = await Promise.all([ getUser(), getPosts(), getComments() ]) ``` Now they can run at roughly the same time. --- # Parallel Fetching vs Streaming These solve **different problems**. ### Parallel Fetching Answers: > "Can these requests happen at the same time?" Use: ```js Promise.all() ``` --- ### Streaming Answers: > "Can useful UI appear before every component is ready?" Use: ```jsx ``` --- # Mental Model ```text PARALLEL FETCHING = Make data finish sooner ``` ```text STREAMING = Show ready UI sooner ``` You can absolutely use both. In fact, good applications often do. --- > **Interview Highlight** > > **Q: Does Suspense automatically prevent data-fetching waterfalls?** > > No. Suspense controls how unresolved UI is revealed and streamed. Independent requests still need to be structured to run in parallel when appropriate, for example with `Promise.all()` or by starting requests before awaiting them. --- # 3. Grouping Components Inside Suspense You don't always want every tiny component appearing independently. Imagine four dashboard cards: ```text Revenue Customers Orders Conversion ``` If they appear: ```text Revenue ✅ Customers ⏳ Orders ✅ Conversion ⏳ ``` then one second later: ```text Revenue ✅ Customers ✅ Orders ✅ Conversion ⏳ ``` then again: ```text Revenue ✅ Customers ✅ Orders ✅ Conversion ✅ ``` the UI may feel like it's playing Tetris. 😭 Sometimes it's better to reveal related elements together. --- # Grouped Suspense Boundary ```jsx } > ``` Then: ```jsx async function DashboardCards() { const data = await getDashboardCards() return (

) } ``` Now the cards appear together. This can feel visually cleaner. --- # Where Should You Put Suspense Boundaries? There isn't one universal answer. Ask: ```text What should the user see first? ``` Then: ```text Which sections depend on slow data? ``` Then: ```text Which components should appear together? ``` For example: ```text Page Title Navigation ``` may appear immediately. Then: ```text Statistics Cards ``` can appear together. Then: ```text Large Analytics Chart ``` can stream separately. Then: ```text Activity Table ``` can stream separately. --- # Too Few Suspense Boundaries If your entire page is one giant boundary: ```jsx } > ``` then one slow child could keep the whole dashboard inside the fallback. You lose some of the benefits of granular streaming. --- # Too Many Suspense Boundaries But this isn't necessarily better: ```text Boundary Boundary Boundary Boundary Boundary Boundary Boundary Boundary Boundary ``` around every tiny component. Your page may pop into existence piece by piece in a visually chaotic way. So don't think: ```text More Suspense = More performance ``` The goal is a good **loading experience**. --- # Good Boundary Placement A useful approach is: ```text Group related content + Separate genuinely slow sections ``` For example: ```text Dashboard │ ├── Header │ ├── │ └── Summary Cards │ ├── │ └── Revenue Chart │ └── └── User Table ``` That's usually easier for users to understand visually. --- # 4. Streaming Server Rendering Let's look under the hood. Without streaming, the server might conceptually generate one big [HTML](/courses/html) response: ```text everything... ``` and wait until it's complete. With streaming, the response can arrive progressively. Conceptually: ```text Chunk 1 ↓ Dashboard Revenue Skeleton Users Skeleton ``` Then: ```text Chunk 2 ↓ Revenue content ``` Then: ```text Chunk 3 ↓ User content ``` React and Next.js coordinate the replacement of the Suspense fallbacks with the completed content. --- > **Definition: Streaming SSR** > > Streaming Server Rendering sends server-rendered UI progressively as chunks become ready instead of waiting for the entire React tree to complete before delivering useful output. --- # Streaming Is Not Client-Side Fetching This distinction matters. Streaming: ```text Server ↓ Renders UI ↓ Sends chunks ↓ Browser ``` is different from: ```text Browser ↓ Initial page loads ↓ useEffect() ↓ fetch() ↓ Receive JSON ↓ Render data ``` With streaming, the server is still doing the rendering work. The browser progressively receives the result. --- # Server Components + Streaming This is one reason [Server Components](/courses/nextjs) and Suspense fit together so well. You can have: ```jsx async function UserTable() { const users = await db.user.findMany() return ( ...

) } ``` The database remains: ```text Server-side ``` while Suspense controls what the user sees while that server work completes. You don't need to move the database query into the browser just to get a loading state. --- # 5. Time to First Byte (TTFB) You'll often hear streaming discussed with: **TTFB — Time to First Byte** TTFB measures how long it takes from requesting a resource until the browser receives the first byte of the response. Conceptually: ```text Request sent ↓ Server processing ↓ First response byte arrives ↓ TTFB ``` --- # Can Suspense Improve TTFB? Streaming can allow a server to begin sending the available shell before slower sections finish. So compared with fully blocking rendering: ```text Wait 5 seconds ↓ Send first byte ``` a streaming architecture may be able to do: ```text Prepare shell ↓ Start response ↓ Continue slow rendering ``` which can improve when useful response bytes begin arriving. But don't memorize: > "Suspense always dramatically improves TTFB." Actual TTFB depends on many factors: - Hosting infrastructure - Network latency - Server startup - Proxy/CDN buffering - Database work required before the shell - Caching - Rendering architecture Streaming's biggest guaranteed architectural benefit is: > **Slow sections don't necessarily have to block ready sections from being delivered.** --- > **Interview Highlight** > > **Q: How can Suspense and streaming affect TTFB?** > > Suspense boundaries can allow the server to begin streaming ready parts of the response before slower sections finish, potentially improving the time until useful response bytes arrive. However, actual TTFB still depends on server, network, caching, and infrastructure behavior. --- # TTFB vs LCP Don't confuse: ```text TTFB ``` with: ```text LCP ``` TTFB asks: ```text How quickly did the response begin? ``` LCP asks: ```text How quickly did the largest important visible element appear? ``` Streaming may help users see content sooner, but good performance still requires: - Fast data access - Good caching - Optimized images - Efficient [JavaScript](/courses/javascript) - Good Suspense boundaries - Smart loading priorities One performance technique doesn't magically defeat physics. 😄 --- # Streaming and SEO You might wonder: > "If some content arrives later, can search engines still understand it?" Streaming happens as part of server rendering. Next.js and React send server-rendered content progressively rather than turning the entire page into client-only rendering. So streaming itself doesn't mean: ```text SEO is gone ``` The architecture is still server-rendered. Of course, your actual SEO still depends on: - Crawlable content - Metadata - Semantic [HTML](/courses/html) - Performance - Content quality --- # 6. Suspense with Modern Cache Components Modern Next.js can also combine Suspense with the Cache Components architecture. Imagine: ```text Header Product Details User Cart ``` The first two may be reusable. The cart depends on: ```text cookies() ``` and therefore needs the current request. You could isolate it: ```jsx import { Suspense } from "react" export default function ProductPage() { return ( <> } > ) } ``` Conceptually: ```text Reusable page shell ↓ Prepared ahead of time User Cart ↓ Request-time ↓ Streamed later ``` This is part of the modern **Partial Prerendering** mental model we learned earlier. --- # Static + Cached + Streamed One route can now conceptually contain: ```text Navbar ↓ STATIC Article ↓ CACHED Comments ↓ REVALIDATED User Controls ↓ REQUEST-TIME + STREAMED ``` Suspense is one of the key tools that makes this architecture possible. --- # 7. `loading.jsx` vs Manual Suspense When should you use each? --- ## Use `loading.jsx` When: You want: ```text Route-level loading UI ``` Example: ```text /dashboard ``` should display a full dashboard skeleton while its page is loading. Structure: ```text dashboard/ ├── loading.jsx └── page.jsx ``` Simple. --- ## Use `` When: You need granular control. Example: ```text Dashboard title ↓ Show immediately Revenue chart ↓ Separate skeleton User table ↓ Separate skeleton ``` Then: ```jsx ``` is better. --- # You Can Use Both They aren't mutually exclusive. You might have: ```text dashboard/ ├── loading.jsx └── page.jsx ``` while: ```text page.jsx ``` also contains several component-level Suspense boundaries. For example: ```jsx export default function Dashboard() { return ( <>

Dashboard

} > } > ) } ``` Route-level and component-level streaming can work together. --- # 8. Loading Skeleton Design Matters Streaming can technically work perfectly while your UX still looks terrible. Suppose: ```text Real component height = 500px ``` but your fallback is: ```text 20px spinner ``` When real content arrives: ```text Page suddenly expands 480px ``` Now your layout jumps. Not great. --- # Better Skeleton Try to make the fallback approximately match the final UI. Example: ```jsx function ChartSkeleton() { return (

) } ``` If the actual chart also uses roughly: ```text 400px ``` of height, the transition feels much smoother. --- # Skeleton Mental Model Bad: ```text Loading... ``` then suddenly: ```text ████████████████████████████ ████████████████████████████ ████████████████████████████ ``` Better: ```text ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ``` then: ```text ████ REAL CONTENT ███████████ ████ REAL CONTENT ███████████ ``` Less jumping. Better perceived performance. --- # 9. A Complete Dashboard Example Let's put everything together. --- ## `page.jsx` ```jsx import { Suspense } from "react" import RevenueChart from "./RevenueChart" import UserTable from "./UserTable" import { RevenueSkeleton, UsersSkeleton } from "./Skeletons" export default function DashboardPage() { return (

Analytics Dashboard

Welcome back!

} > } >

) } ``` --- ## `RevenueChart.jsx` ```jsx export default async function RevenueChart() { const revenue = await getRevenue() return (

Revenue

${revenue.total}

) } ``` --- ## `UserTable.jsx` ```jsx export default async function UserTable() { const users = await getUsers() return ( {users.map(user => ( ))}

{user.name}

) } ``` Now: ```text Dashboard heading ``` can appear without waiting for: ```text Revenue ``` or: ```text Users ``` And those two sections can become ready independently. --- # Common Mistake: Fetching Everything at the Top Bad: ```jsx export default async function Page() { const revenue = await getRevenue() const users = await getUsers() return ( ) } ``` If: ```text getUsers() ``` takes five seconds, the page itself waits. Move slow independent work toward the components that need it when granular streaming makes sense. --- # Common Mistake: Thinking Suspense Makes Queries Faster Suspense does not make: ```text 5-second database query ``` become: ```text 500ms database query ``` The query is still slow. Suspense simply means other ready UI may not need to wait for it. You should still optimize: - Queries - Indexes - Caching - Database location - API performance Streaming hides latency better. It does not delete latency. --- # Common Mistake: Thinking Suspense Automatically Parallelizes Data Remember: ```text Streaming ≠ Parallel fetching ``` If this is sequential: ```js await A() await B() await C() ``` it's still sequential. Use parallel fetching where appropriate. --- # Common Mistake: One Giant Loading Spinner This: ```text Entire Dashboard ↓ Huge Spinner ``` throws away much of the benefit of streaming if lots of useful UI could already be shown. Consider smaller meaningful sections. --- # Common Mistake: 50 Tiny Boundaries The opposite extreme is also messy. If every: ```text Icon Label Button Number Avatar ``` has its own fallback, your page can become visually chaotic. Suspense boundaries should reflect meaningful UI groups. --- # Common Mistake: Skeleton Doesn't Match Content If your skeleton is tiny but the final content is huge, the page can jump when content arrives. Design fallbacks with approximately the same dimensions as the content they replace. --- # Common Mistake: Slow Work Above the Boundary This: ```jsx const data = await slowRequest() return ( ) ``` doesn't help much because: ```text slowRequest() ``` already finished before React reaches the Suspense boundary. Move the suspendable work **inside** the boundary when appropriate. --- # Quick Reference | Need | Tool | |---|---| | Route-level loading state | `loading.jsx` | | Granular loading state | `` | | Loading placeholder | `fallback` | | Several independent requests faster | `Promise.all()` | | Progressive server rendering | Streaming | | Keep related sections together | One shared Suspense boundary | | Let sections appear independently | Separate Suspense boundaries | | Request-time content inside static shell | Suspense + modern rendering | | Better perceived loading | Skeleton UI | --- # Streaming vs Parallel Fetching | Feature | Streaming | Parallel Fetching | |---|---|---| | Main Goal | Show UI progressively | Reduce total data wait time | | Main Tool | `` | `Promise.all()` | | Makes slow query faster? | ❌ | Potentially reduces overall waiting | | Shows ready UI early? | ✅ | Not automatically | | Prevents sequential waterfalls? | ❌ | ✅ When requests are independent | | Can be combined? | ✅ Absolutely | ✅ Absolutely | --- # `loading.jsx` vs `` | Feature | `loading.jsx` | `` | |---|---|---| | Setup | File convention | React component | | Scope | Route segment | Any wrapped UI | | Automatic boundary | ✅ | Manual | | Granular control | Limited | ✅ High | | Good for whole-page skeleton | ✅ | Possible | | Good for independent widgets | ❌ Less ideal | ✅ | | Supports streaming | ✅ | ✅ | --- # Interview Quick Hits > **Q: What is streaming in Next.js?** > > Streaming allows the server to progressively send rendered UI to the browser as different parts become ready instead of waiting for the entire route to finish. --- > **Q: What does `loading.jsx` do?** > > It defines instant fallback UI for a route segment. Next.js uses it with React Suspense so the fallback can be shown while the route content loads. --- > **Q: What is a Suspense boundary?** > > A `` boundary wraps UI that may not be ready yet and displays a fallback until the wrapped content can be revealed. --- > **Q: Does Suspense make slow database queries faster?** > > No. It prevents slow UI from necessarily blocking ready UI. The underlying query still needs normal performance optimization. --- > **Q: Does Suspense eliminate data waterfalls?** > > No. Suspense controls rendering and reveal behavior. Independent requests still need to be parallelized when appropriate. --- > **Q: What is the difference between `loading.jsx` and manual ``?** > > `loading.jsx` provides route-level fallback UI automatically, while manual Suspense boundaries give you finer component-level control. --- > **Q: Can shared layouts remain visible while a route loads?** > > Yes. Shared layouts can remain interactive while the changing route segment displays its loading fallback. --- > **Q: What is interruptible navigation?** > > It means the user can navigate somewhere else before the currently loading route finishes instead of being forced to wait for it. --- > **Q: Can streaming improve TTFB?** > > It can allow ready parts of the response to start arriving before slower sections complete, potentially improving when useful response bytes arrive. Actual TTFB still depends on server, caching, network, and hosting behavior. --- # The Mental Model Without streaming: ```text FAST COMPONENT ↓ Wait FAST COMPONENT ↓ Wait SLOW COMPONENT ↓ Finally ready EVERYTHING ↓ User ``` With streaming: ```text FAST CONTENT ↓ User SLOW CONTENT ↓ Skeleton SLOW CONTENT READY ↓ Stream it in ``` Then remember: ```text Suspense = "How should the UI wait?" ``` while: ```text Promise.all() = "How should independent data requests run?" ``` Those two ideas solve different layers of the problem. --- ## Summary React Suspense and Next.js streaming let you progressively deliver server-rendered UI instead of forcing useful content to wait for the slowest part of a page. The key ideas are: - Streaming breaks server-rendered output into progressive chunks - `` displays fallback UI while wrapped content isn't ready - `loading.jsx` creates route-level loading behavior automatically - Shared layouts can remain visible and interactive while child content loads - Navigation with loading UI can be interruptible - `loading.jsx` applies to its route segment and nested content - Route Groups can help scope loading behavior - Manual `` gives you granular component-level streaming - Fetching data inside the suspended component can enable better streaming boundaries - Related components can be grouped under one Suspense boundary - Too many boundaries can create visually distracting UI - Too few boundaries can make unrelated content wait unnecessarily - Skeletons should roughly match the final content's dimensions - Suspense does **not** make slow queries faster - Suspense does **not** automatically remove data waterfalls - `Promise.all()` is useful for parallelizing independent requests - Parallel fetching and streaming solve different problems - Streaming can allow useful response content to arrive before slower sections finish - Suspense also works with modern Cache Components and Partial Prerendering - Static, cached, and request-time streamed content can coexist in the same route The biggest mental model is: ```text Parallel Fetching = Finish independent work sooner Streaming = Show finished work sooner ``` Once you understand that difference, Suspense stops looking like a fancy loading spinner and starts making architectural sense. And that's how we'll keep learning Next.js on **asif.to** — not by wrapping every component in `` and hoping performance magically appears 😭, but by understanding where users are actually waiting, which requests can run together, and which parts of the page deserve to appear first. Good streaming isn't about more skeletons. It's about making the application feel useful as early as possible. 🚀