본 포스팅을 보기 전에 이전 포스팅 - 네트워킹 을 보시는 것이 도움이됩니다. 🙂
브라우저는 서버로 부터 요청한 html과 css, javascript 파일을 받아 렌더링을 한 후 사용자에게 픽셀로 내용을 표시해줍니다. 브라우저가 수행하는 일련의 렌더링과정을 rendering critical path 라고 합니다.
이번 포스팅에서는 rendering critical path를 알아보겠습니다.
👉 Document Object Model 구축
브라우저의 html parser가 tokenization 알고리즘을 통해 각 태그들을 Node로 만들며
이 contruction 알고리즘을 통해 DOM tree를 구축합니다.
Node (노드) ?
여기서 말하는 노드는 node.js가 아닙니다. 노드는 HTML element와 관련된 정보를 담고 있습니다. 시작 태그 '<>'와 닫는 태그 '</>'를 하나의 토큰으로 노트들은 계층적 구조를 띌 수 있으며 이렇게 Node들의 계층적 구조가 하나의 DOM Tree를 형성하게 됩니다.
이때 Node 계층 구조가 복잡하다면 단순한 구조에 비해 파싱되는데 더 많은 시간이 들게되며
DOM construction은 incremental이기 때문에 먼저 구축되는 내용들을 우선적으로 보여주게 됩니다.
여러개의 노드가 겹치거나 합쳐져서 하나의 DOM Tree를 형성합니다.
👉 CSS Object Model (CSSOM) 구축
DOM이 content를 담고 있다면 CSSOM은 DOM의 스타일을 담고 있습니다.
DOM과 다른점은 construction이 incremental(점진적)하게 일어나지 않아 다 해석이 되어야만 표시가 됩니다. 따라서 CSS Object Model이 생성되는 과정을 rendering blocking 하다고 말합니다. 오버라이드되는 스타일들은 렌더링 트리에 포함되어 스크린에 표시되면 안되기 때문에 렌더링 트리로 합쳐지기 전에 모든 CSS는 파싱되어 CSSOM으로 만들어져야 합니다.
퍼포먼스 측면에서..
selector performance에서
.foo {} 가 .bar .foo {} 보다 더 빠르다고 합니다. 구체적으로 표현된 css selector는 부모자식관의 관계를 탐색해야되기 때문에 속도가 더 느리다고 합니다. 하지만 optimizing에 크게 영향을 미치지는 않습니다. 관련 글: developer.mozilla.org
👉 Renter Tree 구축
렌더트리는 실제로 스크린에 표시될 내용을 DOM Tree와 CSSOM 을 합쳐서 만듭니다.
webkit(크롬 렌더링 엔진)에서는 이렇게 두 가지를 합치는 것을 attatchment라고 말합니다.
attatchment에서 브라우저는 DOM tree의 루트 노드 부터 마지막까지 탐색하며 어느 위치에 어느 CSS가 결합되어야 할지 결정합니다.
render tree에는 실제로 스크린에 표시될 내용만 담겨지는데요,
display:none과 같은 css와 결합된 노드는 나타나지 않습니다.
👉 Layout
레이아웃은 페이지의 어느 위치에 어느 element가 나타나야할지 결정해주며
각 element의 크기를 결정해줍니다.
메타 태그에 viewport 속성이 있는데요, 이 viewport 메타태그는 설정을 하지 않으면 기본 값으로 980px이 설정되기 때문에 모바일에서는 내용이 작게 보입니다.
<meta name="viewport" content="width=device-width"> 이 메타태그가 Layout에 영향을 미칩니다.
viewport가 달라질 경우 layout과정을 다시 거치게 됩니다.
👉 Paint
critical rendering path의 마지막 작업입니다.
render tree에 나타나 있는 요소들이 layout에서 결정된 크기와 위치에 픽셀로 나타나집니다.
