브라우저 렌더링 경로: 프레임 지연을 단계별로 진단하기
DOM부터 합성까지를 고정된 순서표가 아닌 진단 모델로 설명하고, DevTools 트레이스에서 레이아웃·페인트·합성 병목을 구분하는 방법을 정리합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
렌더링 경로는 반복 가능한 진단 모델입니다
브라우저는 HTML과 CSS를 해석해 화면을 만들지만, 이를 매번 DOM → CSSOM → 렌더 트리 → 레이아웃 → 페인트 → 합성의 한 번짜리 순차 파이프라인으로 실행하지는 않습니다. 파싱과 리소스 로딩은 겹쳐 진행될 수 있고, 스크립트·스타일·이미지 변경이나 사용자 입력에 따라 필요한 계산만 다시 수행되기도 합니다. 이 단계 이름들은 DevTools 기록을 읽기 위한 모델로 쓰는 편이 정확합니다.
대략 DOM 노드와 스타일이 계산되고, 레이아웃이 필요한 경우 상자 기하를 계산한 뒤, 페인트 기록과 합성이 이어질 수 있습니다. display: none은 레이아웃 상자를 만들지 않지만 visibility: hidden은 일반적으로 공간을 유지합니다. CSS 로딩이 첫 화면에 미치는 영향도 모든 스타일시트가 완전히 내려올 때까지 화면 전체가 항상 비어 있다는 뜻은 아닙니다. 문서의 구조와 스크립트 의존성, 브라우저 구현을 함께 봐야 합니다.
변경한 CSS 속성이 알려주는 비용
| 변경 예 | 브라우저가 다시 확인할 수 있는 작업 | 트레이스에서 볼 단서 |
|---|---|---|
| 요소 너비·글꼴 크기 변경 | 레이아웃, 이후 페인트·합성 | 긴 Layout/Recalculate Style, 영향을 받은 요소 범위 |
| 그림자·배경 등 시각 효과 변경 | 페인트와 합성 | 긴 Paint 또는 raster 작업 |
transform 이동·opacity 변경 | 경우에 따라 레이어 갱신과 합성만으로 처리 가능 | Paint가 생략되는지, 별도 레이어와 메모리 비용이 늘었는지 |
마지막 행은 보장된 최적화 규칙이 아닙니다. 속성, 효과, 레이어 승격, 브라우저와 장치에 따라 페인트나 래스터 작업이 다시 필요할 수 있고, GPU 사용 여부도 고정되어 있지 않습니다. will-change를 무조건 붙이거나 모든 요소를 레이어로 만들면 메모리와 합성 비용이 늘 수 있습니다.
DevTools에서 원인을 좁히는 순서
- Chrome DevTools Performance에서 재현 동작을 기록하고 긴 프레임을 선택합니다. 이 기록은 해당 브라우저·장치·페이지 실행의 관측값이지 다른 환경의 보장은 아닙니다.
- Main 트랙에서
Recalculate Style,Layout,Paint중 어디에 시간이 쌓이는지 봅니다. 스타일 변경 직후getBoundingClientRect()나offsetHeight를 읽는 코드가 있으면 강제 동기 레이아웃의 원인인지 확인합니다. - layout 작업이 반복된다면 쓰기와 기하 읽기를 한 루프에 섞지 말고, 한 번에 DOM을 갱신한 뒤 필요한 값을 읽도록 구조를 바꿔 비교합니다. 변경 전후 트레이스를 같은 조건으로 다시 기록합니다.
- 페인트 비용이 크면 영향을 받는 영역과 CSS 효과를 확인합니다.
transform/opacity로 바꾸는 실험은 프레임 시간과 레이어 메모리를 함께 비교하고, 실제 대상 기기에서 이득이 있는 경우에만 유지합니다.
가상의 예: 카드 열기 애니메이션
카드를 열 때 매 프레임 height를 바꾼다면 주변 콘텐츠가 재배치되어 레이아웃이 반복될 수 있습니다. 같은 UI를 고정된 영역 안의 transform/opacity 전환으로 바꾸면 재배치가 줄어들 가능성은 있지만, 콘텐츠가 잘리거나 접근성 동작이 달라지면 대안이 아닙니다. 이 예는 예상 가능한 원인과 실험 방향을 설명한 가상 사례이며, 측정 결과가 아닙니다. 앞의 네 단계로 실제 트레이스를 비교해 결정하세요.
SSR과 이미지 크기는 별도의 질문입니다
서버 사이드 렌더링은 초기 HTML 전달과 클라이언트 하이드레이션의 시점을 바꾸지만, 자동으로 LCP·INP를 개선하지는 않습니다. 응답 시간, 차단 리소스, 클라이언트 스크립트와 콘텐츠 구조를 함께 측정하세요. 이미지의 고유 크기나 비율을 제공하면 공간을 미리 확보해 레이아웃 이동을 줄이는 데 도움이 될 수 있습니다. 이것 역시 이미지 디코딩이나 폰트 교체 등 다른 이동 원인을 모두 없애지는 않습니다.
자료: MDN Critical rendering path, MDN How browsers work, Chrome DevTools Performance.