브라우저의 렌더링 과정을 설명할 수 있나요?

https://xionwcfm.tistory.com/156

요약 정리는 못 참지 않을까요? (13) 브라우저의 렌더링 과정

😑브라우저의 렌더링 과정을 설명해보아요

예전에 정리를 한 기억이 있긴 한데 복습을 한다는 마음가짐으로 정리하도록 하겠습니다.

키워드를 중심으로 이야기 하는 형식으로 작성했습니다.

 

브라우저의 렌더링 과정은 다음과 같습니다.

HTML, CSS , 자바스크립트, 이미지, 폰트파일 등 렌더링에 필요한 리소스를

먼저 서버에 요청하고 서버의 응답을 받아야합니다.

 

브라우저의 렌더링 엔진은 먼저 서버로부터 응답된 HTML 과 CSS를 파싱하여서

DOM과 CSSOM을 생성하고 이를 결합하여 렌더 트리를 생성시킵니다.

이러한 과정 탓에 HTML을 파싱하여 DOM을 다 그리기 전에 자바스크립트 파일을 동기적으로 읽어

DOM 요소와 상호작용하려고 해서는 안됩니다. 그렇기 때문에 자바스크립트 파일을 읽는

script 태그는 특별한 경우가 아니면 html의 하단부분에 삽입하는 것이 좋습니다.

 

브라우저의 렌더링 엔진은 HTML 문서를 파싱하며 그 과정은 일반적으로 다음과 같습니다.

먼저 이진수 형태로 온 서버의 응답을 읽어들이며 meta 태그의 charset 어트리뷰트에 의해 지정된

인코딩 방식을 기준으로 하여 이진수를 문자열로 변환하는 작업을 수행합니다.

그렇게 이진수를 문자 형태의 html로 변환하는 과정이 끝나면 이 html 문서를 토큰화 시킵니다.

이때 토큰화란 문법적 의미를 갖는 코드의 최소 단위로 코드들을 분해한다는 것을 말합니다.

 

이렇게 HTML 태그를 토큰화 시켜 얻은 토큰을 다시 객체로 변환하여 node를 생성합니다.

토큰의 내용에 따라서 문서 노드, 요소 노드, 어트리뷰트 노드, 텍스트 노드가 생성됩니다.

이러한 node들은 DOM을 구성하는 기본적인 요소가 됩니다.

 

이렇게 얻은 Node들을 이용해 부자관계를 반영하여 트리형태의 자료구조를 만듭니다.

이것이 바로 DOM 트리입니다.

 

렌더링엔진은 HTML을 순차적으로 파싱하며 설명한바와 같이 DOM을 생성해나가는데.

CSS를 로드하는 link 태그나 style 태그를 만나게되면 DOM 생성을 일시중단하고

바이트 -> 문자 -> 토큰 -> 노드 -> CSSOM의 과정으로 CSSOM을 생성합니다.

이렇게 CSS 파싱을 완료하면 다시 DOM 생성을 재개합니다.

 

이렇게 DOM과 CSSOM을 모두 완성한 렌더링 엔진은 렌더링을 위해 렌더 트리로 두 트리를 결합시킵니다.

렌더 트리는 브라우저 화면에 렌더링 되지 않는 meta 태그와 같은 태그들이나

CSS에 의해 표시되지 않는  노드(display:none)들은 렌더 트리에 포함되지 못합니다.

이 렌더트리는 각 HTMl 요소의 레이아웃을 계산하는 데 사용되면서 브라우저 화면에

픽셀을 렌더링하는 페인팅 처리에 입력됩니다.

 

이러한 레이아웃 계산과 페인팅은 예컨대 자바스크립트에 의해 노드가 추가되거나 삭제될 때 등

여러 상황에서 다시 실행될 수 있으며 이는 성능에 영향을 끼치게됩니다.

페인팅이 다시 실행되는 시점

 1. 자바스크립트에 의한 노드 추가 or 삭제
 2. 브라우저 창의 리사지이에 의한 뷰포트 크기 변경
 3. width/height , margin, padding, border, display, position, top , right, bottom, left 등
레이아웃 변경이 동반되는 스타일 변경 

 

또한 렌더링 엔진은 HTML을 순차적으로 파싱해나가면서 DOM을 생성해나가다가

link 태그를 만났을때와 같이 script 태그를 만나게되면 DOM 생성을 중단하고

자바스크립트 파일을 서버에 요청한 뒤

자바스크립트 엔진에게 제어권을 넘겨줍니다.

그리고 자바스크립트의 파싱과 실행이 종료되면 그때부터 다시 렌더링 엔진으로 제어권이 돌아오고

HTML 파싱을 시작하게됩니다.

 

이때 중요한 것은 자바스크립트를 파싱하고 실행하는 것은 브라우저의 렌더링 엔진이 아니라

자바스크립트 엔진이 처리한다는 것입니다. 이때 자바스크립트 엔진은 브라우저마다 다르게 사용하는데

구글 크롬과 브라우저는 아니지만 node.js 환경에선 v8엔진을 사용하고

파이어폭스에서는 SpiderMonkey 사파리에서는 JavaScriptCore를 사용합니다.

 

자바스크립트 엔진은 스크립트태그를 만나 제어권을 넘겨받게되면 자바스크립트 파일을 해석하여

AST라고 부르는 추상구문트리를 생성합니다. 그 뒤 추상구문트리를 기반으로

인터프리터가 실행할 수 있는 중간 코드인 바이트코드를 생성하여서 실행하게됩니다.

 

이렇게 자바스크립트와 CSS에 대한 처리를 하면서 HTML을 순차적으로 실행시키는 렌더링엔진을 통해

브라우저는 렌더링을 성공적으로 수행할 수 있습니다.

리플로우와 리페인트

만약 자바스크립트 코드에 DOM이나 CSSOM을 변경하는 DOM API가 사용된 경우엔
DOM이나 CSSOM이 변경되게 됩니다.
이렇게 변경된 DOM, CSSOM은 다시 렌더트리로 결합되고 변경된 렌더 트리를 기반으로
레이아웃과 페인트 과정을 거쳐 브라우저의 화면에 다시 렌더링되게 되는데

이것을 리플로우와 리페인트라고 부릅니다.

리플로우	레이아웃 계산을 다시 하는 것을 말합니다. 노드의 추가/삭제 , 요소의 크기/위치 변경 등 레이아웃에 영향을 주는 변경에 한해 실행됩니다.
리페인트	리페인트는 재결합된 렌더 트리를 기반으로 다시 페인트를 하는것을 말합니다.

이때 주의할 점은 리플로우와 리페인트가 항상 같이 실행되는 것은 아니라는 것입니다.

예컨대 레이아웃에 영향이 없는 변경은 리플로우 없이 리페인트만 실행될 수 있습니다.

 

body 요소의 가장 아래에 자바스크립트를 위치시키는 이유가 뭔가요?

 

브라우저의 렌더링 엔진은 자바스크립트 코드를 만나게되면 렌더링을 멈추고 자바스크립트 엔진에게

제어권을 넘겨주기 때문입니다. 이 과정에서 블로킹이 발생하게되기때문입니다.

또한 DOM이 완성되지 않은 시점에서 자바스크립트가 DOM을 조작하려고하면 오류가 발생할 수 있습니다.

 

다만 HTML5 부터는 script태그에 async , defer 어트리뷰트가 추가되어 이 문제를 어느정도 해결할 수 있어졌습니다.

다만 위 두 어트리뷰트는 외부 자바스크립트 파일을 로드하는 경우에만 사용할 수 있습니다.

 

async와 defer는 둘 다 비동기적 파일로드를 수행하지만 실행 시점의 차이가 있다.

async	async는 자바스크립트 파일의 로드가 완료된 직후 파싱과 실행을 시작합니다. 또한 먼저 로드가 완료된 순서로 실행되기에 순서가 보장되지 않습니다.
defer	defer 는 DOM 생성이 완료된 직후에 자바스크립트 파싱과 실행이 시작됩니다. (OM 생성이 완료되면 DOMConentLoaded 이벤트가 발생합니다.) 또한 defer는 순서가 보장됩니다.

https://wormwlrm.github.io/2021/03/01/Async-Defer-Attributes-of-Script-Tag.html

스크립트의 실행 시점을 조절하는 Async와 Defer 속성 - 재그지그의 개발 블로그

 

이래서 다들 defer를 쓰는거군요.. 하나 더 리마인드하고 갑니다.