😦 브라우저의 렌더링 과정

해당 포스트는 자세하게 브라우저의 모든 렌더링 과정을 정리하는 것이 아닌 필자 기준으로 현재 이해하고 있는 만큼만 렌더링 과정을 정리하는 포스트입니다.

🔎 브라우저란

브라우저란 HTML, CSS, JavaScript로 작성된 파일을 파싱해서 화면에 렌더링해주는 프로그램입니다.

간단하게 요약하자면 HTML, CSS, JavaScript 파일을 해석해서 사용자가 보기 좋도록 화면을 그려주는 프로그램입니다.

더 구체적으로는 사용자 인터페이스, 브라우저 엔진, 통신, UI 백엔드, JS 해석기, 자료 저장소 등 많은 기능들이 내장되어 있지만 현재 포스팅에 필요한 기능만 작성하겠습니다.

🛫 통신 요청

브라우저의 검색창에 특정 URL을 검색하게 되면 통신 요청을 하게 됩니다.

예를 들어 www.naver.com로 검색하게 된다면 DNS를 통해서 일치하는 IP주소를 찾고 해당 주소를 갖는 서버로 요청을 전달합니다.

• CMD를 통해서 ping www.naver.com 명령을 해보면 www.naver.com의 IP주소를 알 수 있으며, IP주소를 이용해서 검색하면 www.naver.com과 같은 페이지를 볼 수 있습니다.

서버는 요청을 확인하고 정해진 응답을 하게 됩니다.

• 정해진 응답이란 특정 HTTP메서드와 URI의 조합으로 요청을 보내면 서버측에서는 그에 맞게 응답을 미리 정해놨습니다. 그 응답을 정해진 응답이라고 표현했습니다.
  ( html, json, 이미지, 폰트 등의 여러가지 리소스를 응답할 수 있습니다. )

암묵적으로 요청은 index.html을 요청하는 것과 같으므로 www.naver.com/index.html에 요청을 하는 것과 같고 서버에서는 해당하는 html을 응답하게 됩니다.

실제로 www.naver.com과 www.naver.com/index.html를 들어가보게 되면 같은 응답을 받는 것을 확인할 수 있습니다.

www.naver.com에서 네트워크 패널을 열고 요청을 해보면 이상하게도 index.html외에 많은 파일들을 요청하는 것을 확인할 수 있습니다.
JavaScript, CSS, 폰트, 이미지 등의 리소스들을 요청하게 되는데 이것을 최초 요청한 index.html을 파싱하는 도중에 index.html 내부에서 <script>나 <link>로 인해서 요청하는 파일들이기 때문에 추가적으로 요청하는 것입니다.

🛠️ HTML/CSS 파싱

앞서 통신 요청으로 인해서 html을 받아왔다면 html을 브라우저 자체적으로 파싱하게 됩니다.
파싱하는 이유는 html은 일반 텍스트와 다를게 없기 때문에 브라우저에서 이해하고 화면에 그려주기 위해서는 DOM 형태로 변환시켜줘야 하기 때문입니다.

HTML을 파싱해서 DOM으로 변환시켜주면 JavaScript에서도 이해할 수 있고 브라우저도 이해하고 렌더링이 가능하기 때문입니다.

HTML을 파싱하는 과정에서 CSS나 JavaScript 등의 리소스를 필요하게 된다면 일단 HTML 파싱을 중지하고 요청한 CSS나 JavaScript부터 통신 요청을 통해서 요청하고 CSS를 요청했다면 CSS를 먼저 파싱해 CSSOM을 만들고 나서 다시 HTML파싱을 이어가게 됩니다.

HTML을 일반 텍스트와 다를게 없다고 표현한 이유는 변수, 반복문, 조건문, 자료구조등이 없는 언어라서 프로그래밍 언어라고 생각하지 않기 때문입니다. ( 물론 개인적인 생각입니다. )

⚒️ JavaScript 파싱

이전에 말한 HTML을 파싱하는 도중에 JavaScript를 요청하게 된다면 HTMl파싱을 일시 중지하고 JavaScript를 리소스를 요청합니다.
JavaScript 파일을 응답받으면 각 브라우저가 가진 JavaScript 엔진을 통해서 파싱을 통해 AST를 만들고 실행하게 됩니다.

파싱한 JavaScript를 통해서 DOM이나 CSSOM이 변경되게 된다면 리플로우와 리페인팅이 실행되게 됩니다.

🧹 렌더 트리 생성

앞서 HTML과 CSS를 파싱해서 DOM과 CSSOM을 생성했다면 DOM과 CSSOM을 합쳐서 렌더 트리를 생성하게 됩니다.

렌더 트리는 실질적으로 브라우저가 화면을 렌더링할 때 사용하게 됩니다.

실질적으로 화면에 렌더링할 때 사용하는 트리이므로 화면에 렌더링되지 않는 노드들은 포함되지 않습니다.
예를 들어 display: none;같은 속성을 가진 노드나 <script>노드는 실제로 화면을 그리는데는 전혀 영향을 주지않기 때문에 렌더 트리에서는 완전히 제외됩니다.

🧭 레이아웃

렌더 트리를 완성한 이후에는 실제로 요소들이 화면에 렌더링 되기 위한 레이아웃을 결정하게 됩니다.
레이아웃이란 화면에 어느 위치에 어떤 요소가 그려질지를 결정하는 것을 말합니다.
레이아웃 과정에서는 상대적인 단위를 갖는 요소들을 모두 절대적인 단위인 px로 변경합니다.
예를 들어 %, em, vw같은 특정 크기를 기준으로 값이 결정되는 요소들에 구체적인 px값이 지정되게 됩니다.
그리고 그 구체적인 값을 통해서 각 노드들의 구체적인 위치와 크기가 결정됩니다.

🖌️ 페인팅

페인팅이란 레이아웃에 의해서 구체적인 위치를 가진 노드들 즉, 렌더 트리를 이용해서 브라우저의 화면에 렌더링하는 과정을 의미합니다.

페인팅이 끝나게 되면 사용자는 완성된 결과물을 화면으로 볼 수 있게 됩니다.

✏️ 리플로우

사용자의 어떠한 액션을 통해서 JavaScript의 이벤트가 실행되어 DOM이나 CSSOM이 변경되어 레이아웃을 다시 계산하는 행위를 의미합니다.

리플로우가 발생한다면 반드시 리페인트가 발생하게 됩니다.

✍️ 리페인트

리플로우로 인해서 재결합된 렌더 트리를 다시 페인트하는 것을 의미합니다.
하지만 리플로우에 의해서 실행되는 것만이 아니고 레이아웃외에 다른 것이 변경된다면 리페인트만 발생하게 됩니다.

🐲 요약

1. 브라우저를 통해 특정 URL을 검색한다.
2. DNS를 통해 URL에 매칭되는 IP주소를 얻고 요청을 보낸다
3. 해당 IP주소에 의해 응답된 리소스를 받는다.
4. HTML이라면 브라우저가 이해하고 렌더링할 수 있는 DOM으로 파싱한다.
5. HTML을 파싱하는 도중에 리소스를 요청한다면 DOM의 파싱을 일시 중지하고 다른 리소스를 먼저 요청한 뒤 CSS나 JavaScript의 응답이 온다면 DOM보다 먼저 파싱한다.
   5-1. CSS는 브라우저가 이해하고 렌더링할 수 있는 CSSOM으로 파싱한다.
   5-2. JavaScript라면 브라우저 자체적으로 내장된 자바스크립트 엔진을 통해서 AST를 생성하고 바이트 코드로 변화한다.
6. HTML파싱이 끝나면 DOM과 CSSOM을 결합해서 렌더 트리를 생성한다.
7. 렌더 트리를 화면에 렌더링하기 위해 상대적인 단위를 절대적인 단위로 변경해 각 노드의 위치와 크기를 결정하는 레이아웃과정을 거친다.
8. 마지막으로 페인팅을 해서 유저가 보기 좋도록 렌더 트리를 브라우저에 렌더링한다.
9. 유저의 특정 액션을 통해서 DOM이나 CSSOM이 변경된다면 리플로우와 리페인트를 거쳐서 다시 화면을 렌더링한다.

유저의 특정 액션이란 브라우저의 크기를 변경하는 행위(상대적인 크기들이 변경된다.)나 JavaScript의 이벤트를 통해서 노드를 생성하거나 스타일을 변경하는 행위 등을 말합니다.