[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,105 +2,197 @@
|
||||
id: wiki-2026-0508-reflow-and-repaint
|
||||
title: Reflow and Repaint
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Layout Thrashing, Browser Rendering, Compositing]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [browser, rendering, performance, dom, web]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: javascript
|
||||
framework: web
|
||||
---
|
||||
|
||||
# [[Reflow and Repaint|Reflow and Repaint]]
|
||||
# Reflow and Repaint
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Reflow(리플로우)는 요소의 너비, 높이 등 레이아웃에 영향을 미치는 변경이 발생할 때 브라우저가 페이지의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 배경색 등 시각적 요소만 변경될 때 레이아웃 계산 없이 화면을 다시 그리는 작업입니다 [1, 2]. 이 두 과정은 비용이 많이 드는 작업으로 브라우저 렌더링 성능에 큰 영향을 미치며, 특히 애니메이션이나 동적 UI를 구현할 때 성능 저하와 버벅거림(Jank)의 주된 원인이 됩니다 [1, 3, 4]. 따라서 유지보수 가능하고 확장성 있는 CSS를 설계하기 위해서는 리플로우와 리페인트를 최소화하는 렌더링 최적화 전략이 필수적입니다 [5-7].
|
||||
## 매 한 줄
|
||||
> **"매 DOM mutation 의 cost 의 reflow 의 dominate"**. Browser rendering pipeline 의 layout (reflow) → paint (repaint) → composite. Reflow 의 가장 expensive — geometry recalc 매 children. 2026 의 GPU compositing + Layout API 의 mitigate.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
리플로우(Reflow)는 브라우저가 화면 내 요소들의 기하학적 위치와 크기를 재계산하는 과정을 의미하며 컴퓨팅 자원을 많이 소모합니다 [1-3]. 반면 리페인트(Repaint)는 레이아웃에 영향을 주지 않는 시각적 스타일 변화(색상, 그림자 등)를 픽셀로 변환하여 화면에 그리는 작업입니다 [1, 4]. 두 과정 모두 웹 페이지의 크리티컬 렌더링 패스(CRP)에서 화면을 업데이트하는 데 필수적이지만, 과도하게 발생할 경우 웹 페이지의 성능을 크게 저하시키므로 이를 최소화하는 것이 프론트엔드 성능 최적화의 핵심입니다 [5-7].
|
||||
### 매 Pipeline
|
||||
1. **Style** — CSS 의 element 의 match.
|
||||
2. **Layout (Reflow)** — geometry (width/height/position) compute.
|
||||
3. **Paint (Repaint)** — pixel 의 layer 의 fill.
|
||||
4. **Composite** — layers 의 GPU 의 combine.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Reflow와 Repaint의 개념**
|
||||
* **Repaint:** 요소의 가시성(visibility), 배경색(background color), 윤곽선(outline) 등 레이아웃에 영향을 주지 않는 시각적 스킨의 변화가 생길 때 발생합니다 [1, 2]. 브라우저는 DOM 트리에 있는 다른 노드들의 가시성까지 확인해야 하므로 비용이 발생합니다 [2].
|
||||
* **Reflow:** 요소의 크기(width, height), 여백(margin, padding), 위치(left, top 등) 등 레이아웃 기하학이 변경될 때 발생합니다 [3, 8]. 해당 요소뿐만 아니라 자식 요소, 조상 요소, 그리고 DOM 트리에서 그 뒤에 오는 요소들까지 연쇄적으로 리플로우를 유발하므로 전체 페이지를 다시 배치하는 것과 맞먹는 높은 비용이 듭니다 [2, 4].
|
||||
### 매 Reflow triggers
|
||||
- Geometric 변화: `width`, `height`, `top`, `padding`, `font-size`.
|
||||
- DOM mutation: `appendChild`, `removeChild`.
|
||||
- Read-then-write 패턴: `offsetHeight` (force sync layout).
|
||||
- Window resize, font load.
|
||||
|
||||
* **성능 저하를 유발하는 주요 원인**
|
||||
* 창 크기 조절, 폰트 변경, DOM 스크립트 조작, CSS 가상 클래스(`:hover` 등) 활성화, 클래스 속성 변경, `offsetWidth` 및 `offsetHeight` 계산 등 다양한 작업이 리플로우를 유발합니다 [9, 10].
|
||||
* DOM을 읽고 쓰는 작업을 짧은 루프 안에서 연속적으로 실행하면 브라우저가 강제로 동기적 리플로우를 수행해야 하는 레이아웃 스래싱([[Layout Thrashing|Layout Thrashing]])이 발생하여 프레임 속도가 크게 저하됩니다 [11, 12].
|
||||
* 크기나 여백 같은 레이아웃 속성을 애니메이션으로 처리하면 브라우저가 렌더링 엔진을 매 프레임마다 호출해야 하므로 성능에 치명적입니다 [1, 3].
|
||||
### 매 Repaint-only triggers (no reflow)
|
||||
- `color`, `background-color`, `visibility`.
|
||||
- 매 cheap relative.
|
||||
|
||||
* **Reflow 및 Repaint 최적화(감소) 기법**
|
||||
* **GPU 가속 활용:** 레이아웃을 변경하는 속성 대신 `transform`과 `opacity`를 애니메이션에 사용하면 브라우저가 값비싼 Layout과 Paint 단계를 건너뛰고 GPU에서 합성(Compositing)만 처리하므로 성능이 크게 향상됩니다 [8, 13, 14].
|
||||
* **DOM 변경 및 스타일 적용 최소화:** 여러 개의 인라인 스타일을 각각 설정하는 것을 피하고, 변경 사항을 묶어 CSS 클래스로 처리해야 합니다 [15, 16]. 또한 리플로우의 파급 범위를 줄이기 위해 DOM 트리의 가능한 가장 낮은 하위 노드에서 클래스를 변경해야 합니다 [17].
|
||||
* **문서 흐름(Flow) 분리:** 애니메이션이 적용되는 요소에는 `position: fixed` 또는 `absolute`를 적용하여 주변 요소의 레이아웃에 영향을 주지 않고 리페인트만 발생하도록 유도할 수 있습니다 [15].
|
||||
* **테이블 레이아웃 지양:** 테이블은 아주 작은 변화에도 내부의 모든 노드가 리플로우를 일으킬 수 있고, 전체 콘텐츠를 파악하기 위해 여러 번의 렌더링 패스가 필요하므로 레이아웃 목적으로 사용해서는 안 됩니다 [18].
|
||||
* **렌더링 힌트 제공:** 변경이 빈번하게 일어날 요소에는 `will-change` 속성을 사용하여 브라우저가 미리 렌더링 최적화를 준비하도록 지시할 수 있습니다 [12, 19].
|
||||
* **애니메이션 주기의 동기화:** `requestAnimationFrame`을 사용하여 자바스크립트 애니메이션을 브라우저의 기본 리페인트 주기와 동기화해야 합니다 [11, 12].
|
||||
### 매 Composite-only (cheapest)
|
||||
- `transform`, `opacity` (with `will-change` or layer promotion).
|
||||
- GPU 의 handle — 60fps 의 가능.
|
||||
|
||||
---
|
||||
### 매 Layout thrashing
|
||||
- 매 read → write → read → write 의 loop → 매 forced sync layout 의 매 step.
|
||||
- Fix: 매 batch reads, batch writes.
|
||||
|
||||
* **리플로우(Reflow / Layout)의 메커니즘과 영향:**
|
||||
* 브라우저가 뷰포트 크기와 박스 모델을 기반으로 렌더 트리 내 모든 가시적 요소의 정확한 위치와 크기(x, y, 너비, 높이)를 계산하는 과정입니다 [3, 8, 9].
|
||||
* 주로 창 크기 조절(Resizing), DOM 요소의 추가 및 제거, 마진이나 패딩 등 레이아웃에 영향을 주는 속성이 변경될 때 트리거됩니다 [1, 4, 10].
|
||||
* 문서 흐름(Document flow)의 특성상 단일 요소의 기하학적 변화가 렌더 트리 전체의 연쇄적인 재계산(Cascade of recalculations)을 유발할 수 있으므로, 리플로우는 연산 비용이 매우 높은 작업에 속합니다 [2, 7, 8].
|
||||
### 매 Modern APIs
|
||||
- **`requestAnimationFrame`**: 매 paint 직전 의 schedule.
|
||||
- **`IntersectionObserver`**: 매 scroll 의 listen 의 X.
|
||||
- **`ResizeObserver`**: layout 의 element-level observe.
|
||||
- **CSS `contain: layout/paint`**: subtree isolation.
|
||||
- **`content-visibility: auto`**: viewport 외 의 skip render.
|
||||
- **CSS Houdini Layout API**: custom layout — 매 2026 widely available.
|
||||
- **View Transitions API**: smooth page-to-page animation.
|
||||
|
||||
* **리페인트(Repaint / Paint)의 메커니즘과 영향:**
|
||||
* 기하학적 구조 계산이 완료된 후, 스타일 정보를 바탕으로 렌더 트리의 각 노드를 실제 화면의 픽셀로 래스터화(Rasterizing)하는 과정입니다 [1, 11, 12].
|
||||
* 배경색, 텍스트 색상, 그림자(box-shadow), 가시성 등 레이아웃 수치를 변경하지 않는 시각적 속성 변화가 있을 때만 발생합니다 [1, 4, 10].
|
||||
* 리플로우보다는 계산 비용이 상대적으로 적지만, 애니메이션 도중 과도하게 트리거되면 프레임 드랍이나 버벅거림(Jank)을 일으켜 CPU/GPU 사용량을 높이고 모바일 기기의 배터리를 소모시킬 수 있습니다 [2, 6, 11].
|
||||
### 매 응용
|
||||
1. List virtualization (react-virtual, TanStack Virtual).
|
||||
2. Animation 의 transform/opacity-only.
|
||||
3. SPA route transition (View Transitions).
|
||||
4. Long-list performance (`content-visibility`).
|
||||
5. Charting (Canvas/WebGL 의 DOM 의 avoid).
|
||||
|
||||
* **성능 최적화 전략 ([[Optimization|Optimization]] Strategies):**
|
||||
* **CSS 속성 최적화:** 리플로우를 유발하는 속성(예: `top`, `left`, `width`, `height`) 대신 `transform` 속성을 활용하여 애니메이션을 구현하면, 새로운 레이아웃이나 페인트 사이클을 유발하지 않고 GPU 가속을 통해 처리할 수 있습니다 [6, 7, 11].
|
||||
* **가시성 제어 활용:** 요소를 화면에서 숨길 때 렌더 트리에서 완전히 제거하여 리플로우를 유발하는 `display: none` 대신, 시각적으로만 숨기고 공간을 유지해 리페인트만 유발하는 `visibility: hidden`을 사용하는 것이 유리할 수 있습니다 [13, 14].
|
||||
* **DOM 조작 최소화 및 배치([[Batching|Batching]]) 처리:** 자바스크립트 반복문 내에서의 DOM 조작을 피하고 변경 사항을 일괄 처리해야 합니다 [6, 7]. 또한, React와 같이 가상 DOM([[Virtual DOM|Virtual DOM]])을 사용하는 프레임워크는 변경된 부분만을 계산하여 실제 DOM에 반영함으로써 불필요한 리플로우와 리페인트 횟수를 줄이는 데 도움을 줍니다 [6, 15].
|
||||
## 💻 패턴
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
No trade-offs available.
|
||||
### Layout thrashing 의 fix
|
||||
```javascript
|
||||
// BAD — 매 iteration 의 forced reflow
|
||||
for (const el of items) {
|
||||
const w = el.offsetWidth; // read
|
||||
el.style.width = (w + 10) + "px"; // write — invalidates layout
|
||||
}
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS Animations|CSS Animations]], Layout Thrashing, GPU Acceleration (Compositing), [[CSS Architecture|CSS Architecture]]
|
||||
- **Projects/Contexts:** 애니메이션 (transition / keyframes) 성능 최적화, [[실무에서 CSS 관리하는 방법|실무에서 CSS 관리하는 방법]]
|
||||
- **Contradictions/Notes:** 브라우저 성능 최적화를 돕는 `will-change` 속성은 유용하지만, 최후의 수단으로만 사용해야 합니다. 이를 성능 문제 예측용으로 무분별하게 너무 많은 요소에 남용할 경우, 과도한 메모리 사용 등 그 자체로 심각한 성능 저하를 초래할 수 있다고 경고하고 있습니다 [19, 20].
|
||||
// GOOD — batch reads, then batch writes
|
||||
const widths = items.map(el => el.offsetWidth);
|
||||
items.forEach((el, i) => { el.style.width = (widths[i] + 10) + "px"; });
|
||||
```
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
### transform animation (composite-only)
|
||||
```css
|
||||
.card { will-change: transform; transition: transform 200ms ease-out; }
|
||||
.card:hover { transform: translateY(-4px) scale(1.02); }
|
||||
/* 매 60fps GPU 의 — top/left 의 use 의 X */
|
||||
```
|
||||
|
||||
---
|
||||
### content-visibility
|
||||
```css
|
||||
.long-article > section {
|
||||
content-visibility: auto;
|
||||
contain-intrinsic-size: 0 500px; /* 매 placeholder size */
|
||||
}
|
||||
/* 매 viewport 외 의 layout/paint 의 skip — 10x 빠름 매 long page */
|
||||
```
|
||||
|
||||
- **Related Topics:** [[Critical Rendering Path (CRP)|Critical Rendering Path (CRP]], Render Tree, Virtual DOM, Document Object Model (DOM), CSS Object Model ([[CSSOM|CSSOM]]), GPU Acceleration
|
||||
- **Projects/Contexts:** 프론트엔드 웹 렌더링 성능 최적화, React의 컴포넌트 아키텍처 및 렌더링 최적화([[Reconciliation|Reconciliation]])
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (제공된 모든 소스는 리플로우와 리페인트의 특성 및 이를 최소화해야 한다는 최적화 원칙에 대해 모순 없이 일치된 견해를 보입니다.)
|
||||
### IntersectionObserver (lazy)
|
||||
```javascript
|
||||
const io = new IntersectionObserver(entries => {
|
||||
entries.forEach(e => {
|
||||
if (e.isIntersecting) {
|
||||
e.target.src = e.target.dataset.src;
|
||||
io.unobserve(e.target);
|
||||
}
|
||||
});
|
||||
}, { rootMargin: "200px" });
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
document.querySelectorAll("img[data-src]").forEach(img => io.observe(img));
|
||||
```
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### View Transitions API (2026)
|
||||
```javascript
|
||||
async function navigate(url) {
|
||||
if (!document.startViewTransition) { location.href = url; return; }
|
||||
document.startViewTransition(async () => {
|
||||
const html = await fetch(url).then(r => r.text());
|
||||
document.body.innerHTML = parseBody(html);
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### React virtualization (TanStack)
|
||||
```typescript
|
||||
import { useVirtualizer } from "@tanstack/react-virtual";
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
function List({ items }: { items: Item[] }) {
|
||||
const parentRef = useRef<HTMLDivElement>(null);
|
||||
const v = useVirtualizer({
|
||||
count: items.length,
|
||||
getScrollElement: () => parentRef.current,
|
||||
estimateSize: () => 40,
|
||||
overscan: 5,
|
||||
});
|
||||
return (
|
||||
<div ref={parentRef} style={{ height: 600, overflow: "auto" }}>
|
||||
<div style={{ height: v.getTotalSize(), position: "relative" }}>
|
||||
{v.getVirtualItems().map(vi => (
|
||||
<div key={vi.key} style={{ position: "absolute", top: vi.start,
|
||||
height: vi.size, width: "100%" }}>
|
||||
{items[vi.index].name}
|
||||
</div>
|
||||
))}
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Profile with PerformanceObserver
|
||||
```javascript
|
||||
new PerformanceObserver(list => {
|
||||
for (const entry of list.getEntries()) {
|
||||
if (entry.duration > 50) console.warn("Long task:", entry);
|
||||
}
|
||||
}).observe({ entryTypes: ["longtask"] });
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Animate position | `transform` + `will-change` |
|
||||
| Animate color | OK (repaint only, cheap) |
|
||||
| Long list (>1000) | Virtualize (TanStack Virtual) |
|
||||
| Static long page | `content-visibility: auto` |
|
||||
| Subtree isolation | `contain: layout paint` |
|
||||
| Page transition | View Transitions API |
|
||||
| Charts / heavy draw | Canvas / WebGL |
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
**기본값**: 매 transform/opacity 의 animate, virtualize 매 >100 rows, profile with Chrome Performance panel.
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
## 🔗 Graph
|
||||
- 부모: [[Web-Performance]] · [[Browser-Rendering]]
|
||||
- 변형: [[Layout-Thrashing]] · [[Compositing]] · [[GPU-Acceleration]]
|
||||
- 응용: [[Virtual-Scrolling]] · [[CSS-Animations]] · [[View-Transitions]]
|
||||
- Adjacent: [[Core-Web-Vitals]] · [[CLS]] · [[INP]]
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 perf bottleneck explain (read flame chart), code review for layout thrash, CSS containment recommend.
|
||||
**언제 X**: actual measurement (Chrome DevTools / Lighthouse 의 use), pixel-level paint debugging.
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## ❌ 안티패턴
|
||||
- **`top`/`left` animate**: 매 매 frame reflow → 30fps. transform 의 use.
|
||||
- **Read-write loop**: layout thrashing — batch.
|
||||
- **`!important` 의 abuse**: 매 specificity war 의 reflow rules complex 의.
|
||||
- **Deep DOM (10k+ nodes)**: 매 reflow time 의 linear. virtualize.
|
||||
- **Sync `getBoundingClientRect` 매 RAF**: forces layout — cache.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Chrome DevTools docs, web.dev rendering, MDN content-visibility, View Transitions spec).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — pipeline + 2026 modern APIs |
|
||||
|
||||
Reference in New Issue
Block a user