CRITICAL-RENDERING-PATH
명심하고 성능에 유의해서 코드를 짜도록하자.
Last updated
Was this helpful?
명심하고 성능에 유의해서 코드를 짜도록하자.
Last updated
Was this helpful?
순서는 크게 Construction 그리고 Operation 으로 이어진다.
HTMl 페이지에서 브라우저가 이해할 수 있도록 브라우저만의 언어로 바꾸는 파트
브라우저가 서버에게 html 파일 요청
html 받아와서 loading 을 한다
이후에 html을 한줄 한줄 읽어서 DOM 요소로 변환한다. 이 과정을 scripting 라고 한다.
이 과정에는 DOM + CSSOM 등이 포함된다.
브라우저 윈도우에 보여주기 위해 준비한다. 렌더링 트리를 만드는 과정이다. 이 과정을 렌더링이라고 한다.
자 그럼 어떻게 하면 이 Construction 과정을 빠르게 만들수 있을까?
당연한 이야기겠지만 DOM 을 작게 CSSOM 을 작게할 수록 렌더링트리가 작아지니깐 속도가 빨라진다. 따라서 불필요한 태그(특히 div)를 사용하지 말자.
만들어진 브라우저만의 언어를 이용해서 구조를 작성하고 어디에다 배치할지 결정하고 실제로 브라우저에 그려주는 파트다.
만들어진 render tree를 이용해서(render tree 에는 DOM + CSSOM 의 최종 산물이다) 각각의 요소들이 어느 위치에 얼마만큼의 크기를 가질지 계산하는 과정이 뒤따른다. 이를 layout 이라고 한다.
이 과정에서 상대적인 측정값들은 화면에서의 절대적인 픽셀로 전환된다.
여기서 표시되는 노드와 해당 노드의 계산된 스타일 및 기하학적 형태에 대해 모두 파악 완료한다.
그리고 실제로 페이지에 나타낸다. 이를 painting
렌더링 트리의 각 노드를 화면의 실제 픽셀로 변환하는 마지막 단계
계산한 아이들을 바로 브라우저에 그리는게 아니라 우리가 이 요소들을 어떻게 배치했냐에 따라서 페인트에서는 각각의 부분을 잘게 잘게 나누어서 이미지를 준비해놓는다. (컴퓨터가 이해할 수 있는 bitmap 형태로 준비한다.) z-index 를 생각해보면 각각의 부분을 왜 잘라 놓는지 쉽게 이해할 수 있다. z-index 를 이용해서 각각의 레이어별로 만들어 놓는다.(그렇다고 꼭 z-index 만을 위한 과정은 아니다!)
이렇게 요소들을 분리해놓는 이유를 성능적인 측면에서 이해해보자면, 만약 이런 요소들을 한번에 준비하고 그린다면 어떤 한 요소가 변경되었을 때도 다시 한번 모든 요소를 그려야하는 엄청난 비효율이 생긴다!
Css 에 will-change 라는 속성이 있다. 예를 들면 opacity 가 변화하는 요소에 이 속성을 사용하면 브라우저는 이 속성을 통해 아 너는 변할 가능성이 있는 요소구나. 그렇다면 나는 너를 하나의 레이어로 만들어서 관리할게. 왜냐하면 넌 변할거고 그때마다 굉장히 큰 요소를 다시 그리기는 싫으니깐! 그래도 will-change 를 너무 남발하지 말아줘. 왜냐하면 너가 많으면 내가 따로 만들어야할 레이어가 너무 많아지니깐!
마지막과정은 composition이다. 이 과정에서는 이전 과정에서까지 준비해놓은 레이어들을 순서대로 브라우저 위에다가 표시한다!
자 어떻게 하면 빠르게 operation 과정을 끝낼 수 있을까?
처음에 사용자에게 표시하는것도 중요하지만 뷰의 변화를 최소화하는게 중요하다! 예를 들면 페이지에 네모 그림이 있다고 할 때 이 네모그림을 옮기는 최적의 방법은 transition 을 이용하는 것. transition 을 이용하면 이미 존재하는 composition 요소를 옮기기만 하기 때문이다.
최악은 layout을 처음부터 다시 그리는 과정이다. 이 과정은 요소의 변화로 인해 각 요소들이 영향을 받을 때 발생함.
따라서 무언가의 변화가 필요할 때 최대한 composition 만 일어나게하고 paint 까지는 괜찮겠지만, layout까지는 가지 말도록하자!
