💡 Critical Rendering Path
브라우저에서 웹페이지를 열면 어떤 순서로 렌더링이 될까?
requests / response
브라우저가 서버로 부터 HTML파일을 요청하고 응답받는 과정이다.
loading
브라우저가 HTML파일을 한줄 한줄 읽어나간다.
scripting
브라우저가 HTML 파일을 DOM으로 변환 및 CSSOM을 생성 후 Render Tree를 만들어낸다.
Render Tree는 웹페이지에서 보여지는 부분에 대해서만 요소를 가지고 있다.
head부분과 display : none 같이 보여지지 않는 부분에 대해서는 요소를 가지고 있지 않다.
rendering
브라우저에 보여질 요소들을 준비한다.
layout
렌더링 된 요소들을 어디에, 얼마나 크게 배치할 것인지 결정한다.
paint
레이아웃이 완료된 요소들을 스타일링한다.
Render Tree를 layout과 paint를 통해 브라우저에 표기한다.
💡 paint의 비밀
브라우저를 한 레이어로 그리는 것이 아니라, 각각의 속성에 따라 따로따로 레이어를 나누어서 그린다.
만약 한 레이어로 그렸다면, 레이어 안의 어떠한 요소가 변경됨에 따라서 전체의 레이어를 다시
그려야만 할 것이다. 마치 포토샵의 레이어 기능처럼 작동한다
성능을 위해서 나눠서 그린 레이어는 해당 레이어의 변경이 있을 때마다 해당 레이어만 수정하면 된다.
will-change라는 CSS 속성은 브라우저에게 변경이 있을거니까 별도의 레이어에 그려놓으라는 말이다.
Paint 과정에서 성능을 위해 별도의 레이어를 생성하여 그린다.
💡 성능을 위한 웹 렌더링
웹 페이지의 렌더링 과정이 짧을 수록 좋은 성능을 보여줄 수 있다.
렌더링 과정을 살펴봤을 때 DOM이 무겁지 않다면, Render Tree를 빠르게 만들어낼 수 있을 것이다.
따라서, 별다른 의미를 가지지 못하는 태그들을 남용해서는 안되겠다.
또한, 어떤 요소의 레이아웃이 변경된다면, layout을 재배치하고, paint의 과정까지 거쳐야한다.
가장 최악은 다른 요소의 layout까지 침범하여, 재배치 이후에 repaint 과정을 거친다면 웹 성능이 나빠질 것이다.
대표적으로 width, height, top, left등의 스타일 속성을 변경할 때 layout부터 과정이 진행되므로
좋은 방식이 아니다.
opacity와 transform은 다른 요소에 layout을 침범하지 않으므로, 웹 성능을 위해 좋은 방식이라고 할 수 있다.
아래의 웹페이지는 CSS 스타일마다 어떤 과정부터 거치게 되는 지 나와있다.
성능 개선을 위해 개발하면서 한번씩 참고하면 좋을 것 같다.
