렌더링 과정
앞서 살펴보았던 브라우저 렌더링 과정을 크게 두 개의 구성으로 나눠볼 수 있다.
-
construction
- DOM / CSSOM
- Render tree
-
operation
layout: 요소의 위치와 크기를 계산하는 것paint: 레이어 작업이 수행되는 것composition: 작업이 끝난 요소들을 브라우저 위에 살포시 내려놓는 것
꽤나 설명이 추상적일 거 같다. 그림 그리는 것을 예시로 들었을 때 나무를 그릴 위치와 나무의 크기를 계산하는 것이 레이아웃 단계이고, 같은 규칙의 요소들끼리, 하늘에 있는 해와 새는 같은 레이어로 나무와 사과는 같은 레이어로 묶어주는 작업이 페인트 단계이다. 그리고 완성된 나무를 도화지에 내려놓는 것이 컴포지션 단계이다.
😖 리렌더링의 비용을 줄여라
중요한 포인트는 다음과 같은 작업을 통해 레이아웃 계산과 페인팅이 재차 실행되고 이것은 성능에 악영향을 주는 작업이라는 것이다.
- 자바스크립트에 의한 노드 추가 또는 삭제
- 브라우저 창의 리사이징에 의한 뷰포트 크기 변경
- HTML 요소의 레이아웃에 변경을 발생시키는 여러가지 스타일 변경들 ( width/height, margin, padding, border, display, position, top/right/left/bottom 등 )
composition 까지는 괜찮다. paint 단계가 반복되는 것도 썩 좋진 않지만 참아줄 수 있다. 그러나 layout 단계가 재실행되는 것은 매우 좋지 않다.
해당 링크는 애니메이션이나 브라우저에 동적 변화가 일어났을 때 리렌더링의 비용을 알려주는 사이트이다. 해당 사이트를 참고하여 성능 개선에 힘을 써보자.
css-triggers ⬅️ 참고하기
🛠️ 퍼포먼스 개발툴
개발자도구의 performance tool을 통해서 애니메이션이나 동적인 변화를 녹화하여 프레임 단위로 성능을 확인할 수 있다. 16ms가 넘어가면 사용자가 어플리케이션을 사용하는 데 불편함을 느낄 수 있고 레이아웃 이동이 발생하면 알려주고 개선해야한다고 경고를 띄운다.
또한 ctrl+shift+p를 눌러 커멘드 팔렛을 활용해서 레이아웃이 어떻게 움직이는지 확인할 수 있다.
사용자 인터렉션이 많은 어플리케이션일수록 성능개선은 반드시 요구되어진다. 성능개선의 중요함을 다시 한번 각인시키자.
