브라우저에 URL을 입력하면...
request/response -> Loading -> scripting -> rendering -> layout -> painting
Critical Rendering Path
scripting 까지의 과정을 construction, 그 이후를 operation이라고 부른다. Rendering Tree를 만들고(contruction), 그걸 그려주는 과정이 크게 layout, paint, composition 과정이다.
Layout
우리의 모질라께서는 Layout을 다음과 같이 설명한다.
일단 렌더 트리가 생성되고 나면, 레이아웃은 가능해지며 화면의 크기에 의존합니다. 레이아웃 단계는 요소들이 페이지에서 배치되는 위치와 방법, 각 요소의 너비와 높이 그리고 서로 관련된 위치를 결정합니다.
렌더 트리를 기반으로 윈도우에 어느정도 크기로 요소들을 그릴지 말그대로 레이아웃을 짠다.
Paint
바로 그림을 그리는게 아니라, 잘게 쪼개서 각 부분의 이미지를 레이어별로 준비해놓는다. 레이어별로 준비해놓는 이유는, 나중에 수정할 부분이 생겼을때 전체를 갈아엎는게 아니라 해당 레이어만 바꾸기 위해서이다.(css will-change 속성을 통해 얘는 나중에 바꿀거야 라고 선언해 놓으면 따로 레이어에 만들어놔서 성능을 조금 낫게 할 수 있다. 남용하면 오히려 성능이 낮아질 수 있으니 꼭 필요할때만 사용하자)
Composition
만들어 놓은 Layer를 순서대로 차곡차곡 쌓는 것이다.(z-index가 가장 높은애를 나중에 쌓기)
그래서 성능을 어떻게 개선할 수 있을까?
Render Tree 자체를 작게 만든다.
브라우저의 구성원리를 보면 성능 개선을 하는 방법은 꽤나 Straight하게 보인다. Construction까지(Render Tree를 구성)의 성능을 개선하려면 당연히 노드의 개수를 줄이면 트리를 만드는데 시간이 덜 걸린다. 그러려면 불필요한 html 태그들을 줄이면 된다. 불필요한 wrapping 태그들을 줄이는 방법이 대표적이다. 이를 통해 트리 자체의 크기를 줄이는게 좋다.
composition 수준에서 변경 가능하게 구상한다.
애니메이션이나 css 속성을 변경해야 할 때, composition 단계에서 해결될 수 있는 문제라면 성능에 관해 크게 걱정하지 않아도 된다. 하지만 layout이 바뀌는 속성 변경이라면 변경된 Layout에 paint, composition 과정이 적용되어야 하므로 소요가 많다. 따라서 이 변경이 필수적인가 고민해 볼 필요가 있다.
내가 쓰는 css는 어디까지 영향을 끼치는걸까
css attribute 별 composition만 변경되는지, paint가 바뀌는지, layout까지 변경되는지 알려주는 사이트다.
https://csstriggers.com/
운영 브라우저 엔진마다 적용 범위가 다르므로 참고하면 좋을 것 같다!
