[모던 JS 딥다이브] 38장. 브라우저의 렌더링 과정

naring·2024년 4월 8일

JavaScript 모던 javascript 딥다이브 브라우저의 렌더링 과정

Javascript

목록 보기

9/9

브라우저의 렌더링 과정은 웹 개발자라면 꼭! 꼭! 알고 있어야 할 필수 개념이다. 하지만 여기에도 저기에도 참 어렵게 설명이 되어있었는데, 모던 자바스크립트 딥다이브 책을 통해 쉽게 이해할 수 있었다!

아주 짧은 요약본

먼저 간단한 요약본을 통해 큰 틀을 먼저 보고 가자.
큰 과정은 다음 세 단계와 같다.

브라우저는 서버에서 HTML, CSS, 자바스크립트를 요청하고, 이를 응답받는다.
서버에서 응답받은 HTML, CSS, JS 를 파싱해 브라우저가 이해할 수 있는 객체 트리 구조를 만든다.
파싱이란?
텍스트 문서를 읽어 들여 실행하기 위해 필요한 과정으로,
1. 텍스트 문서(HTML 등)의 문자열을 토큰으로 분해하고
2. 토큰에 문법적 의미와 구조를 반영해 트리 구조의 자료구조인 파스트리를 생성하는 과정.
  일반적으로 파싱이 완료된 이후에는 파스트리를 기반으로 중간언어인 바이트코드를 생성해 실행한다.
해당 트리 구조를 기반으로 렌더링하여 사용자에게 보여준다.

렌더링이란?
HTML, CSS, JS로 작성된 문서를 파싱해 브라우저에 시각적으로 출력하는 것

이 중 핵심은 2번이다. 어떻게 HTML, CSS, JS를 파싱하는지, 그래서 어떤 순서로 트리가 만들어지는지를 한 단계 자세히 들여다보자.

요약본 : 브라우저가 렌더링하는 과정

2번 과정을 조금 더 상세히 들여다보면 2~4번과 같다.

HTML, CSS, JS, 이미지, 폰트 파일 등 렌더링에 필요한 리소스를 요청하고 서버에게서 응답 받음.
브라우저의 렌더링 엔진은 서버에게 받은 HTML, CSS를 파싱해 DOM, CSSOM 생성
DOM, CSSDOM을 결합해 렌더 트리 생성
브라우저의 자바스크립트 엔진은 서버로부터 응답된 자바스크립트를 파싱해 AST(Abstract Syntax Tree) 생성후 바이트 코드로 변환해 실행
이때 자바스크립트는 DOM API를 통해 DOM이나 CSSOM 변경 가능. 변경된 DOM, CSSDOM은 다시 렌더트리로 결합.
렌더트리를 기반으로 HTML 요소의 레이아웃을 계산하고 브라우저 화면에 HTML 요소 페인팅

이제 각각의 단계를 자~세히 들여다 보자.

38.1 요청과 응답

브라우저의 핵심 기능
필요한 리소스를 서버에 요청하고 응답받아 브라우저에 시각적으로 렌더링하는 것.

브라우저를 통해 서버에 요청 보내는 과정

브라우저 주소창에 URL을 입력하고 엔터 키 입력
URL의 호스트 이름이 DNS를 통해 IP 주소로 변환
이 IP 주소를 갖는 서버에게 요청 전송
- 이때 루트 주소로 보내면 암묵적으로 /index.html 요청
- 서버에게 index.html이 아닌 다른 정적 파일, 동적 데이터도 요청 가능하다.

38.2 HTTP 1.1과 HTTP 2.0

HTTP?

HyperText Transfer Protocol. 웹에서 브라우저와 서버가 통신하기 위한 프로토콜(규약).

1989년 HTML, URL과 함께 팀 버너스 리가 고안.

1991년 최초로 문서화되었고, 1996년 HTTP/1.0, 1999년 HTTP/1.1, 2015년 HTTP/2가 발표.

HTTP/1.1

기본적으로 커넥션 당 하나의 요청과 응답만 처리.
HTTP/1.1은 리소스의 동시 전송이 불가능한 구조.
- 즉 여러 개의 요청을 한 번에 전송할 수 없고 응답 또한 마찬가지.
- 따라서 HTML 문서 내에 포함된 여러 개의 리소스 요청 즉 CSS 파일을 로드하는 link, img tag, script 태그 등에 의한 리소스 요청이 개별적으로 전송되고 응답 또한 개별적으로 전송된다.
단점 : 요청할 리소스의 개수에 비례해 응답 시간도 증가

HTTP2

커넥션당 여러 개의 요청과 응답, 즉 다중 요청/응답이 가능.
따라서 HTTP/1.1보다 페이지 로드 속도가 50%정도 빠르다고 알려져 있다.
자세한 내용은 구글의 HTTP/2 소개 참고

38.3 HTML 파싱과 DOM 생성

파싱의 필요성

HTML 문서는 문자열로 이루어진 순수한 텍스트.
이러한 텍스트를 브라우저에 시각적인 픽셀로 렌더링하려면 HTML 문서를 브라우저가 이해할 수 있는 자료구조(DOM,Document Object Model)로 변환해 메모리에 저장해야 한다.
따라서 브라우저의 렌더링 엔진이 HTML → DOM으로 변환

HTML 파싱과 DOM 생성

서버가 HTML 파일 응답
이때 서버는 HTML 파일을 읽어들여 메모리에 저장한 다음 메모리에 저장된 바이트(2진수)를 인터넷을 경유해 응답
브라우저는 서버가 응답한 HTML 문서를 바이트 형태로 응답받는다.
그리고 응답된 바이트 형태의 HTML 문서는 meta 태그의 charset 어트리뷰트에 의해 지정된 인코딩 방식(ex UTF-8)을 기준으로 문자열로 변환.
참고로 메타 태그의 charset 어트리뷰트에 선언된 인코딩 방식은 응답 헤더에 담겨 응답된다. 브라우저는 이를 확인하고 문자열로 변환한다.
문자열로 변환된 HTML 문서를 읽어들여 문법적 의미를 갖는 코드의 최소 단위인 토큰들로 분해
각 토큰들을 객체로 변환해 노드를 생성.
토큰 내용에 따라 문서 노드, 요소 노드, 어트리뷰트 노드, 텍스트 노드가 생성. 노드는 이후 DOM을 구성하는 기본 요소가 된다.
HTML 문서는 HTML 요소들의 집합으로 이루어지며, HTML 요소는 중첩 관계를 갖는다. 즉 HTML 요소의 콘텐츠 영역에는 텍스트뿐만 아니라 다른 HTML 요소도 포함될 수 있다.
이때 중첩 관계에 의해 HTML 요소간 부모 자식 관계가 형성되고, 이러한 HTML 요소간 관계를 반영해 모든 노드들을 트리 자료구조로 구성된다.
이 노드들로 구성된 자료구조를 DOM이라 한다.

즉, DOM은 HTML 문서를 파싱한 결과물.

38.4 CSS 파싱과 CSSOM 생성

렌더링 엔진은 HTML을 처음부터 한 줄씩 순차적으로 파싱해 DOM 생성한다.

그러다가 렌더링 엔진이 CSS를 로드하는 link 태그나 style 태그를 만나면 DOM 생성 일시 중지한다. 그리고 먼저 CSS 파일을 HTML과 동일한 파싱 과정(바이트 → 문자 → 토큰 → 노드 → CSSOM)을 거치며 해석해 CSSOM을 생성한 뒤, HTML 파싱해 DOM 생성을 재개한다.

이때 CSS 파일이란?

link 태그의 href 어트리뷰트에 지정된 CSS 파일을 서버에 요청해 로드한 CSS 파일
style 태그 내 CSS

결국, HTML을 읽으며 DOM을 생성하는 과정 중에 link의 css 파일, style 태그를 만나면 그 즉시 CSSOM을 생성!!

CSSOM 상속

CSSOM은 CSS의 상속을 반영해 생성
예) body 요소에 적용한 font-size 프로퍼티와 ul요소에 적용한 list-style-type 프로퍼티는 모든 li 요소에 상속된다. 이러한 상속 관계가 반영되어 CSSOM 생성

38.5 렌더 트리 생성

렌더링 엔진은 서버로부터 응답된 HTML, CSS를 파싱해 각각 DOM, CSSOM을 생성하고, 이들은 렌더링을 위해 렌더트리로 결합한다.

렌더트리?

렌더링을 위한 트리 구조의 자료구조. 따라서 화면에 렌더링 되는 노드로만 구성된다.

렌더트리에는 브라우저 화면에 렌더링되지 않는 노드(meta, script 태그) 와 CSS에 의해 비표시 되는 노드들은 포함하지 않는다.(ex display : none)
이후 완성된 렌더트리는 각 HTML 요소의 레이아웃을 계산하는 데 사용하며 브라우저 화면에 픽셀을 렌더링하는 페인팅 처리에 입력된다.

렌더트리가 완성되고 이후 과정?

Reflow

렌더트리가 완성된 이후 브라우저는 각 요소가 화면의 어디에 위치해야 하는지 결정해야 한다. 이 과정을 Reflow(레이아웃 계산)라고 한다. 각 요소의 위치, 크기, 그리고 다른 요소들과의 상대적 관계는 CSS 속성들에 의해 결정된다.

Reflow에서 일어나는 계산

위치와 크기 결정: 각 요소의 width, height, margin, padding, border 등의 CSS 속성을 기반으로 요소의 크기와 화면 내 위치를 계산한다.
상위 요소와의 관계 계산: 요소들은 상위 요소에 영향을 받으며, 상위 요소의 크기 변경은 하위 요소의 위치와 크기를 재계산하게 할 수 있다.
보이지 않는 요소 처리: display: none과 같이 화면에 보이지 않아야 할 요소들은 레이아웃 계산에서 제외된다.

여기서 렌더트리가 어떻게 사용되나?
렌더 트리는 이 모든 정보를 가지고 있어, 레이아웃 계산 과정에서 각 요소의 정확한 위치와 크기를 결정하는 데 필수적. 이 과정을 통해 브라우저는 각 요소를 어디에, 어떻게 그릴지를 알게 되며, 이 정보를 바탕으로 최종적인 화면을 사용자에게 보여주게 된다.

Repaint

레이아웃 계산이 끝나고 각 요소의 정확한 위치와 크기가 결정되면, 브라우저는 실제로 요소를 화면에 그리는 과정, 즉 '페인팅' 처리를 시작한다. 이 과정에서는 렌더 트리에 있는 각 요소를 실제 픽셀로 변환하여 화면에 표시한다.

배경 그리기: 요소의 배경 색상이나 이미지를 그린다.
테두리 그리기: border 속성에 따라 요소의 테두리를 그린다.
텍스트 그리기: 텍스트의 크기, 색상, 폰트 등을 적용하여 화면에 표시한다.
기타 효과 적용: 그림자나 반투명 효과 같은 시각적 효과를 요소에 적용한다.

이때 레이아웃 계산, 페인팅을 다시 실행하는 리렌더링은 비용이 많으 드는 작업이기에 빈번하게 발생하지 않도록 주의해야 한다. 다음과 같은 경우 반복해서 레이아웃 계산과 페인팅이 실행된다.

자바스크립트에 의한 노드 추가 또는 삭제
브라우저 창의 리사이징에 의한 뷰포트 크기 변경
HTML 요소의 레이아웃 변경을 발생시키는 width/height, margin, padding, border, display, position, top/right/bottom/left 등의 스타일 변경

38.6 자바스크립트 파싱과 실행

HTML 문서를 파싱한 결과물로 생성된 DOM은 HTML 문서의 구조, 정보뿐만 아니라, HTML 요소와 스타일 을변경할 수 있는 인터페이스로서 DOM API를 제공한다.

즉, 자바스크립트 코드에서 DOM API를 사용하면 이미 생성된 DOM을 동적으로 조작할 수 있다.

→ 자세한 DOM 조작 방법은 39장 DOM 참고

자바스크립트 파싱 과정

DOM 생성 중 script 태(자바스크립트 파일을 로드하는 script 태그나 자바스크립트 코드를 콘텐츠로 담은 script 태그) 만나면 DOM 생성 일시 중단
이후 script 태그의 src에 정의된 자바스크립트 파일을 서버에 요청해 로드한 자바스크립트 파일이나 script 태그 내의 자바스크립트 코드를 파싱하기 위해 자바스크립트 엔진에 제어권을 넘긴다.
이후 자바스크립트 파싱, 실행이 종료되면 렌더링 엔진으로 다시 제어권을 넘겨 HTML 파싱 중단 지점부터 DOM 생성을 재개한다.

자바스크립트 파싱과 실행 : 자바스크립트 엔진이 처리

자바스크립트 엔진은 자바스크립트 코드를 파싱해 CPU가 이해할 수 있는 저수준 언어로 변환하고 실행
종류 : 구글 크롬과 Node.js의 V8, 파이어폭스의 SpiderMonkey, 사파리의 JavascriptCore 등
모든 자바스크립트 엔진은 ECMAScript 사양을 준수

AST(추상 구문 트리)

자바스크립트 엔진이 자바스크립트 코드를 파싱해 AST를 생성한다.
AST를 기반으로 인터프리터가 실행할 수 있는 중간코드인 바이트코드를 생성해 실행한다.

토크나이징

단순한 문자열인 자바스크립트 소스코드를 어휘 분석해 문법적 의미를 갖는 코드의 최소 단위인 토큰들로 분해한다. 이과 정을 렉싱이라고 부르기도 하지만 토크나이징과 미묘한 차이가 있다.

파싱

토큰들의 집합을 구문분석해 AST를 생성. AST는 토큰에 문법적 의미와 구조를 반영한 트리 구조의 자료구조.

토큰 + 문법적 의미 + 구조

AST는 인터프리터나 컴파일러만이 사용하는 것은 아니다. AST를 사용하면 Typescript, Babel, Prettier같은 트렌스파일러를 구현할 수도 있다. AST Explorer 웹사이트를 방문하면 다양한 오픈소스 자바스크립트 파서를 사용해 AST를 생성해 볼 수 있다.

바이트코드 생성과 실행

파싱의 결과물로 AST 생성.

→ 이는 인터프리터가 실행할 수 있도록 바이트코드로 변환.

→ 인터프리터에 의해 실행

이 중 실행이 자주되는 코드에 대해 최적화 하기도 함.

V8 엔진의 경우 자주 사용되는 코드는 터보팬이라 불리는 컴파일러에 의해 최적화된 머신코드로 컴파일되어 성능 최적화. 코드 사용 빈도가 적어지면 다시 디옵티마이징 하기도.

터보팬?

V8 엔진은 실행 중인 자바스크립트 코드를 분석하여 자주 사용되는 부분(핫 코드라고도 함)을 식별한다. 이러한 코드는 '터보팬(TurboFan)'이라는 고급 최적화 컴파일러에 의해 특수 처리되어 머신코드(하드웨어가 직접 실행할 수 있는 코드)로 컴파일된다. 이 과정에서 코드는 여러 최적화 단계를 거쳐 실행 속도가 크게 향상된다. 이러한 최적화는 변수의 타입 추론, 불필요한 코드 제거, 타이트한 루프 최적화 등을 포함할 수 있다.

디옵티마이징

한편, 코드의 사용 빈도가 시간이 지나면서 줄어들거나, 초기에 만들어진 가정(예: 변수의 타입이 변하지 않는다는 가정)이 더 이상 유효하지 않게 되면, V8 엔진은 최적화된 코드를 '디옵티마이징(deoptimizing)'할 수 있다. 디옵티마이징은 최적화 과정을 되돌려 더 일반적이고 유연한 코드로 전환하는 것을 의미한다. 이는 최적화 과정에서 적용된 가정들이 더 이상 유효하지 않게 되었을 때, 성능 저하를 방지하고 코드가 여전히 정확하게 실행될 수 있도록 보장하기 위해 필요하다.

정리

자바스크립트 코드 → 토크나이징 → 파싱 → AST 생성
→ 바이트 코드로 변환(인터프리터가 실행할 수 있도록) → 인터프리터에 의해 실행

38.7 리플로우와 리페인트

자바스크립트 코드에 DOM, CSSOM을 변경하는 DOM API가 사용된 경우 DOM이나 CSSOM이 변경된다.

이때 변경된 DOM, CSSOM은 다시 렌더트리로 결합되고, 변경된 렌더트리를 기반으로 레이아웃과 페인트 과정을 거쳐 브라우저의 화면에 다시 렌더링된다.

앞서 설명한 내용이니 간단히 보고 넘어가자.

Reflow

레이아웃 계산을 다시 하는 것
노드의 추가/삭제, 요소의 크기/위치 변경, 윈도우 리사이징 등 레이아웃에 영향을 주는 변경이 발생한 경우에 한해 실행

Repaint

재결합된 렌더 트리를 기반으로 다시 페인트 하는 것.
항상 리플로우 → 리페인트 순서대로 이뤄지는 것은 아니며, 리페인트만 실행되기도 한다.

앞서 설명한 내용과 상이해 헷갈릴 수 있어 덧붙이자면, reflow, repaint 과정은 첫 렌더링 시점에도 일어나고, DOM 또는 스타일의 변경이 있을 때 reflow와 repaint가 추가적으로 발생한다.

38.8 자바스크립트 파싱에 의한 HTML 파싱 중단

렌더링 엔진과 자바스크립트 엔진은 직렬적으로 파싱을 수행한다. 이는 script 태그의 위치에 따라 HTML 파싱이 블로킹되어 DOM 생성이 지연될 수 있다는 것을 의미한다. 따라서 script 태그의 위치는 중요한 의미를 갖는다.

script 태그의 위치에 따른 차이

직렬적으로 파싱을 수행한다는 것은 script 태그가 위쪽에 있으면, DOM 트리를 아직 다 그리지 못하고 script 태그가 실행된 것을 의미한다. 그런데 직렬적으로 파싱을 수행하기 때문에 script 태그를 읽고 파싱을 하는 동안에는 그저 렌더링 엔진은 기다려야 한다. 따라서 미리 DOM을 그리고 JS 코드를 파싱하는 것보다, 사용자가 보기에는 화면이 그려지지 않는 시간이 길게 된다.

렌더링 지연 외 또 다른 문제 : DOM 요소 부재

자바스크립트 코드에서 DOM, CSSOM을 변경하는 DOM API를 사용할 경우 DOM, CSSSOM이 이미 생성돼 있어야 한다. 만약 DOM을 변경하는 DOM API를 사용할 때 DOM의 생성이 완료되지 않은 상태라면 문제가 발생할 수 있다.

script 태그에 의한 블로킹 예시

...
<head>
...
	<script>
	cosnt $apple = document.getElementById('apple');
	$apple.style.color = 'red';
	</script>
</head>
<body>
	<ul>
		<li id='apple'>Apple</li>
		...
	</ul>
</body>
</html>

DOM API인 document.getElementById(’apple’)은 DOM에서 id가 apple인 HTML 요소를 가져온다.
하지만 이를 실행하는 시점에 id가 apple인 html요소가 파싱되지 않았기 때문에 DOM에는 해당 요소가 없다.
따라서 정상적으로 동작하지 않는다.

→ 이러한 문제를 회피하기 위해 body 요소의 가장 아래에 자바스크립트를 위치시키는 것이 좋은 아이디어다.

정리

script 태그가 body 아래에 있어야 하는 이유

DOM이 완성되지 않은 상태에서 자바스크립트가 DOM을 조작하면 에러 발생 가능
자바스크립트 로딩/파싱/실행으로 인해 HTML 요소들의 렌더링이 지장받는 일이 발생하지 않아 페이지 로딩 시간이 단축

38.9 script 태그의 async/defer 어트리뷰트

async/defer 등장 배경

자바스크립트 파싱에 의한 DOM 생성 중단 문제를 해결하기 위해 HTML5부터 script 태그에 async, defer 어트리뷰트가 추가

async/defer 사용 조건

다음과 같이 src 어트리뷰트를 통해 외부 자바스크립트 파일을 로드하는 경우에만 사용할 수 있다.
즉 src 어트리뷰트가 없는 인라인 자바스크립트에는 사용할 수 없다.

<script async src='extern.js'></script>
<script defer src='extern.js'></script>

async/defer 차이

async/defer 어트리뷰트를 사용하면 HTML 파싱, 외부 자바스크립트 파일의 로드가 비동기적으로 동시에 진행. 하지만 자바스크립트 실행 시점에 차이.

로드 → 파싱 → 실행 과정으로 이루어지는데, 로드→ 파싱까지는 동일하고 실행의 시점이 다르다 !

async 어트리뷰트

JS를 로드하는 동안까지는 HTML 파싱이 지속되며, 로드가 완료되면 직후 HTML 파싱이 멈추고 자바스크립트가 실행된다.
여러개의 script 태그에 async를 지정하면 로드 완료된 자바스크립트부터 먼저 실행돼 순서가 보장되지 않는다.
IE10 이상에서 지원

defer 어트리뷰트

async와 마찬가지로 JS 로드 동안까지 HTML 파싱이 지속된다. 단, JS 로드가 완료되었을 때 바로 JS를 실행시키는 것이 아니라, HTML 파싱이 모두 완료된 직후에 로드된 JS를 실행한다.
IE10 이상에서 지원

느낀점

언제나 너무 긴 설명으로 이해하기 어렵다고 생각했다. 하지만 역시 모던 자바스크립트 딥다이브를 찬찬히 읽다보면 슈루루룩 이해를 다 해버린 나를 발견한다! 인내심을 갖고 책을 천천히 정독해보자! 이웅모 개발자님 너무 감사합니다...!!
그리고 해당 포스트는 책 내용을 죽 설명해 둔 것이라 좀 길지만, 추후에 조금 더 이해하기 쉽고 간단하게 설명하는 컨텐츠를 발행해 보아야겠다!

참고

자바스크립트 딥다이브 38장 브라우저의 렌더링 과정, chatGPT 질문 활용

naring

개발은 즐거워

이전 포스트

[Javascript] 콜백함수란

1개의 댓글

Narcoker

2024년 4월 19일

좋은 글 잘 읽고 갑니다~~!!

답글 달기