Reflow? Repaint?
- 수정된 렌더 트리를 리렌더링 하는 과정에서 발생
- 웹 애플리케이션의 성능을 저하시키는 주된 원인이다.
Reflow
- 모든 엘리먼트의 위치와 길이 등을 다시 계산하는 과정에서 발생됩니다.
- dom 일부 혹은 전체 렌더링시에 발생합니다.
Repaint
가시성에 영향을 주는 엘리먼트가 변경되면 발생한다.
- background, display 등등..- 무조건은 아니지만, Reflow가 발생하면 Repaint는 같이 발생한다.
- 브라우저가 DOM트리에 있는 다른 노드의
가시성을 모두 확인해야 하므로 리페인트는 비용이 많이 든다.
Reflow 가 발생 되는 경우
- DOM el 추가, 제거 또는 변경
- CSS 스타일 추가, 제거 또는 변경
- inline-style, class 변경이 일어남으로써 레이아웃이 변경 될 수 있다.
- DOM el 길이를 변경하면 DOM트리에 있는 다른 노드에 영향을 줄 수 있다.
- CSS 애니메이션, 트렌지션
- 애니메이션의 모든 프레임에서 리플로우 발생
- offsetWidth와 offsetHeight의 사용
- 해당 속성을 사용하면, 초기 reflow가 트리거되어 수치가 계산된다.
- offset, computed, bounding 같은 속성 및 메소드들은 이미 렌더링 된 DOM기준으로 CSS속성을
계산만해서 내려주기 때문에 reflow + repaint가 아닌 순수 reflow만 발생한다.
- 기타
- hover, 텍스트 입력, 창 크기 조절, 글꼴 크기 변경 등등
- 활성화 되면 리플로우를 트리거 할 수 있다.
성능 저하 최소화
그럼 이제 성능 저하 최소화 관련해서 한번 정리를 해볼려고 한다.
수 많은 성능 저하 최소화 관련 방법이 있지만, 자주 사용하는 태그 관련되서 정리를 해볼려고 한다.
1. 클래스 변경을 통해 스타일을 변경할 경우, 최대한 말단의 노드의 클래스를 변경한다.
- 돔 구조에서 최 하단 노드의 클래스를 변경한다.
- 중간에 있는 class를 바꾸게 된다면(ul > li 이런 케이스 제외...) 위 아래 노드들에게 영향을 미치게 되고, 그 과정에서 리플로우 리페인트가 발생 할 수 있기 때문이다.
<div>
<!-- 돔이 200개 -->
<!-- 최하단에 있는 class를 바꿔주세용 -->
<div class="change"></div>
</div>2. 인라인 스타일을 사용하지 않는다.
- 인라인 스타일을 사용하면 HTML이 다운로드 될 때, 레이아웃에 영향을 미치면서 추가
리플로우를 발생시킨다. - 클래스가 변경될때 엘리먼트는 하나의 리플로우만 발생시킨다.
3. 애니메이션이 들어간 엘리먼트는 position: fixed 혹은 position: absolute로 지정한다.
absolute또는fixed위치인 엘리먼트는 다른 엘리먼트 레이아웃에 영향을 미치지 않는다.- 리플로우가 아닌 리페인트 발생, 리페인트가 훨씬 적은 비용이 듦.
- 가격이 싸다.
리플로우 + 리페인트 < 리페인트
- 가격이 싸다.
4. 레이아웃을 위한 <table>은 피한다.
- 점진적으로 렌더링이 되지 않고, 모두 불려지고 계산된 다음에서야 렌더링이 된다.
- 작은 변경만으로 테이블의 다른 모든 노드에 대한
리플로우가 발생한다.
- 작은 변경만으로 테이블의 다른 모든 노드에 대한
글을 마치며..
이전 포스팅, 이번 포스팅을 통해서 대략적인 렌더링 과정과 리플로우 리페인트, 그리고 최적화 과정에 대해서 알아보았다.
FE개발자로 개발자 생활을 하면서, 중요한 이런 내용들을 놓치고 있어서 다시 한번 정리해 보았고, 앞으로 이런 내용들을 놓치지 않고 챙겨야 할 것 같다.
참고
Happy Accident FE developer