브라우저 렌더링 과정 (CRP)
한 줄 답변
브라우저 렌더링은 HTML, CSS, JavaScript를 파싱하여 화면에 그리는 과정입니다. DOM/CSSOM 트리 생성, 렌더 트리 구축, 레이아웃(Reflow), 페인트(Repaint) 단계를 거치며, 성능 최적화를 위해 Reflow를 최소화하는 것이 핵심입니다.
핵심 개념 정리
브라우저 렌더링 과정(Critical Rendering Path, CRP)은 브라우저가 서버로부터 HTML, CSS, JavaScript 등의 리소스를 응답받아 화면에 픽셀 형태로 렌더링하기까지의 일련의 단계를 의미합니다. 프론트엔드 성능 최적화의 핵심 기반이 되는 개념이므로 면접에서 매우 빈번하게 출제됩니다.
첫 번째 단계는 파싱(Parsing)입니다. 브라우저의 렌더링 엔진은 HTML 문서를 파싱하여 DOM(Document Object Model) 트리를 구축하고, CSS를 파싱하여 CSSOM(CSS Object Model) 트리를 만듭니다. 이때 HTML 파싱 중 `<script>` 태그를 만나면 제어권이 자바스크립트 엔진으로 넘어가 파싱이 블로킹될 수 있으므로, `defer`나 `async` 속성을 적절히 활용하는 것이 중요합니다.
두 번째 단계는 렌더 트리(Render Tree) 구축입니다. 완성된 DOM 트리와 CSSOM 트리를 결합하여 렌더 트리를 생성합니다. 렌더 트리는 화면에 표시되는 노드들로만 구성되므로, `display: none`이 적용된 요소는 제외되지만 `visibility: hidden`이 적용된 요소는 화면에 보이지 않아도 공간을 차지하므로 렌더 트리에 포함됩니다.
세 번째는 레이아웃(Layout) 또는 리플로우(Reflow) 단계입니다. 렌더 트리를 기반으로 뷰포트 내에서 각 요소의 정확한 크기와 위치를 계산합니다. 브라우저 창의 크기를 조절하거나 요소의 기하학적 속성이 변경될 때 다시 발생합니다. 마지막으로 계산된 결과를 화면의 픽셀로 그리는 페인트(Paint) 단계와, 분리된 레이어들을 합성하는 컴포지팅(Compositing) 단계를 거쳐 최종 화면이 출력됩니다.
비교 정리
| 항목 | Layout (Reflow) | Paint (Repaint) |
|---|---|---|
| 유발 원인 | 요소의 크기, 위치 변경 (width, height, margin 등) | 요소의 시각적 속성 변경 (color, background, box-shadow 등) |
| 성능 영향 | 레이아웃 계산 후 페인트까지 다시 발생하므로 비용이 큼 | 레이아웃 단계를 건너뛰고 색상만 칠하므로 리플로우보다 비용이 적음 |
| 최적화 방법 | transform, opacity 등을 활용하여 GPU 가속(컴포지팅) 유도 | 변경이 잦은 요소를 별도의 레이어로 분리 (will-change 속성 활용) |
| CSS 속성 예시 | position, top, left, width, padding, font-size | background-color, border-radius, color, visibility |
면접에서 이렇게 답하세요
브라우저 렌더링 과정을 단순히 나열하기보다는, 각 단계에서 발생할 수 있는 병목 현상과 이를 해결하기 위한 '성능 최적화 경험'을 연결하는 것이 좋습니다. 예를 들어 "애니메이션 구현 시 left, top 대신 transform을 사용하여 Reflow를 방지하고 프레임 드랍을 개선했다"와 같이 실제 실무나 프로젝트에서의 트러블슈팅 사례를 덧붙이면 면접관에게 깊은 인상을 줄 수 있습니다.
자주 묻는 추가 질문
Q. DOM 요소의 display: none과 visibility: hidden의 렌더링 관점에서의 차이는 무엇인가요?
display: none은 렌더 트리에서 완전히 제외되어 Layout과 Paint가 발생하지 않습니다. 반면 visibility: hidden은 렌더 트리에 포함되어 공간을 차지하므로 Layout 과정에 영향을 줍니다.
Q. <script> 태그를 <body> 최하단에 배치하는 이유는 무엇인가요?
HTML 파싱 중 스크립트를 만나면 파싱이 멈추기(블로킹) 때문입니다. 최하단에 두거나 defer/async 속성을 사용하여 DOM 생성을 방해하지 않고 렌더링 초기 속도를 높일 수 있습니다.
Q. 리액트의 Virtual DOM은 렌더링 최적화에 어떻게 기여하나요?
상태 변경 시 실제 DOM을 즉시 조작하지 않고, 메모리 상의 Virtual DOM과 비교하여 변경된 부분만 일괄 업데이트(Batching)함으로써 Reflow와 Repaint 횟수를 줄여줍니다.
커뮤니티 하이라이트
“면접관이 진짜 듣고 싶어하는 건 순서 암기보다 '그래서 어떻게 최적화할 건데?' 입니다. 리플로우 방지 사례 하나쯤은 꼭 준비해 가세요!”
“개발자 도구의 Performance 탭에서 실제 CRP를 프로파일링하고 분석해본 경험을 이야기했더니 아주 좋은 평가를 받았습니다.”
32명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.