docs: Day 1 Reflow vs Repaint 실험 및 성능 최적화 최종 보고서 #9
Description
📌 Overview
브라우저 렌더링 파이프라인의 Reflow(Layout) 와 Repaint(Composite) 단계의 비용 차이를 시각적으로 증명하고, 대량의 DOM 제어 시 발생하는 성능 병목을 해결하는 실험을 수행함.
🛠️ Implemented Features (구현 기능)
1. 렌더링 엔진 비교 (Core)
- CPU Mode (Slow):
left/top속성을 제어하여 Reflow(Layout) 유발. - GPU Mode (Fast):
transform: translate3d를 사용하여 Composite(합성) 단계만 수행 (Hardware Acceleration).
2. 동적 부하 테스트 (Load Testing)
- Dynamic Slider: 기기 성능(Mobile/Desktop)에 따라 테스트 대상을
100~5,000개까지 실시간 조절 가능. - Stats.js: 실시간 FPS(Frame Per Second) 모니터링 연동.
3. UX/UI 개선
- Transition Handling: 렌더링 모드 전환 시
useTransition을 사용하여 UI 블로킹 방지. - Style Cleanup: 모드 전환 시 이전 스타일 속성(
leftvstransform) 충돌로 인한 위치 튀는 현상(Flicker) 해결.
🚨 Troubleshooting & Optimization (핵심 경험)
Issue 1: Layer Explosion (레이어 폭발 현상)
- 문제 상황: 초기 실험에서 3,000개 요소에 일괄적으로
will-change: transform적용 시, 오히려 GPU 모드가 CPU 모드보다 느려지는 역전 현상 발생. - 원인 분석:
will-change는 요소를 별도의 그래픽 레이어(Texture)로 분리함.- 3,000개의 텍스처를 생성하고 VRAM에 업로드/합성하는 Overhead가 단순 좌표 계산 비용을 초과함.
- 해결책:
- 테스트 기본 개수를 1,000개로 하향 조정하여 최적점(Sweet Spot) 탐색.
- 부하 테스트용 슬라이더를 도입하여 사용자가 직접 한계를 테스트하도록 개선.
📊 Performance Analysis: CPU vs GPU
Performance 탭의 타임라인을 통해 렌더링 방식에 따른 메인 스레드 부하와 프레임 드랍 원인을 비교 분석했습니다.
1. Overview Comparison
-
상단 (CPU Mode - Reflow):
- 현상: 보라색(Rendering) 작업 막대가 프레임마다 폭이 넓고 촘촘하게(High Density & Wide Spikes) 배치되어 있으며, 유휴 시간(Idle Gap)이 매우 짧습니다.
- 해석:
requestAnimationFrame이 매 프레임 호출되지만,Layout과Paint를 포함한 렌더링 파이프라인의 전체 비용이 16.6ms(60Hz 기준) 예산을 초과하거나 육박하고 있습니다. 이는 메인 스레드를 장시간 점유하여 사용자 입력 처리를 지연(Blocking)시킵니다.
-
하단 (GPU Mode - Composite):
- 현상: 불규칙한 패턴의 보라색(Rendering) 스파이크가 관측됩니다.
- 해석:
Reflow비용은 제거되었으나, 테스트 당시 과도한 레이어 생성(Layer Explosion)으로 인한 Layer Management Overhead가 발생하여 간헐적인 병목이 관측됩니다.
2. Deep Dive: CPU Mode Frame Drops
-
🚨 Dropped Frame (빨간색 빗금) 원인 분석:
- 16.6ms의 데드라인 초과: 브라우저는 60Hz 주사율을 맞추기 위해 16.6ms 안에 화면 갱신을 마쳐야 합니다.
- rAF의 한계:
requestAnimationFrame은 프레임 시작 시점에 맞춰 실행을 보장하지만, 콜백 내부의 연산 비용(Reflow) 자체가 마감 시간을 넘겨버리면 다음 V-Sync 타이밍을 놓치게 됩니다. - 결과: 브라우저는 미처 그리지 못한 프레임을 건너뛰고(Drop), 사용자는 화면이 뚝뚝 끊기는(Stuttering) 현상을 경험하게 됩니다.
-
🐢 Main Thread Task:
Main트랙의 길게 늘어진 작업 막대들은 브라우저가 위치 계산(Style -> Layout -> Paint)을 수행하느라 골든 타임을 놓치고 있음을 시각적으로 증명합니다.
💡 Conclusion
- CPU 모드는 "연산 비용(Computation)" 문제로 인해 프레임 드랍이 발생합니다.
- GPU 모드는 "대역폭/관리 비용(Overhead)" 문제(Layer Explosion)로 인해 병목이 발생할 수 있습니다.
- 따라서 무조건적인 GPU 전환보다는, **적절한 레이어 수 유지(Virtualization 등)**가 성능 최적화의 핵심임을 확인했습니다.
🔗 Reference
- Implement Feature: feat: Reflow vs Repaint 렌더링 성능 비교 실험 구현 #3
- Fix Layer Explosion: fix: GPU 모드 성능 저하(Layer Explosion) 해결 및 실험 변별력 확보 #5