브라우저는 HTML을 어떻게 화면으로 바꿀까: 렌더링 파이프라인과 성능 포인트 빠른 답 브라우저는 DOM -> CSSOM -> 렌더 트리 -> 레이아웃 -> 페인트 -> 컴포지팅 순서로 화면을 만든다. 크기와 위치를 바꾸면 레이아웃 비용이 커지고, 색상·그림자·배경 변경은 주로 페인트 비용을 만든다. transform과 opacity 중심 애니메이션은 컴포지팅 단계에서 처리돼 더 부드럽게 동작하는 경우가 많다. 성능 문제는 감으로 추측하지 말고 Chrome DevTools의 Performance, Layers, Paint flashing으로 먼저 확인한다. 목차 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인을 왜 알아야 할까: 화면은 느린데 API는 빠른 이유 HTML이 픽셀이 되기까지: DOM, CSSOM, 렌더 트리, 레이아웃, 페인트, 컴포지팅 어떤 변경이 어디까지 전파될까: 스타일 계산, 레이아웃, 페인트, 컴포지팅 프런트엔드에서 자주 만드는 안티패턴 성능에 유리한 렌더링 구성 예시: CSS 속성 선택과 숨김 전략 렌더링 타이밍: React 리렌더링과 브라우저 페인트는 다르다 Chrome DevTools로 병목 확인하기 자주 하는 오해와 실무 체크리스트 데이터 흐름과 상태 소유권부터 봐야 하는 이유 브라우저 렌더링 파이프라인은 브라우저가 화면을 그리는 방법을 설명합니다. 하지만 실무에서 성능 문제가 시작되는 지점은 대개 그보다 앞입니다. 어떤 상태가 바뀌었고, 그 상태 변화가 어떤 컴포넌트 재계산과 DOM 변경으로 이어졌는지가 먼저입니다. 브라우저는 갑자기 화면을 느리게 만드는 주체라기보다, 애플리케이션이 만든 결과를 계산하고 그리는 쪽에 가깝습니다. 그래서 프런트엔드 성능은 브라우저 지식만으로는 잘 풀리지 않습니다. 상태를 누가 소유하는지, 변경이 어떤 방향으로 흐르는지, 작은 상호작용이 왜 큰 트리의 리렌더링으로 번지는지를 같이 봐야 합니다. 상태는 한 곳이 소유하고, 아래로 전...