7월부터 진행한 오픈소스 컨트리뷰션 아카데미 에서 진행한 githru 프로젝트 issue를 해결하는 과정에서 이미지가 느리게 로딩되는 이슈 를 assign하게되었다.
이슈
사용자의 github profile Image를 렌더링 하는 과정에서 error가 발생할 경우 ( profile Image가 존재하지 않는 경우 ) gravatar를 사용하여 random 이미지를 렌더링 해주는데 로딩 속도가 느리다는 이슈가 발생하였다.
로딩속도는 사용자의 경험에 큰 영향을 준다고 생각하여 해당 이슈를 지나칠 수 없어 담당하게되었다.
https://github.com/githru/githru-vscode-ext/issues/258
최적화 조언
해당 프로젝트를 함께 진행중인 팀원분의 조언은
사용자별 gravatar 의 경로를 md5로 랜덤한 값으로 요청을 보내기에,
profile image가 존재하지 않는 사용자가 많아질 경우 요청 지연은 발생하기 때문에, 사용자별 랜덤한 값이 아닌 약 5개의 값으로 캐싱을 적용하도록 하자는 의견을 주셨다.
하지만, 나는 gravatar를 사용한 fallback url에 대한 지연을 발견하지 못하였다.
( 네트워크 환경을 제한없음 , 빠른 3g , 느린 3g 에 대하여 성능 측정 진행 하였음. )
오히려 profile image가 더욱 느리게 렌더링되는 것을 확인하게 되었다.
또 다른 문제점 발견
fallback url이라 하면, 해당 유저의 profile Image Url에 대하여 요청 실패 이후, 재 요청을 통해 profile Image가 존재하는 유저보다 느리게 렌더링이 되어야한다.
하지만, 3가지의 네트워크 환경에서 모두 fallback url이 먼저 렌더링이 되는 이슈가 발생하였다.
위 이미지를 확인해보면, github profile을 조회하는 경우 redirect를 발생시키게되어 렌더링 속도가 느리게 되는 것을 확인할 수 있다.
해결방안
redirect URL로 요청을 보내자
Redirect 를 보내는 url로 처음부터 요청을 보내면 리다이렉트를 발생시킬 일이 없을 것이다.
하지만, 사용자 고유 값이 존재하지 않아 해당 방법을 통해 해결할 수 없었다.
이미지 크기 리사이징
해당 이미지는 나의 깃허브 프로필 사진이다.
콘텐츠 다운로드 시간이 약 800ms가 발생하였는데,
github image는 리사이징이 가능하다고 한다.
나는 githru에서 사용하는 이미지 크기인 ?size=30을 사용하여 이미지 크기 리사이징을 진행하였다.
그 결과,
콘텐츠 다운로드 시간이 0.32ms 가 소모되는 것을 확인할 수 있다.
결과
네트워크 환경은 빠른 3g 였으며, onError를 발생한 유저는 11명 , 리다이렉트 발생하는 유저는 13명이었다.
리사이징 이전에는 약 6000ms ~ 8300ms => 2300ms 였지만,
리사이징 이후에는 약 5800ms ~ 7600ms => 1800ms 로 약 500ms가 감소하게 되었다.
