# [[Reflow 및 Repaint 최적화]]

## 📌 Brief Summary
Reflow는 브라우저가 문서의 레이아웃이나 요소의 기하학적 구조(너비, 높이, 위치 등)를 다시 계산하는 과정이며, Repaint는 레이아웃에는 영향을 주지 않는 시각적 변화(색상, 배경 등)를 화면에 다시 그리는 과정이다 [1, 2]. 이 두 과정은 처리 비용이 매우 높아 과도하게 발생할 경우 CSS 애니메이션과 자바스크립트의 성능을 저하시키고 화면의 버벅거림(Janky)을 유발한다 [3-5]. 따라서 효율적인 CSS 속성 선택과 DOM 조작의 최소화를 통해 Reflow와 Repaint의 발생을 줄이는 것은 유지보수 가능하고 확장성 있는 프론트엔드 아키텍처를 구축하기 위한 필수적인 렌더링 파이프라인 최적화 기법이다 [5-7].

## 📖 Core Content
* **Reflow와 Repaint의 개념 및 발생 원인**
  * **Repaint:** 요소의 스킨(outline, visibility, background color 등)이 변경되어 가시성에만 변화가 생길 때 발생한다 [2]. 브라우저가 DOM 트리의 다른 노드들의 가시성까지 확인해야 하므로 비용이 든다 [2].
  * **Reflow:** 요소의 크기(width, height, margin, padding 등)나 위치가 변경되어 페이지의 레이아웃이 바뀔 때 발생한다 [2, 3]. 한 요소의 Reflow는 자식 요소, 조상 요소, 그리고 DOM 트리에서 뒤따르는 요소들의 연쇄적인 Reflow를 유발하여 거의 전체 페이지를 다시 레이아웃하는 것과 같은 엄청난 처리 비용을 요구한다 [2, 4, 8].
  * **주요 원인:** 창 크기 조절, 폰트 변경, `:hover` 등의 가상 클래스 활성화, 스크립트를 통한 DOM 조작, `offsetWidth` 또는 `offsetHeight` 계산, 인라인 스타일 변경 등이 모두 Reflow를 트리거한다 [9, 10].

* **CSS 및 애니메이션 최적화 전략**
  * **레이아웃 속성 애니메이션 지양:** `width`, `height`, `margin`, `left`, `top` 등의 속성을 애니메이션화하면 지속적인 Reflow와 Repaint 사이클이 발생하여 성능을 크게 떨어뜨린다 [3, 5, 8, 11]. 대신 레이아웃 재계산을 피하고 GPU 가속(Compositing)을 활용할 수 있는 `transform`과 `opacity`를 사용해야 한다 [8, 12, 13].
  * **고비용 속성 최소화 및 `will-change` 활용:** `box-shadow`, `filter`, `border-radius`와 같이 렌더링 리소스를 많이 소모하는 속성의 사용을 주의해야 한다 [12, 14]. 브라우저에게 변경이 일어날 요소를 미리 알려주는 `will-change` 속성을 활용하면 성능 최적화에 도움이 되지만, 너무 많은 요소에 남용하면 성능 저하를 유발할 수 있다 [7, 15, 16].
  * **애니메이션 요소의 위치 독립:** 애니메이션을 적용할 요소에 `position: fixed` 또는 `absolute`를 설정하면 다른 요소의 레이아웃에 영향을 주지 않아 무거운 Reflow 대신 상대적으로 가벼운 Repaint만 발생하게 할 수 있다 [17, 18].

* **DOM 조작 및 스크립트 실행 최적화**
  * **DOM 조작 최소화 및 일괄 처리:** `documentFragment`를 사용해 DOM 업데이트를 일괄로 처리하거나 노드를 복사하여 변경한 후 원본과 한 번에 교체하는 방식으로 Reflow/Repaint 횟수를 줄일 수 있다 [6, 19]. 또한 여러 개의 인라인 스타일을 반복해서 설정하기보다는 CSS 클래스 한 번의 변경으로 스타일을 적용해야 한다 [17, 19].
  * **레이아웃 스래싱(Layout Thrashing) 방지:** DOM 읽기와 쓰기를 좁은 루프 안에서 번갈아 수행하면, 브라우저는 정확한 수치를 반환하기 위해 강제로 동기적인 Reflow를 실행하게 되어 심각한 병목 현상이 발생한다 [7, 10]. 이를 막기 위해 읽기/쓰기 작업을 분리하고, `requestAnimationFrame`을 사용하여 브라우저의 렌더링 주기에 맞추어 업데이트해야 한다 [7, 10].

* **구조적 최적화 고려사항**
  * **DOM 트리 하단에서의 클래스 변경:** Reflow의 파급 범위를 최소화하기 위해, 상위 래퍼(wrapper) 요소보다는 DOM 트리에서 최대한 하단에 위치한 요소의 클래스를 변경하는 것이 유리하다 [20].
  * **테이블 레이아웃 지양 및 선택자 단순화:** 테이블 레이아웃은 렌더링 시 여러 번의 계산 패스가 필요하고, 작은 변경에도 내부의 모든 노드에 Reflow를 유발하므로 피해야 한다(필요시 `table-layout: fixed` 사용) [21, 22]. 더불어 불필요하게 깊게 중첩되고 복잡한 CSS 선택자는 렌더링 파싱 속도를 늦추므로 단순하고 직접적인 선택자를 사용해야 한다 [19, 23, 24].

## 🔗 Knowledge Connections
- **Related Topics:** CSS 성능 최적화, CSS 애니메이션(transition / keyframes), DOM 조작과 렌더링 파이프라인, GPU 가속(Compositing)
- **Projects/Contexts:** 확장 가능한 CSS 아키텍처 설계, 실무에서의 CSS 상태 관리 및 프론트엔드 성능 개선
- **Contradictions/Notes:** 브라우저 제조사들이 성능 저하의 주범으로 지목하는 Reflow와 Repaint 자체를 브라우저 환경에서 완전히 없앨 수는 없습니다. 하지만 개발자는 불필요한 레이아웃 속성 변경이나 레이아웃 스래싱을 피하도록 설계함으로써 그 영향을 획기적으로 최소화할 수 있습니다 [20, 25, 26]. `will-change` 속성 또한 브라우저 최적화를 돕는 훌륭한 도구이지만, 과도하게 사용할 경우 오히려 디바이스 리소스를 고갈시켜 프레임 드랍을 유발할 수 있으므로 최후의 수단으로 신중히 사용해야 합니다 [15, 16, 27].

---
*Last updated: 2026-04-26*