성능 최적화 (2) Infinite scroll 에 Intersection Observer 적용하기
-
728x90
Performace
기존 무한 스크롤을 구현했던 방식은 Scroll Event를 이용하여 현재 스크롤 위치와 전체 스크롤 크기 등을 이용한 로직이었습니다. 해당 로직은 문제점이 있었는데요. 스크롤을 움직이면 1초안에 굉장히 많은 Event가 발생하게 되면서 위 퍼포먼스 성능과 같이 1000ms 당 약 160ms를 스크립트가 차지하게 되는 문제였습니다. 사실 최근 개인 컴퓨터의 성능과 서버의 성능이 많이 좋아지면서 체감하기 어려울 순 있습니다. 하지만 항상 최선만을 염두에 둘 순 없습니다. 만약 성능이 안좋다면 유저에게 최악의 경험을 안겨주게 됩니다.
두 가지의 개선 방법이 있었습니다.
쓰로틀링과 인터섹션 옵저버 입니다.
제가 처음 사용을 고려했던 것은 쓰로틀링 이었는데요. 문제가 있었습니다.
이에 대해 섹션을 나누어 이야기 해 보겠습니다.
1. Throttling
쓰로틀링이란 하나의 변수와 setTimeOut을 이용하여 처음 함수가 실행된 이후 일정 시간 동안 다시 호출되지 않게끔 하는 프로그래밍 기법입니다.
쓰로틀링의 장점은 구현이 굉장히 간단합니다. 그만큼 가독성이 좋다고도 볼 수 있을 것 같습니다.
이를 Scroll Event에 적용했다면 1초안에 굉장히 많은 Event가 발생되는 것은 막을 수 있습니다만..
제 머릿속에선 서버에서 API를 받아와서 데이터를 그리는 시간 + 운 없이 API를 호출할 시점 전에 마지막 Scroll Event가 실행되어 최악의 속도로 요청하게되는 경우가 맞물렸을 때.. 과연 이게 옳은가? 라고 생각이 들었습니다.
실제로도 setTimeOut의 시간을 설정하는 것이 굉장히 신경쓰였습니다.
따라서 다른 좋은 방법이 없을까 고민을 하게 되었고 인터섹션 옵저버에 대해 알게 되었습니다.
2. Intersection Observer
인터섹션 옵저버란 '옵저버' 라는 단어 그대로 특정 엘리먼트를 관찰하게 하고 관찰될 시 인터섹션 옵저버의 Callback을 통해 원하는 액션을 취할 수 있게 합니다. 쉽게 풀어말하면 내가 보고있는 화면에서 특정 엘리먼트가 보이는 요소인지 아닌지를 판별하게 도와줍니다. 이 기능은 '비동기적'으로 진행되기 때문에 앞서말한 Scroll Event의 성능 이슈의 보완점이 됩니다.
단점을 꼽아보자면 이전까지 IE와 Safari 등 몇몇 브라우저에서 지원을 하지 않았었지만 현재는 IE(서비스 종료)를 제외한다면 다 사용할 수 있으니 문제 또한 없습니다.
다만 무한 스크롤을 위해 스크롤의 끝에 관찰할 수 있는 Element를 만들어야 합니다.
이를 적용하고 난 뒤
비슷하게 약 1000ms간 무한스크롤링을 시도했지만 이전과 다르게 성능이 약 150ms 정도 개선된 것을 볼 수 있었습니다.
요즘 이런 개선점 찾는 것이 꽤 재밌는 것 같습니다. 물론 처음부터 잘 했으면 좋았겠지만 ㅎㅎ 다음에는 이런 케이스를 놓치지 않을 것 같아요.
미래에 연차가 쌓이고 익숙해진다면 많은 과정에서 최선의 기법을 잘 선택할 수 있을거라 믿습니다.