chore: Delete processed raw file (Code Splitting)
This commit is contained in:
Antigravity Agent
@@ -1,36 +0,0 @@
|
||||
# [[코드 스플리팅 및 성능 최적화(Code Splitting & Performance Optimization)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 스플리팅은 거대한 JavaScript 번들을 작은 청크(Chunk)로 나누어 사용자가 필요로 할 때만 로드하게 함으로써 초기 페이지 로드 시간을 획기적으로 단축하는 기술입니다 [1-3]. 성능 최적화는 코드 스플리팅뿐만 아니라 불필요한 리렌더링 방지, 동시성 렌더링, 리소스 우선순위 지정, 이미지 지연 로딩 등을 결합하여 애플리케이션의 반응성과 런타임 속도를 향상시키는 과정입니다 [4, 5]. 이를 통해 프론트엔드 애플리케이션은 LCP(Largest Contentful Paint), INP(Interaction to Next Paint)와 같은 Core Web Vitals 지표를 개선하고 원활한 사용자 경험을 제공할 수 있습니다 [1, 6, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
* **코드 스플리팅 및 지연 로딩 (Code Splitting & Lazy Loading)**
|
||||
* **개념 및 효과:** 대규모 JavaScript 번들은 브라우저의 파싱 및 컴파일 시간을 지연시켜 TTI(Time to Interactive) 및 FCP 등의 지표를 악화시킵니다 [3, 8]. 코드 스플리팅을 사용하면 초기 로드에 필요한 번들 크기를 줄여 성능을 크게 높일 수 있습니다 [2].
|
||||
* **구현 기법:** React에서는 `React.lazy()`와 `<Suspense>`를 사용하여 라우트 레벨이나 무거운 UI 컴포넌트(차트, 에디터 등) 단위로 동적 임포트(Dynamic Imports)를 구현합니다 [9-11].
|
||||
* **번들 분할 (Chunking):** Vite와 같은 현대적인 빌드 도구에서는 `manualChunks` 설정을 통해 React 코어처럼 자주 변경되지 않는 무거운 벤더 라이브러리를 별도의 파일로 분리하여 브라우저 캐싱 효율을 극대화합니다 [11-13].
|
||||
|
||||
* **리렌더링 및 런타임 최적화 (Re-render & Runtime Optimization)**
|
||||
* **메모이제이션:** 컴포넌트의 불필요한 리렌더링을 방지하기 위해 `React.memo()`, `useCallback`, `useMemo`를 전략적으로 사용합니다 [14-16]. 인라인 익명 함수나 객체는 렌더링 시마다 새로운 참조를 생성하므로 메모이제이션된 컴포넌트라도 리렌더링을 유발할 수 있어 주의가 필요합니다 [17-19].
|
||||
* **React Compiler:** React 19 이상을 지원하는 React Compiler를 도입하면 빌드 타임에 자동으로 상태와 UI 요소를 세분화하여 메모이제이션하므로, 수동 최적화에 따른 복잡도와 오류를 줄일 수 있습니다 [12, 20-22].
|
||||
* **리스트 가상화 (Virtualization):** 수천 개의 항목을 포함하는 대규모 리스트를 렌더링할 때는 `react-window` 같은 라이브러리를 사용하여 화면에 보이는 항목(Viewport)만 렌더링함으로써 DOM 비대화를 막고 메인 스레드의 응답성을 유지합니다 [1, 23-25].
|
||||
* **디바운스 및 쓰로틀링:** 검색 입력 등 빈번한 이벤트에 대해 디바운싱(Debounce)과 쓰로틀링(Throttle)을 적용하여 무거운 연산이나 API 호출 횟수를 제한합니다 [23, 26].
|
||||
|
||||
* **상태 관리 및 동시성 제어 (State Management & Concurrency)**
|
||||
* **Context API 한계 극복:** React Context API는 내부의 값이 하나라도 변경되면 해당 컨텍스트를 구독하는 모든 컴포넌트를 리렌더링시킵니다 [27-29]. 빈번하게 업데이트되는 전역 상태의 경우, Context의 도메인을 잘게 쪼개거나, Zustand 등 특정 상태 슬라이스(Slice)만 구독할 수 있는 라이브러리를 사용하는 것이 성능상 훨씬 유리합니다 [30-32].
|
||||
* **동시성 렌더링 (Concurrent Features):** `useTransition`을 사용해 무거운 UI 업데이트의 우선순위를 낮추고, `useDeferredValue`로 무거운 연산을 지연시킴으로써 사용자의 입력과 같은 중요 인터랙션이 차단되지 않도록 합니다 [33-35].
|
||||
* **Server Components:** Next.js의 React Server Components(RSC)를 활용하면, 인터랙션이 없는 정적 UI를 서버에서 렌더링하고 클라이언트로 전송되는 JavaScript 양을 대폭 줄일 수 있습니다 [36-38].
|
||||
|
||||
* **네트워크 및 리소스 최적화 (Network & Resource Optimization)**
|
||||
* **크리티컬 렌더링 패스:** CSS와 같은 렌더링 차단 리소스를 최소화하고, `async`와 `defer`를 활용해 자바스크립트 실행 시점을 제어합니다 [4].
|
||||
* **이미지 및 리소스 우선순위:** WebP, AVIF 등 최신 이미지 포맷을 사용하며, 화면 아래의 이미지는 `loading="lazy"` 속성으로 지연 로드합니다. 화면 상단의 핵심 이미지는 `fetchpriority` 속성이나 `preload`, `preconnect` 등의 리소스 힌트를 활용해 빠르게 로드합니다 [39-41].
|
||||
|
||||
* **측정 및 모니터링 (Measurement & Monitoring)**
|
||||
* 성능 최적화는 추측이 아닌 데이터에 기반해야 합니다. "측정하지 않은 것은 최적화하지 마라"는 원칙에 따라 React DevTools Profiler, why-did-you-render, Chrome 개발자 도구 성능 탭 등을 활용해 렌더링 병목을 프로파일링해야 합니다 [26, 42-44].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[메모이제이션(Memoization)]], [[가상화(Virtualization)]], [[동시성 렌더링(Concurrent Rendering)]], [[Core Web Vitals]]
|
||||
- **Projects/Contexts:** [[대규모 React 애플리케이션 아키텍처]], [[Vite 및 Next.js 기반 성능 튜닝 환경]]
|
||||
- **Contradictions/Notes:** 여러 소스에서 `React.memo`, `useMemo`, `useCallback`과 같은 수동 최적화 도구의 남용을 경고합니다. 이러한 도구는 비교 연산에 비용이 들기 때문에, 렌더링 비용이 가볍거나 prop이 자주 변경되는 컴포넌트에 사용하면 오히려 성능 저하를 초래할 수 있으므로 반드시 측정 후에 적용해야 합니다 [45, 46]. 또한, React Context API는 도입이 쉽지만 전역 상태 관리에 무분별하게 사용할 경우 심각한 리렌더링 폭풍(Re-render storm)을 일으키므로, 동적인 상태에는 Zustand와 같은 도구가 더 적합하다고 강조합니다 [28, 29, 47].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: FE-PERF-CODE-SPLIT-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [performance, code-splitting, optimization, lazy-loading, suspense, bundling, vite, nextjs, core-web-vitals]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Code Splitting and Frontend Performance Optimization (코드 스플리팅과 성능 최적화)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "한꺼번에 전송되는 거대한 자바스크립트 번들은 사용자의 기다림을 고통으로 바꾼다. 번들을 의미 있는 조각(Chunks)으로 나누고 필요할 때만 호출(On-demand)하여, 첫 화면의 주인공을 0.1초라도 빨리 무대에 올려라" — 초기 로딩 속도와 런타임 반응성을 극대화하는 핵심 전략.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Granular Bundling and Adaptive Resource Loading" — 애플리케이션 코드를 라우트, 컴포넌트, 라이브러리 단위로 세분화하고 브라우저의 렌더링 스케줄에 맞춰 로딩 우선순위를 조정하는 패턴.
|
||||
- **핵심 최적화 기법:**
|
||||
- **Route-based Splitting:** 사용자가 현재 보지 않는 페이지의 코드를 로드하지 않도록 라우터 수준에서 지연 로딩(`React.lazy`) 적용.
|
||||
- **Component-level Lazy Loading:** 무거운 서드파티 라이브러리(차트, 에디터)나 특정 상호작용 후에만 필요한 UI 요소를 별도 청크로 분리.
|
||||
- **Vendor Splitting (Manual Chunks):** 자주 변경되는 비즈니스 로직과 변경이 적은 외부 라이브러리(`react`, `react-dom`)를 분리하여 브라우저 캐싱 효율 극대화.
|
||||
- **Resource Prioritization:** `preload`, `prefetch` 힌트를 활용하여 다음에 필요한 자산을 백그라운드에서 미리 준비.
|
||||
- **의의:** LCP와 INP 지표를 획기적으로 개선하여 검색 엔진 순위와 사용자 전환율(Conversion Rate)을 동시에 높임.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 HTTP/1.1 환경에서 요청 수를 줄이기 위해 하나의 거대한 번들(One big bundle)이 유리했으나, 현대 정책은 HTTP/2 이상의 다중화(Multiplexing) 환경에 최적화된 '다중 청크 정책'을 권장함.
|
||||
- **정책 변화:** Antigravity 프로젝트는 200KB 이상의 단일 JS 파일 생성을 금지 정책으로 하며, 모든 동적 임포트 시 로딩 상태(Loading Spinner/Skeleton) 제공 정책을 의무화함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[JavaScript-Optimization-Patterns]], [[Largest-Contentful-Paint-LCP]], [[Interaction-to-Next-Paint-INP]], [[Vite-Build-Optimization]], [[Modern-Frontend-Engineering-Architecture]]
|
||||
- **Raw Source:** [[00_Raw/코드 스플리팅 및 성능 최적화(Code Splitting & Performance Optimization).md]]
|
||||
Reference in New Issue
Block a user