[Browser] 브라우저는 어떻게 html을 이해할까?

 

브라우저가 html, css, javascript를 이해하고 뿌려주는(?) 방식인  Rendering path에 대하여 알아보자.

브라우저의 사고방식을 이해한다는게 재미있다. 정말로..

.

 

---

Rendering path

 

Rendering path를 통해 브라우저는 html, css, javascript를 픽셀로 변환하여 우리 눈에 보이게끔 화면에 뿌려준다.

Render tree까지를 constructor, layout부터를 operation 두 단계로 나눈다.

 

---

Constructor

 

network -> request / response -> loading -> scripting -> Render tree

 

= 

 

네트워크 -> 데이터 요청 -> 데이터를 받아옴 -> DOM, CSSOM 으로 변환 -> DOM + CSSOM

 

*Render tree란?

DOM 과 CSSOM의 콜라보레이션.

 

*CSSOM 이란? 

브라우저가 html정보를 이해하기 위해 dom형태 변환시킨것 마찬가지로

css정보를 브라우저가 이해하기위해 바꾼 형태를 말한다. 

기본적으로 cascading 방식을 따른다.

 

CSSOM

 

DOM+CSSOM = Render tree

 

단, render tree는 그렇게 호락호락하지않다.

DOM이나 CSSOM에서 눈에 보이지 않는 부분은 포함시키지 않는다.

위의 그림을 잘 보면 html의 head태그 부분이나 css에서 {display:none}이 적용된 부분은 사라진 걸 확인할 수 있다.

 

---

Operator

 

layout -> paint -> *composition

 

layout : 레이아웃을 구상한다.

 

paint : 각각의 요소들을 레이어 별로 준비'만' 해놓는다.

레이어로 준비해놓는 이유? 

수정할 떄 전체 레이아웃을 바꿀 필요없이 해당 레이어만 바꾸면 되기에 성능이 개선된다.

 

*composition : 준비한 레이아웃을 세팅한다

 

- 레이어 순서대로

- z-index 순서대로

- ...

 

요소의 변경(animation , transform등)이 일어날 떄 성능이 보장되는 순서는 다음과 같다.

BEST - 요소의 위치만 변경하면 될 떄 (composition).

SO SO - 요소를 아예 다른 이미지요소로 바꾸어야 할 떄(paint).

WORST - 요소를 바꾸는데 다른 요소의 위치나 크기 등 마저 바꾸어야 할 때(layout)

 

흠 그럼 어떤걸 쓸 떄 좋고 안 좋은지 어떻게 알지요?

바로 아래 사이트에서 어떤 속성(width, opacity, transfrom 등등)이 변경 되었을 떄 composition ,paint ,layout이 일어날지 확인할 수 있는 좋은 사이트가 있다.

브라우저의 성능 개선에 대한 고민이 필수적인 프론트 엔드 개발자에겐 반드시 즐겨찾기 해놓아야 할 페이지이다.

 https://csstriggers.com/ 

CSS Triggers

 

기억하자.

composition만 일어났을 때가 성능 최고, paint는 쏘쏘, layout 은 최악의 성능을 선사한다는 것을.

---

정리해보자.

rendering path 를 통해 브라우저는 화면에 html, css, javascript를 보이게 해준다.

rendering path엔 constructor과 operator 두 단계가 있다.

첫 번째 constructor 단계에서

정보를 요청, 받아오기, dom과 cssom으로 변환 후 합친 결과인 render tree를 만들어 낸다.

두 번쨰 operator 단계에서

만들어진 render tree를 기반으로 요소를 어떤 자리에 위치시킬지 구상, 각각의 요소를 미리 준비만 시켜놓는다(아직 세팅은x), 준비한 레이아웃을 세팅한다.

이때 요소의 변경(animation 이나 transition 등)이 일어날 때 성능이 개선되기도 악화될 수도 있다.