Skip to content

docs: Day 1 Reflow vs Repaint 실험 및 성능 최적화 최종 보고서 #9

Description

@PaleBlueNote

📌 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: 모드 전환 시 이전 스타일 속성(left vs transform) 충돌로 인한 위치 튀는 현상(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

Image
  • 상단 (CPU Mode - Reflow):

    • 현상: 보라색(Rendering) 작업 막대가 프레임마다 폭이 넓고 촘촘하게(High Density & Wide Spikes) 배치되어 있으며, 유휴 시간(Idle Gap)이 매우 짧습니다.
    • 해석: requestAnimationFrame이 매 프레임 호출되지만, LayoutPaint를 포함한 렌더링 파이프라인의 전체 비용이 16.6ms(60Hz 기준) 예산을 초과하거나 육박하고 있습니다. 이는 메인 스레드를 장시간 점유하여 사용자 입력 처리를 지연(Blocking)시킵니다.
  • 하단 (GPU Mode - Composite):

    • 현상: 불규칙한 패턴의 보라색(Rendering) 스파이크가 관측됩니다.
    • 해석: Reflow 비용은 제거되었으나, 테스트 당시 과도한 레이어 생성(Layer Explosion)으로 인한 Layer Management Overhead가 발생하여 간헐적인 병목이 관측됩니다.

2. Deep Dive: CPU Mode Frame Drops

Image
  • 🚨 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

documentationImprovements or additions to documentation

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions