2nd/10_Wiki/Topics/AI_and_ML/프론트엔드 성능 최적화.md

# [[프론트엔드 성능 최적화|프론트엔드 성능 최적화]]

## 📌 Brief Summary
프론트엔드 성능 최적화는 브라우저의 렌더링 과정을 이해하고, 불필요한 연산을 줄여 사용자에게 빠르고 매끄러운 웹 경험을 제공하는 일련의 과정입니다 [1, 2]. 이를 위해 HTML과 CSS가 DOM과 [[CSSOM|CSSOM]]을 거쳐 렌더 트리로 변환되는 중요 렌더링 경로(CRP)를 관리하며, 비용이 많이 드는 Reflow와 Repaint를 최소화합니다 [3, 4]. 또한 React의 [[Virtual DOM|Virtual DOM]] 메커니즘을 활용하여 DOM 조작을 효율화하고, 프로젝트의 목적에 맞게 CSR, SSR, SSG 등의 렌더링 방식을 전략적으로 선택하여 컴포넌트 기반 아키텍처로 유지보수성이 높은 시스템을 설계하는 것을 핵심 목적으로 합니다 [1, 5, 6].

## 📖 Core Content
* **브라우저 렌더링 과정 (HTML → CSSOM → [[Render Tree|Render Tree]]):** 
  브라우저는 데이터를 점진적으로 파싱하여 HTML을 문서 객체 모델(DOM)로 생성하고, CSS를 파싱하여 CSS 객체 모델(CSSOM)로 변환합니다 [3, 7, 8]. 이 두 트리가 준비되면 화면에 실제로 표시될 노드와 계산된 스타일 정보만을 포함하는 렌더 트리(Render Tree)로 결합합니다 (`display: none` 등의 시각적으로 숨겨진 요소는 제외됩니다) [9, 10]. 이후 렌더 트리를 기반으로 각 요소의 정확한 크기와 위치를 계산하는 레이아웃(Layout 또는 Reflow) 단계를 거친 후, 계산된 기하학적 형태를 화면의 실제 픽셀로 변환하는 페인트(Paint 또는 Repaint) 단계를 수행합니다 [11-15].

* **Reflow / Repaint 최소화 방법:** 
  Reflow(레이아웃 계산)는 브라우저 창 크기 조절이나 요소의 크기, 위치(`width`, `height`, `margin` 등)가 변경될 때 발생하며, 문서 흐름에 따라 전체 트리에 연쇄적인 재계산을 유발할 수 있어 연산 비용이 매우 높습니다 [11, 16-18]. 이를 최소화하려면 불필요한 DOM 깊이를 줄이고, 복잡한 CSS 선택자를 피해야 합니다 [19]. 특히 애니메이션과 같이 복잡한 렌더링 변경 시에는 `position: absolute`나 `fixed`를 사용하여 문서 흐름에서 요소를 분리하거나, Reflow를 유발하지 않고 GPU 가속을 활용할 수 있는 `transform` 속성을 사용하는 것이 좋습니다 [4, 12, 19, 20]. Repaint는 색상이나 그림자 등 시각적 속성만 변경될 때 발생하며 Reflow보다 부담은 적지만, 과도하게 발생 시 성능을 저하시키므로 DOM 조작과 변경 사항을 일괄 처리([[Batching|Batching]])하는 전략이 필수적입니다 [4, 12, 16, 21].

* **[[DOM vs Virtual DOM|DOM vs Virtual DOM]] 및 “React가 빠른 이유”:** 
  실제 DOM을 직접 조작하는 것은 본질적으로 매번 레이아웃과 페인트 단계를 유발해 속도가 느립니다 [22]. React는 이를 해결하기 위해 메모리 내에 UI의 가벼운 표현인 가상 DOM(Virtual DOM)을 유지합니다 [22, 23]. 상태가 변경되면 React는 O(n) 복잡도의 휴리스틱 Diffing 알고리즘을 통해 이전 가상 트리와 새로운 가상 트리를 비교([[Reconciliation|Reconciliation]])하고, 변경된 특정 속성이나 노드만을 계산해 실제 DOM에 한 번에 반영합니다 [22, 24-27]. 이처럼 불필요한 DOM 연산을 최소화하는 방식과 더불어, 렌더링 작업을 잘게 쪼개 우선순위를 매기는 Fiber 아키텍처와 상태 업데이트를 자동으로 그룹화하는 자동 일괄 처리([[Automatic Batching|Automatic Batching]]) 기능 덕분에 React는 빠르고 반응성 높은 UI를 제공할 수 있습니다 [28-31].

* **[[CSR vs SSR vs SSG|CSR vs SSR vs SSG]] 렌더링 전략:** 
  * **CSR (Client-Side Rendering):** 서버에서 빈 HTML과 [[JavaScript|JavaScript]]를 보내고 브라우저가 화면을 렌더링합니다 [5, 32, 33]. 대시보드나 [[SaaS|SaaS]] 앱처럼 상호작용이 많을 때 유리하지만, 자바스크립트 실행 전까지 화면이 비어 있어 초기 로딩(FCP)이 느리고 SEO에 취약합니다 [5, 34-36].
  * **SSR (Server-Side Rendering):** 서버가 각 요청마다 완전한 HTML을 렌더링하여 클라이언트에 전달하므로, 초기 화면이 즉시 표시되고 검색 엔진 최적화(SEO)에 매우 유리합니다 [37-40]. 그러나 브라우저가 JavaScript를 다운로드하고 이벤트 리스너를 연결하는 [[Hydration|Hydration]] 과정이 끝날 때까지는 페이지와 상호작용할 수 없는(TTI 지연) 단점이 있습니다 [37, 41-43].
  * **SSG (Static Site Generation):** 빌드 시점에 정적 HTML을 생성하고 CDN을 통해 즉각적으로 제공하는 방식입니다 [44-46]. 속도가 가장 빠르고 SEO가 뛰어나지만, 실시간 데이터가 필요한 동적 콘텐츠 페이지에는 적합하지 않습니다 [44, 47-49].

* **컴포넌트 기반 아키텍처 (CBA) 개념:** 
  애플리케이션을 독립적이고 재사용 가능하며 캡슐화된 구성 요소(컴포넌트)로 나누어 조립하는 소프트웨어 설계 방식입니다 [50-53]. 각 컴포넌트는 자체적인 데이터와 UI 로직을 포함하며, 잘 정의된 인터페이스(API)를 통해서만 상호작용합니다 [50, 51, 54]. 이 아키텍처는 코드의 재사용성을 높여 개발 속도를 단축하고, 각 팀이 병렬로 작업할 수 있도록 모듈성을 제공하며, 특정 컴포넌트만 수정 및 교체할 수 있어 시스템의 유지보수성과 확장성을 극대화합니다 [55-59].

## 🔗 Knowledge Connections
- **Related Topics:** [[중요 렌더링 경로 (Critical Rendering Path)|중요 렌더링 경로 (Critical Rendering Path]], 가상 DOM과 재조정 (Reconciliation), Hydration 성능 최적화, [[Fiber 아키텍처와 동시성 (Concurrent Rendering)|Fiber 아키텍처와 동시성 ([[Concurrent Rendering]]]], [[단일 페이지 애플리케이션 (SPA)|단일 페이지 애플리케이션 (SPA]]
- **Projects/Contexts:** [[웹 프론트엔드 아키텍처 설계|웹 프론트엔드 아키텍처 설계]], [[성능 및 SEO 최적화 프로젝트|성능 및 SEO 최적화 프로젝트]]
- **Contradictions/Notes:** 소스에 따르면 SSR은 서버에서 완전히 렌더링된 HTML을 제공하여 첫 화면 표시(FCP) 속도를 획기적으로 개선하지만, JavaScript 번들을 다운로드하고 하이드레이션(Hydration)이 완료되기 전까지는 사용자가 상호작용할 수 없기 때문에 TTI(Time to Interactive)는 오히려 지연될 수 있습니다. 이는 초기 콘텐츠 렌더링과 상호작용 활성화 사이의 성능 트레이드오프(Trade-off)를 의미합니다 [37, 42, 43, 60].

---
*Last updated: 2026-04-25*