[브라우저 렌더링 파이프라인] 브라우저는 어떻게 화면을 그릴까?

웹 페이지가 화면에 보이기까지 브라우저는 여러 단계를 거치게 되는데,

이 과정을 브라우저 렌더링 파이프라인(Rendering Pipeline)이라고 한다.

📌 파싱(Parsing)이란?

브라우저 렌더링 과정에 대해 알아보기 전에

먼저 파싱이라는 개념에 대해 작성해보려고 한다.

파싱(Parsing)은 텍스트 형태의 데이터를

문법적으로 분석하여 구조화된 데이터로 변환하는 과정을 말한다.

브라우저는 HTML 데이터를 받아서

이를 해석한 뒤에 DOM 트리라는 구조화된 데이터로 만들게 된다.

이러한 과정을 HTML 파싱이라고 한다.

1️⃣ HTML 파싱 → DOM 트리 생성

사용자가 브라우저에 어떤 사이트의 주소를 입력했을 때

서버가 그 주소에 해당하는 HTML 파일을 브라우저로 전송하게 된다.

이때 브라우저는 HTML 파일을 바이트 스트림(8비트 단위 데이터) 형태로 전달받아서

이를 문자 형태로 변환하고 토큰화(Tokenization) 과정을 수행하게 된다.

💡 참고)
브라우저 자체에서 바이트 스트림 형태로 최적화해서 가져옴 (HTTP 프로토콜에 의해)
실제로 개발자는 번들링/트랜스파일링 과정을 거쳐 청크 형태로 서버에 HTML, CSS, JS를 업로드함

토큰: 바이트 스트림이 HTML 코드인지 확인하는 일종의 설명서 같은 존재
토큰화: HTML 태그나 속성 등을 구분해 나가는 과정

토큰화 과정을 통해서 브라우저는 노드를 생성한다.

이렇게 만들어진 노드들이 모여서 최종적으로 DOM 트리가 완성된다.

노드: 토큰을 기반으로 만들어진 DOM 트리의 구성단위

💡 참고) DOM트리를 생성할 때
<img>나 <link>와 같은 태그들을 만나면 브라우저는 해당 태그 안에 명시되어 있는 리소스를 다운로드한다.
<script> 태그를 만나면 브라우저는 DOM 생성을 잠시 멈추고 스크립트 코드를 해석한다.

2️⃣ CSS 파싱 → CSSOM 트리 생성

CSS 파싱 과정은 HTML 파싱과 매우 유사하다.

서버에서 받은 CSS 코드(바이트 데이터)를 문자로 해석한 뒤

토큰화 과정을 거쳐 CSSOM(CSS Object Model) 트리를 생성한다.

3️⃣ 렌더 트리(Render Tree) 생성

브라우저는 DOM 트리와 CSSOM트리를 합쳐서 렌더 트리를 생성한다.

렌더 트리는 화면에 실제로 표시될 요소들로만 구성되기 때문에

<head> 안의 <script>, <meta> 등 비시각적인 요소나

display: none이 적용된 요소는 렌더 트리에 포함되지 않는다.

💡 접근성을 위해 스크린리더에는 읽히지만 시각적인 요소를 숨겨줘야 한다면
display: none은 렌더 트리에 포함되지 않기 때문에 사용하면 안 된다.
접근성을 고려한다면 아래와 같은 방식을 사용해야 한다.
https://cocoding420.tistory.com/17

접근성 고려하기(Aria-label, sr-only)

1. Aria-labelaira-label은 웹 페이지에서 스크린 리더 사용자에게 정보를 전달하는 데 사용되는 HTML 속성요소가 시각적으로는 명확한 정보를 제공하지만 스크린 리더 사용자들이 이해하기 힘들기 때

cocoding420.tistory.com

4️⃣ 레이아웃(Layout)

렌더 트리를 기반으로 각 요소의 크기와 위치를 계산하는 과정이다.

레이아웃 과정에서 레이아웃 트리가 생성되고

좌표, 박스 크기 등 렌더링에 필요한 정보가 담기게 된다.

5️⃣ 페인트(Paint)

페인트 단계에서는 레이아웃 정보를 바탕으로 페인트 기록을 생성한다.

페인트 기록에는 페이지를 여러 개의 레이어로 나누고 텍스트, 색, 이미지와 같은

시각적인 부분을 그리는 작업과 요소를 렌더링 하는 순서가 담기게 된다.

6️⃣ 컴포지팅(Compositing)

페인트 단계까지 완료하게 되면 브라우저는 컴포지팅 단계를 진행한다.

컴포지팅 단계에서는 페인트 단계에서 만들어둔 레이어들을 스크린에 픽셀로 표현하고

나누어져 있던 레이어들을 하나로 합성해서 페이지를 완성하게 된다.

💡 컴포지팅 단계에서는 GPU을 활용한다.

브라우저는 위 과정을 거쳐서 화면에 HTML, CSS, JS를 표현하게 된다.

하지만 CSS를 수정해서 화면에 보이는 레이아웃이 변경될 때

일련의 단계가 다시 수행되게 되는데 그 과정들을 정리해 보려고 한다.

🔄 리플로우(Reflow)

리플로우는 브라우저가 레이아웃을 다시 계산해야 할 때 발생한다.

DOM 트리와 CSSOM 트리를 기반으로 만들어진

렌더 트리를 다시 생성하거나 갱신하는 작업을 말한다.

(→ 4. 레이아웃 과정이 다시 진행되는 것)

🧐 리플로우가 발생하는 경우

레이아웃에 영향을 주는 속성이 변경되었을 때
- position, left, top, right, bottom
- width, height, margin, padding, border
- display, float, overflow
- font-family, font-size, font-weight, line-height, text-align, vertical-align 등
DOM 구조가 변경되었을 때
- 노드 추가/삭제
- 노드 이동 (appendChild, insertBefore 등)
브라우저의 크기가 변경되었을 때 (반응형 레이아웃)

브라우저에게 있어서 레이아웃을 변경하는 리플로우 작업은

상당히 부담이 많이 되는 연산이기 때문에 리플로우를 최소화시키는 것이 중요하다.

🎨 리페인트(Repaint)

리페인트는 레이아웃에 변화는 없지만 시각적인 스타일이 변경될 때 발생한다.

요소의 위치나 크기는 그대로이고 색상, 배경, 그림자와 같은

시각적 요소가 변경되는 경우를 말한다.

(→ 5. 페인팅 과정이 다시 진행되는 것)

🧐 리페인트가 발생하는 경우

background
color
box-shadow
border-radius, border-style
outline, text-decoration 등

리플로우보다는 비교적 부담이 적지만,

리페인트도 자주 일어나게 되면 성능에 영향을 끼칠 수 있으니 주의해야 한다.

🧩 리플로우와 리페인트의 관계

리플로우가 발생하면 항상 리페인트도 발생한다.

→ 레이아웃이 변경되면 화면을 다시 그려야 하기 때문에

리페인트는 리플로우 없이도 실행될 수 있다.

→ 사용자가 변경한 CSS 속성이 레이아웃의 영향이 없는 변경이라면 리플로우 없이 리페인트와 컴포지팅만 실행된다.

💡 참고
width를 변경하면 → 레이아웃 다시 계산해서 배치(reflow) → 다시 그려냄(repaint) → compositing
color만 변경하면 → 레이아웃 변화 없음 → 리페인트만 수행 → compositing

⚡ 최적화 팁

애니메이션에는 position이나 top 대신 transform을 활용하는 것이 성능상 유리하다.
(transform: translateX(100px) → 리플로우/리페인트를 건너뛰고 GPU 레벨에서 합성 단계만 다시 수행)
opacity도 마찬가지로 리플로우/리페인트를 생략할 수 있어 성능에 좋다.
불필요한 리플로우를 막기 위해 DOM 조작은 한 번에 모아서(batch) 처리하는 것이 좋다.

📚 참고

https://www.youtube.com/watch?v=z1Jj7Xg-TkU

https://yozm.wishket.com/magazine/detail/2909/

브라우저가 화면을 그리는 방법, 렌더링 과정 이해하기 | 요즘IT

렌더링(Rendering)이란, 브라우저가 HTML, CSS, Javascript를 해석해, 우리가 보는 화면에 실제로 나타내는 과정을 말합니다. 단순히 파일을 읽는 것만 아니라, 웹 페이지의 구조를 분석하고 스타일과 스

yozm.wishket.com

728x90

📌 파싱(Parsing)이란?

1️⃣ HTML 파싱 → DOM 트리 생성

2️⃣ CSS 파싱 → CSSOM 트리 생성

3️⃣ 렌더 트리(Render Tree) 생성

4️⃣ 레이아웃(Layout)

5️⃣ 페인트(Paint)

6️⃣ 컴포지팅(Compositing)

🔄 리플로우(Reflow)

🧐 리플로우가 발생하는 경우

🎨 리페인트(Repaint)

🧐 리페인트가 발생하는 경우

🧩 리플로우와 리페인트의 관계

⚡ 최적화 팁

📚 참고

티스토리툴바