DOM Reflow 100번을 1번으로 줄였더니 60fps가 돌아왔다
Summary
브라우저 엔진을 길들이는 법: 100번의 Reflow를 단 1번으로 압축하다
React를 우회하고 4단계 배칭 시스템으로 레이아웃 스래싱을 정복하여 60fps를 탈환한 최적화 전략
이 아티클은 고성능 그래픽 에디터 개발 중 마주한 렌더링 성능 한계를 브라우저 내부 메커니즘 이해를 통해 해결한 과정을 담고 있습니다. 단순히 React 최적화에 그치지 않고, 브라우저 레이아웃 파이프라인을 직접 통제하는 '4-Phase 배칭 모델'을 설계하여 리플로우 비용을 극적으로 절감한 실전 노하우를 공유합니다.
- 01React Reconciliation 모델이 고빈도 업데이트 요구사항에서 가질 수 있는 성능적 한계 분석
- 02DOM의 읽기(Read)와 쓰기(Write)가 교차될 때 발생하는 레이아웃 스래싱 현상과 성능 저하 원인 규명
- 03Task 기반의 4단계(PRE-READ-WRITE-POST) 배칭 매니저를 통한 브라우저 리플로우 최적화
- 04직접 DOM 조작(Native Rendering)과 React 상태 관리 간의 효율적인 동기화 전략 수립
- 05크롬 성능 프로파일러를 활용한 정량적인 성능 개선 지표(50ms → 0.5ms) 달성
RECOMMENDATION
에디터, 인터랙티브 대시보드, 타임라인 등 대량의 DOM 요소를 실시간으로 갱신해야 하는 프론트엔드 개발자에게 필수적인 읽을거리입니다. 프레임 드롭 문제로 고민 중이라면 브라우저 렌더링 파이프라인 관점에서의 접근법을 권장합니다.
The Problem
캔버스 에디터에서 여러 요소를 드래그할 때 수백 개의 DOM 노드가 동시에 업데이트되며 화면이 버벅이는 문제가 발생했습니다. 초기에는 React 렌더링 비용이 원인이라 판단했으나, 실제 병목은 DOM 읽기와 쓰기가 반복되며 발생하는 레이아웃 스래싱(Layout Thrashing)으로 인한 과도한 리플로우(Reflow)였습니다.
The Solution
React의 재조정 과정을 우회하여 DOM을 직접 조작하는 별도의 렌더링 파이프라인을 구축했습니다. 특히 DOM 작업의 순서를 제어하기 위해 모든 읽기(Read)를 먼저 수행하고 모든 쓰기(Write)를 나중에 수행하는 4단계 배칭(PRE, READ, WRITE, POST) 모델을 도입하여 레이아웃 계산을 1회로 제한했습니다.
The Result
100개 요소 드래그 시나리오 기준으로 프레임당 레이아웃 횟수가 약 100회에서 1회로 줄어들었으며, 레이아웃 소요 시간은 50ms에서 0.5ms로 대폭 단축되었습니다. 결과적으로 15~25fps에 머물던 프레임 레이트가 60fps로 복구되어 부드러운 사용자 경험을 제공하게 되었습니다.
Trade-off
React의 선언적 UI 모델 대신 직접 DOM을 제어하는 복잡한 상태 머신과 파이프라인을 유지보수해야 하는 부담이 생겼습니다. 또한 조작 중에는 React 상태와 실제 DOM이 일시적으로 괴리되므로, 조작 종료 시 idleCallback을 통해 수동으로 상태를 동기화하는 추가 로직이 필요합니다.
Key Concepts
More from 미리디
View all posts from 미리디
AI 잘 쓰는 사람의 노하우, 어떻게 팀 전체로 퍼질까?
AI EnablementAXAI Native2일 전미리캔버스가 AI 3대로 해외 트렌드에서 진짜를 가려내는 법
LLM AgentsMulti-Agent OrchestrationTrend Analysis1주 전AI로 QA 업무를 자동화한 방법: n8n부터 E2E 테스트 자동화까지
n8nE2E TestingLLM2주 전통합 검색 임베딩 모델 개발기: 9개 태스크를 고르게 학습시키기
EmbeddingMulti-task LearningContrastive Learning2주 전데이터 요청 응대 30분을 3분으로 줄인 n8n AI 에이전트
n8nAI AgentWorkflow Automation3주 전