feat: complete wikification of War Commander batch 1&2 and final grey dot cleanup
This commit is contained in:
+1
-1
@@ -20,7 +20,7 @@ Next.js를 활용한 하이브리드 렌더링은 단일 애플리케이션 내
|
||||
RSC를 사용한다고 해서 모든 성능 문제가 자동으로 해결되는 것은 아닙니다 [20]. 데이터 페칭 의존성이 순차적으로 구성되어 있다면, 브라우저에서 발생하던 워터폴(Waterfall) 현상이 서버에서 그대로 발생할 수 있습니다 [21, 22]. 따라서 데이터를 병렬로 페칭(Fetching)하도록 아키텍처를 설계해야 합니다 [23, 24]. 또한, `"use client"` 지시어를 남용하여 너무 많은 컴포넌트를 클라이언트로 전환하게 되면, 대규모 JavaScript 번들이 브라우저로 전송되어 RSC의 이점이 사라지므로 클라이언트 경계를 최소한으로 얕게 유지해야 합니다 [25, 26].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[Static Site Generation (SSG)]], [[Incremental Static Regeneration (ISR)]], [[Hydration]], [[React Flight 프로토콜]]
|
||||
- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[Static Site Generation (SSG)]], Incremental Static Regeneration (ISR), [[Hydration]], React Flight 프로토콜
|
||||
- **Projects/Contexts:** [[Next.js App Router]]
|
||||
- **Contradictions/Notes:** 소스에서는 React Server Components가 번들 크기를 줄이고 데이터 액세스를 개선하는 강력한 수단이지만 결코 '은탄환'은 아니라고 지적합니다. 잘못 구성될 경우 캐싱 복잡성을 더하거나 서버 측 워터폴(Server-side Waterfall)을 일으켜 성능 병목 지점만 클라이언트에서 서버로 옮기는 결과를 낳을 수 있으므로 철저한 설계가 필수적입니다 [20, 22, 27].
|
||||
|
||||
|
||||
Reference in New Issue
Block a user