성능을 개선하기위해 브라우저 렌더링 과정을 재고해보지 않을수 없었다. 결국 성능을 잡는 다는건 렌더링 을 최소화하기 위한 일이니까....
렌더링 엔진
브라우저를 돌리기위해선 여러가지 엔진들이있다 (렌더링엔진..., 브라우저 엔진 ... )
렌더링 엔진이란놈이 존재한다
렌더링 엔지이 하는일:
- 웹페이지 요소들을 보여줌
- 효율적으로 렌더링 하기위한 자료구조를 만들어줌
렌더링 과정 :
👉웹페이지 불러옴
👉 파싱
👉 웹페이지 파일을 html5 표준의 토큰으로 변환함
👉 노드객체로 변경
👉 각노드가 연관성을 가지도록 트리를 생성함
👉 DOM트리 생성 (최상위 document)
👉 이와비슷하게 CSSOM 트리도 만들어짐
👉 DOM트리와 CSSOM트리를 합쳐 렌더트리를 만듬
document 객체부터 각노드를 순회하면서 각각의 맞는 CSSOM을 찾아서 규칙을 적용한다 (display : none 렌더트리 포함안됨)
👉레이아웃[Reflow] 과정을 거침 (뷰포트 내에서 요소들의 위치와 크기를 계산하는과정 )
👉 페인트 과정을 거침 (화면에 실제 픽셀로 그려지는 과정)
css 변경되거나 애니메이션이 실행 될때 어떤일이 벌어질까?
레이아웃 : 요소 크기 위치 , 브라우저창 이바뀔때
페인트 : 레이아웃 수치 x 스타일 변경
레이어 합성(composite) : 화면에 표시하기 위해 페이지에서 페인트된 부분을 합치는 과정 (tranform opacity will-change 등을 사용했을 때 합성 과정을 거친다)
레이아웃 > 페인트 > 레이어합성 순으로 렌더링이 많이된다
따라서 아래와같은 말을 많이 하는것도 이 렌더링 순서에 따른 말이다
=>"display : none 쓰지마세요 opacity 쓰세요 "
=>"레이아웃에서 변경하지말고 레이어합성 부분 에서 변경 시키세요 "
레이아웃 과정에서 성능잡기
직접 width , height 박아주기
...작성중
페인트 과정에서 성능잡기
...작성중
