Problem
사실 이미지 최적화에 대해서 생각해본 적이 없었는데,
최근에 조은님의 프론트엔드 실무에 관한 강의를 들으면서
이미지 최적화가 유저 체류 시간을 늘리는 것에 꽤나 큰 역할을 한다는 것을 알았다.
그래서 회사 프로젝트의 asset을 살펴본 결과,
이미지 파일 형식은 png, jpeg들이 대부분이었고
쓰이는 크기에 비해 원본 파일의 크기가 너무 크다는 문제점이 있었다.
대충 찾아본 결과 (조금 더 찾아서 부연 설명을 붙여보자)
png, jpeg보다는 WebP, AVIF가 저용량 고효율을 보인다는 이야기가 있어서
이참에 쓰이는 크기만큼 조절하고, WebP로 변환시켜 다시 deploy해
성능 차이를 확인해보기로 했다.
Before
그렇다면 최적화 하기 전 프로젝트의 성능은 어떤지 보도록 하자
성능 비교는 모바일과 데스크톱 두 개를 모두 비교하기로 했다.
지표는 Lighthouse와 Network 로딩 시간을 확인하기로 했다.
동일한 환경을 위해 브라우저 캐싱이 전혀 되지 않는 크롬의 게스트 탭을 이용했고
같은 네트워크, wifi를 이용했다.
데스크톱 환경
모바일 환경
보다시피 image size가 적절하지 않고,
구시대의 format을 사용하는 것이 성능저하의 가장 큰 원인이라고 지적해주고 있다.
네트워크
로컬 환경
배포 환경
다음은 네트워크 탭에서 실제로 불러와지는 속도를 봐보았다.
가장 하단에 다음과 같은 정보를 집중적으로 봐보도록 했다.
로컬 환경
7.1 MB transferred
16.8 MB resources
Finish: 1.77 s
DOMContentLoaded: 849 ms
Load: 1.39 s
배포 환경
8.7 MB transferred
8.8 MB resources
Finish: 11.01 s
DOMContentLoaded: 3.66 s
Load: 10.66 s
After
모바일은 해당 warning 사라짐 (Navbar에 들어가는 이미지가 데스크톱에서만 보여서 그런듯)
로컬 환경
배포 환경
로컬 환경
3.4 MB transferred
13.0 MB resources
Finish: 936 ms
DOMContentLoaded: 671 ms
Load: 931 ms
배포 환경
5.6 MB transferred
5.7 MB resources
Finish: 5.63 s
DOMContentLoaded: 3.16 s
Load: 5.39 s
Compare
보다시피 이전의 Serve images in next-gen formats warning은 당연히 사라졌고,
Properly size images 수치도 3.5에서 1, 18에서 2.4로 크게 낮아진 것을 확인할 수 있다.
또한 네트워크 탭에서도 주고 받는 데이터의 양도 크게 감소했고
로딩 속도도 눈에 띄게 빨라진 것을 확인 할 수 있었다.
특히 배포 환경에서의 속도 차이가 굉장히 크게 났다.
사실 브라우저 캐시 없이 한 테스트라, js 파일 캐시 시간을 제외한다면
그 차이는 더 클 것으로 예상 된다.
로컬 환경
transferred7.1MB->3.4MB
resources16.8MB->13.0MB
Finish1.77s->936ms
DOMContentLoaded:849ms->671ms
Load:1.39s->931ms
배포 환경
transferred8.7MB->5.0MB
resources8.8MB->5.1MB
Finish:11.01s->5.35s
DOMContentLoaded:3.66s->2.98s
Load:10.66s->5.10s
Conclusion
앞으로는 이미지 최적화에 신경을 쓰자...
이때까지 아무런 생각없이 큰 용량의 이미지 파일을 남발하고 있었던 것 같은데
이번에 바꾸고 나니 체감 속도가 너무 빨라서 깜짝 놀랄 정도였다.
다른 팀원들에게도 공유를 해야겠다.
Moreover
아직 최적화를 위해 개선되어야 하는 부분들이 많이 보인다.
Lighthouse라는 툴을 알게된 지 얼마 되지 않았는데
사용하지 않는 자바스크립트 코드를 불러오거나, LCP 문제를 지적하고 있는데
이런 부분들을 어떻게 개선할 수 있을 지에 대해 알아보고, 적용하고 테스트 해 결과를 velog에 작성해봐야겠다.
끝
