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