애니메이션 최적화 (Reflow, Repainting)

애니메이션 최적화 (Reflow, Repainting)

참고

Jank(쟁크) 현상

일반적으로 모니터의 주사율은 1초당 60개(60FPS 60프레임) 화면을 보여준다. 이에 맞춰 브라우져도 1초에 60개를 보여주려 한다

이때 브라우져가 60개를 못보여주고 1초에 20개, 30개 정도만 보여준다면 애니메이션은 버벅거리게 되는데, 이 현상을 Jank(쟁크) 현상이라고 한다.

그럼 어떤 상황에서 브라우져는 1초에 60개를 못 그릴까?

브라우져 렌더링 과정

브라우저가 화면을 렌더링하는 과정은 아래와 같다.

HTML + CSS + JS 다운로드 -> DOM + CSSOM 변환 -> Render Tree 생성 -> Layout -> Paint -> Composite

DOM은 HTML 요소를 tree 구조로 만든 것이고 CSSOM은 스타일 요소들을 tree 구조로 만든 것이다.

이 두 가지를 조합해서 최종적으로 Render Tree를 만든다.

Layout은 요소의 위치와 크기 등을 계산하는 작업이고 Paint는 그 Layout 위에 배경색상이나 그림자, 글자 색 등 색을 칠하는 과정이다.

마지막 Composite은 각 레이어를 합치는 과정이다.

이 일련의 과정을 Critical Rendering Path, 혹은 Pixel Pipeline이라고 한다.

화면이 변하면 이 과정을 처음부터 다시 수행하는데, 이 변화가 너무 많으면 브라우져가 1초에 60번씩 보여주기 어렵게 된다.

performance 탭에 main tab을 보면 이 픽셀 파이프라인을 볼 수 있다. main 탭의 점선은 화면이 나타나야 하는 시점이다. composite가 이 점선 전에 완료되어야 정상이다.

그럼 브라우져에게 부담을 적게 주는 방법은 layout과 paint 과정을 건너 뛰는 것이다.

Reflow, Repainting, GPU의 도움을 받는 요소

1. Reflow

width, height처럼 위치나 크기에 관여하는 요소가 변할 때는 layout과 paint를 포함한 브라우저 렌더링 전체 과정이 재실행 된다. 이걸 Reflow라고 한다.

2. Repaint

outline, color, background-color 등 색상에 관여하는 요소가 변하면 layout은 생략되고 브라우저 렌더링이 일어난다. 이를 Repaint라고 한다.

3. GPU의 도움을 받아서 Reflow, Repaint 피하기

transform과 opacity 가 변경되면 GPU가 관여하면서 layout, paint 과정이 생략된다.

이 두 속성이 변할 때는 GPU가 직접 데이터를 가공해서 composite과정을 거치게 된다.

즉, 결론적으로 애니메이션 효율은 transform, opacity를 이용할 때 가장 빠르고, 그 다음은 색상이 변할 때가 빠르며 마지막으로 위치와 크기가 변할 때 가장 느리다.

CSS 요소 변화 시 렌더링 속도 비교

transform, opacity > color, background-color 등 색상 요소 > width, height 등 위치 및 크기 요소

결론

결론적으로 위치와 크기를 변화 시키는 애니메이션은 transform을 활용하고, 색상을 변화시키는 애니메이션은 opacity를 활용하는 게 가장 효율적이다.

빨강에서 파랑 등 어떤 특정 색상에서 또 다른 색상으로 변하는 애니메이션이 아니라, disabled 등 색상을 흐리게만 해도 되는 상황일 때는 opacity를 활용하는 게 좋겠다.