수업 중 강사님께서 Reflow와 Repaint에 대해 언급하셨고, 이에 대해 자세히 공부해보라는 말씀에 이번 기회에 브라우저 랜더링에 대해 알아 보았습니다.
우선, 웹브라우저는 어떤 일을 할까요? 우리가 작성한 HTML, CSS, Javascript를 읽고 웹페이지를 그려주는 일을 하는데요.
이때, 브라우저에서 어떤 일이 일어나는지를 알아봅시다.
아래는 웹 브라우저의 기본 구조를 보여주는 그림과 설명입니다.
웹 브라우저의 구조
(1) 사용자 인터페이스(User Interface)
웹 페이지를 제외한 주소 표시줄, 이전/다음/새로고침 버튼, 북마크 등 사용자와 상호작용하는 부분
(2) 브라우저 엔진(Browser Engine)
유저 인터페이스와 렌더링 엔진 사이에서 동작을 제어하고 연결하는 엔진
(3) 렌더링 엔진(Rendering Engine)
HTML과 CSS를 파싱하여 요청한 웹 페이지(콘텐츠)를 표시하는 엔진
(4) 자료 저장소(Data Persistence)
로컬 저장소(localStorage)나 쿠키(Cookie)와 같이 보조 기억장치에 데이터를 저장하는 파트
(5) 통신(Networking)
각종 네트워크 요청을 수행하는 파트
(6) 자바스크립트 해석기(Javascript Interpreter)
자바스크립트 코드를 실행하는 파트
(7) UI 백엔드(UI Backend)
예를 들어, 콤보박스나 창과 같은 기본적인 장치를 그려주는 UI 백엔드 파트
이 중에서 우리는 렌더링 엔진에 대해 자세히 알아봅시다.
우선, 여러 브라우저는 각 브라우저마다 다른 렌더링 엔진을 사용합니다. (Safari는 Webkit, Firfox는 Gecko, Chrome은 Blink 등)
모든 렌더링 엔진은 웹표준을 준수하면서도 엔진마다 조금씩 다르게 동작하는 부분이 있습니다.
렌더링 엔진은 두가지 목표를 가집니다.
HTML, CSS, JS, 이미지 등 웹페이지에 포함된 모든 요소들을 화면에 보여줍니다.
업데이트가 필요할 때, 효율적으로 렌더링을 할 수 있도록 자료 구조를 생성합니다.
(업데이트의 예 : 사용자에 의한 입력 발생, 스크롤, 애니메이션, 비동기 요청으로 인한 데이터 로딩 등)
이런 목표를 위해서 렌더링 엔진은 크게 다음의 과정을 거쳐서 동작합니다.
(1) DOM Tree 생성
위 예시의 마크업 코드는 토큰화(Tokenization) 과정을 거쳐 HTML5에서 정의한 고유한 토큰으로 변환됩니다.
이후 브라우저는 트리 구성(Tree Construction) 단계를 통해 토큰을 노드 객체로 변환하고, 최종적으로 DOM 트리를 만듭니다.
(요소와 속성, 텍스트를 계층적 노드 구조로 표현한 객체 모델)
또한, 브라우저는 HTML을 파싱하는 과정에서 자바스크립트나 CSS와 같은 필요한 파일들을 불러오기도 하는데, 브라우저는 DOM Tree를 생성하듯이 CSS를 파싱하여 CSSOM Tree를 생성합니다.
(2) CSSOM Tree 생성
DOM Tree와 CSSOM Tree가 모두 생성되면, 렌더링 엔진이 DOM Tree와 CSSOM Tree를 합쳐서 Render Tree를 생성합니다.
(3) Render Tree 생성
(참고로 간소화한 랜더트리입니다. 실제로는 더 많은 정보를 가지고 있고, 브라우저마다 조금씩 다르게 생성됩니다.)
Render Tree는 화면에 표시되어야 할 모든 노드의 컨텐츠, 스타일 정보를 포함하는 트리를 말합니다.
이때, meta태그나 display:none;같은 속성은 트리에 포함하지 않습니다.
Render Tree가 생성되면, Layout이라는 과정을 거칩니다
뷰포트 내에서 요소들의 정확한 위치와 크기를 계산하는 과정으로 박스 모델에 따라서 텍스트나 요소의 박스가 화면에서 차지하는 영역이나 여백 그리고 이외의 스타일 속성이 계산됩니다.
레이아웃 과정에서 렌더링 엔진이 각 요소들이 어떻게 생겼고, 어떻게 보여줘야 할지 알게 되면 화면에 실제 픽셀로 그려지도록 변환하는 과정을 거치는데, 이를 Paint 과정이라고 합니다.
이렇게 렌더링 엔진이 어떻게 동작하는지를 알아봤습니다.
위에서 알아 본 핵심 렌더링 경로(Critical Rendering Path)의 시간을 줄이면, 브라우저가 웹 페이지를 보여주는 시간도 줄일 수 있게 됩니다.
그런데 사용자 동작으로 자바스크립트가 실행되어서 CSS가 변경되거나 애니메이션 재생이 일어났을 때 무슨 일이 일어날까요?
이런 경우 3가지의 상황이 생길 수 있습니다.
UI가 업데이트되는 3가지 상황
1. Reflow (리플로우)
- 정의: 요소의 크기나 위치가 변할 때, 브라우저가 레이아웃을 다시 계산하는 과정.
- 발생 조건:
- 브라우저 창 크기 변경
- 크기(높이, 너비, margin 등) 변경
- 위치(position, left/right 등) 변경
- 레이아웃(display, flex 등) 변경
- 폰트 크기/굵기(font-size, font-weight 등) 변경 - 과정: 레이아웃 → 페인트 → 합성
- 특징: 부모의 변화가 자식에게 전파되며 CPU 부하가 큼. 성능에 가장 큰 영향을 미침.
2. Repaint (리페인트)
- 정의: 요소의 시각적 표현(색상 등) 만 변할 때, 다시 화면에 그리는 과정.
- 발생 조건:
- 색상(color, background-color 등) 변경
- 테두리(border-color, border-radius 등) 변경
- 그림자(box-shadow 등) 변경 - 과정: 페인트 → 합성
- 특징: 레이아웃은 변하지 않고 GPU를 주로 사용. 상대적으로 비용이 적음.
3. 레이어 합성만 발생하는 경우
- 레이아웃, 페인트 없이 합성 단계만 다시 실행.
- 가장 성능 이점이 큼.
- 예: transform, opacity 변경 시.
4. 성능상 차이
- Reflow: CPU 의존, 부모→자식 영향 전파 → 비용 큼.
- Repaint: GPU 의존, 독립적 요소만 다시 그림 → 비용 적음.
- 따라서 최적화에서는 Reflow를 최소화하는 것이 핵심.
그렇다면, Reflow를 최소화 하는 방법을 알아볼까요?
5. Reflow를 최소화 하는 방법
(1) DOM 업데이트 배치 (Batch Update)
- DOM 조작을 모아 한 번에 처리.
(2) 계산 값 재사용
- 요소 크기/위치 값을 변수에 저장 후 재사용.
(3) 레이아웃 변경 최소화
- flex, grid 대신 absolute, fixed와 같이 독립적인 레이아웃 사용.
(4) GPU 활용
- transform: translate3d(x, y, 0)
- will-change 속성으로 변화 예상 힌트 제공.
(5) 애니메이션 최적화
- transform, opacity 기반 애니메이션 사용.
- transition/animation 활용.
(6) CSS contain 속성 활용
- 특정 요소의 레이아웃/스타일/페인트 영향 범위를 제한.
이상 Reflow, Repaint와 같은 브라우저 렌더링에 대해 알아본 내용이었습니다. 감사합니다 :)
참고 자료 : https://www.youtube.com/watch?v=sJ14cWjrNis
https://www.youtube.com/watch?v=TZz9VHjJzMk
