requestAnimationFrame 으로 프레임 타이밍 맞추기

🎨 글에 들어가기 앞서 브라우저는 화면을 그릴 때 다음과 같은 과정을 반복한다. 

1. 자바스크립트 실행
2. DOM 변경 감지
3. 스타일 계산
4. Layout (Reflow) – 요소의 위치와 크기를 계산
5. Paint – 계산된 정보를 바탕으로 픽셀을 그리기
6. Composite – 레이어를 조합해 최종적으로 화면에 출력

위 사이클은 보통 1초에 60번, 약 16.6ms마다 반복되며, 브라우저는 이 주기에 맞춰 최대한 부드럽게 화면을 렌더링을 하는데, 자바스크립트에서 DOM을 조작하거나 애니메이션을 처리할 때 이 타이밍을 고려하지 않으면, 프레임 드롭, 끊김, 느려진 인터랙션 같은 문제가 쉽게 발생한다고 한다.

✨ requestAnimationFrame 이란?

window.requestAnimationFrame() 메서드는 브라우저에게 수행하기를 원하는 애니메이션을 알리고 다음 리페인트 바로 전에 브라우저가 애니메이션을 업데이트할 지정된 함수를 호출하도록 요청합니다. 이 메서드는 리페인트 이전에 호출할 인수로 콜백을 받습니다.

 
requestAnimationFrame() 은 위에서 말한 그 타이밍을 고려하는 메서드다. 
브라우저의 렌더링 주기 안에서 가장 적절한 타이밍에 콜백을 실행해 주며, DOM 변경이나 스타일 업데이트 같은 작업을 이 시점에 맞춰 실행하면 불필요한 Reflow나 Paint를 줄일 수 있고, 결과적으로 퍼포먼스가 향상된다고 한다.
 
나의 경우, 전에 개발하던 에픽에서 마우스로 빠르게 드래그할 때 묘하게 탁탁 끊기는 느낌이 들어서 해당 메서드에 대해 찾아보게 되었다. requestAnimationFrame을 적용하고 나서 해당 현상이 사라졌고, 체감상으로도 훨씬 부드럽게 작동했다. 다만 블로그에 정리할 때,  적용 전 후가 영상으로는 차이가 잘 드러나지 않아 어떻게 비교해 볼지 고민이 많았는데, 🤖 의 추천의 Performance 탭을 좀 더 깊게 들여다보게 되었다.

📈 성능 비교

 
왼쪽이 requestAnimationFrame 적용 전 상태, 오른쪽이 적용 후 상태이다. 두 개 다 실제 인터랙션이 일어나는 구간을 확대해 보았다. 
 
적용 전 타임라인을 보면 프레임 드랍이 여러 번 발생하고 있고, 레이아웃 변경도 불규칙하게 일어나며 브라우저가 렌더링 타이밍을 제대로 맞추지 못하고 있는 모습을 볼 수 있다. 반면 적용 후 상태는 프레임이 일정하게 유지되고 있으며, 프레임 드롭도 발생하지 않았다.
레이아웃 변경은 일정한 간격으로 반복되고 있어, DOM 변경이 브라우저의 렌더링 주기 안에서 안정적으로 처리되고 있음을 보여준다. 
 
레이아웃 변경이 일정한 간격으로 반복되는 이유는 위에서 언급된 타이밍 때문이다.
requestAnimationFrame은 브라우저가 다음 프레임을 그리기 직전, 즉 렌더링 사이클의 가장 적절한 순간에 콜백을 실행해 준다. 이때 DOM 변경이나 스타일 수정이 일어나면 브라우저는 그 변경사항을 곧바로 이어질 Layout 및 Paint 과정에 반영할 수 있고, 불필요한 연산 없이 한 프레임 안에서 모든 렌더링 작업이 효율적으로 처리된다. 결과적으로 렌더링 주기와 정확히 맞물려 작업이 진행되기 때문에, 레이아웃 변경도 매 프레임마다 일정하게 발생하게 되는 것이다. 
 

🤔 느낀점

애매하게 느껴지는 작은 끊김을 해결하기 위해 시작했던 문제였지만, 글을 적다 보니 결국 "언제 실행되는가"가 성능에서 얼마나 중요한지를 체감하게 되었다. requestAnimationFrame은 단순히 애니메이션을 부드럽게 해주는 유틸성 API가 아니라, 브라우저의 렌더링 타이밍과 내 코드의 실행 시점을 맞춰주는 최적화 도구다. 만약 애니메이션 도중 끊김이나 버벅거림이 느껴진다면, 가장 먼저, 그리고 간단하게 시도해 볼 수 있는 방법이 아닐까 싶다.