당신의 이미지 업로드/다운로드가 느린 이유 feat. network탭 활용

서두

사실 뭐 이미지 업로드 / 다운로드가 느린 이유가 뻔하지. 이미지 사이즈 / 네트워크 전송속도 대부분 이러한 문제가 아닐까?

회사에서 기존 전임자가 만들어놓은 이미지 관련된 api를 여러 이유로.. 리팩토링하는 과정 중에서 심각한 점을 발견했다. 

 

포스트맨으로 체크했을 때에는 분명 문제가 없었는데, 테스트라는 것은 결국 내가 아는 범위 내에서의 테스트일 뿐이지, 완벽한 체크가 아니라는 것을 다시 한번 느낀다. 

 

여태까지 서버 로그, 포스트맨으로만 확인하다가 앱에서 알림이 와서 확인하는데 이미지가 불러와지지 않는 것이다. 그런데 하필 리팩토링(s3 + cloudfront 작업 이후 기존 이미지 cloudfront url로 컨버팅)중에 있다보니 url 변환해주는 과정에서 이슈가 있나? 라는 생각이 먼저 들었다. 

 

 

과정

웹에서 직접 이미지를 불러와보니.. 웹에서도 늦게 불러와졌다. 어느정도냐면.........

아니 ㅋㅋㅋㅋㅋㅋㅋ 단위가 바뀌어버릴정도로 차이가 많이 났다. 

 

이게 .. 어느정도 느린 것이냐면 앱 기준으로 왼쪽은 5초정도 소요되면서 바로 불러와지는 이미지,

오른쪽은 대략 3분을 기달려야 나올까 말까 한 수준의 이미지였다.

그니까 결국 이미지가 안불러와지는게 아니라 하도 느려서 안불러와진다고 느낀 것이다. 

웹에서는 그나마 57ms, 1.04s인데, 이게 1.04s는 눈으로 이미지가 불러와지는 과정이 슬로우모션처럼 보이는 수준이다. 

앱기준으로 5초..? 3분..?

 

사실 5초도 엄청 답답한데.. 

구글은 최초 페이지 로딩이 3초 이상 걸릴 경우 50%의 사용자가 이탈한다는 분석값을 내놓았으며, 페이지 로딩 시간이 긴 경우 검색 순위를 낮추겠다는 말까지 나올 정도다. 

 

 

왜 그런 것인지 분석해보자. 각 이미지의 속성을 확인해보니 용량과 그 크기가.. 어마어마했다. 

 

반대로 그나마 빨리 불러와지는 이미지를 확인해보자. 둘을 비교해보면.. 용량은 단위부터 압도적으로 달라진다. 

 1MB는 1024KB이므로, 30.7MB은 대략 31,532.8KB 으로 400배의 차이가 난다..

규격은 뭐 계산하지 않아도 대충 9~10배의 차이가 난다. 

 

 

이제 어떻게 해결할지는 다음 포스팅에서 다루려 한다. 

 

코멘트

response time만 중요한 것이 아니다. 정작 프론트에서 보여주는 것은  rdb에 넣어둔 url 문자열에 불과하다.

s3에는 이미 전달을 했고, 클라이언트는 s3에서 알려준 링크대로 보려고 하는 것이기 때문에 다른 시각에서 접근해야 한다. 

 

s3에 이미지를 저장할 때 가공하는 과정을 거쳐야 보여줄 때 저렇게 오래 기다리지 않고 바로 보여줄 수 있다. 이미지를 리사이징해서 원본과 수정본을 각각 저장하고, 기본적으로 수정본을 보여주되, 변환 과정이나 특정 오류때문에 수정본이 없거나 확인되지 않는 경우 원본을 보여줄 수 있도록 처리하는게 좋겠다.