프로그래스 바 구현과 성능 개선을 위한 트러블 슈팅

0. 설계

페이지 내 컴포넌트와 상태 관계도

• 다시보기 진행 시간 상태에 따라 헤더의 진행시간, 스크립트 하이라이팅, 바 진행도를 갱신합니다.

1. 설계: 프로그래스 바 드래그로 제어하기

• 드래그 판단 조건: 프로그래스 바에서 MouseDown && MouseMove라고 생각했습니다.
• 그래서 마우스 버튼을 클린한 경우 isProgressBarDrag flag state를 true로 변경하도록 했습니다.
• MouseMove 이벤트가 발생할 때마다 isProgressBarDrag가 true일 때, progressMsTimeState와 프로래스 바의 width를 조절하도록 했습니다

2. 해당 설계의 문제

문제 - MouseMove 이벤트가 너무 많이 발생해 부하 발생 가능성

• MouseMove 이벤트는 마우스의 좌표가 바뀔 때마다 발생합니다. 만약 900pixel의 프로그래스 바의 끝에서 끝까지 드래그 할 경우 적어도(x축 이동 뿐만 아니라 y축 이동에도 이벤트가 발생할 것이기 때문입니다.) 900회 이상의 이벤트가 발생할 것 입니다.
  

• 단순히 프로그래스 바를 랜더링 하는 수준에서는 감당 가능한 부하겠지만, 프로그래스바의 이동에 따라 다시보기 화면 전체를 랜더링 하는 경우는 부하가 커질 것이라고 판단했습니다. 그리고 추후 다시보기의 내용을 쪼개서 요청을 보내 캔버스를 랜더링 할 경우 요청이 너무 많아 클라이언트 뿐만 아니라 서버에도 큰 부하가 발생할 수 있을 것이라고 판단했습니다.

3. 해당 설계의 문제 해결

해결 - 쓰로틀링 적용

디바운싱 vs. 쓰로틀링(쓰로틀링을 적용한 이유)

• 이런 잦은 빈도의 이벤트 발생으로 인한 문제의 해결 방법이 크게 디바운싱과 쓰로틀링이 있습니다. 그런데 디바운싱의 경우 이벤트 발생이 끝나고 일정 시간 이후에 제일 마지막 이벤트에 대한 처리를 합니다. 이런 디바운싱의 동작 방식 때문에 프로그래스 바의 드래그 기능에는 적합하지 않다고 생각했습니다. 그래서 일정 시간 주기로 이벤트의 콜백을 처리하도록 쓰로틀링을 적용했습니다.

쓰로틀링을 적용했을 때 예상되는 단점

• 프로그래스바를 드래그했을 때 화이트보드의 진행 상황이 부드럽게 연결되지는 않을 것입니다.

예상되는 단점에도 이런 성능 개선을 위한 방법을 선택해도 되는 이유

• 사용자가 프로그래스바를 드래그로 진행도를 조작하는 경우 모든 프레임을 확인하는 목적보다는 해당 시간대에 어떤 장면이 있었는지 빠르게 브리핑되는 화면을 바탕으로 탐색하는 것이 사용자들의 주목적이라고 생각했습니다. 그래서 적절한 간격으로 화이트보드를 랜더링 해주기만 한다면 사용자 경험에서 문제가 없을 것이라고 생각했습니다. 그리고 사용자가 드래그를 통한 진행 상황 탐색 당시 렌더링 부하로 인해 프로그래스 바에 지연이 생기는 경우가 더 나쁜 사용자 경험이 될 것이라고 생각합니다.

4. 개선

개선된 설계도

쓰로틀링 적용 전

쓰로틀링 적용 후

5. 개선의 결과(성능, 사용자 경험)

• 성능개선: 스크립팅에 소모되는 시간이 2474ms에서 560ms로 약 77%의 성능적 개선이 가능했습니다.
• 사용자 경험: 프로그래스 바를 드래그 하면 생겼었던 딜레이를 해결해 사용자의 경험을 증진시킬 수 있었습니다.