Front-End/React

이미지 lazy loading을 통한 성능 개선

KEMON 2023. 6. 26. 01:14
728x90

1. lazy loading 적용 전

아래의 사진은 고객사의 로고들이 있는 고객사례 컴포넌트이다. 

해당 컴포넌트는 index 페이지에 포함되어있다.

즉, 고객이 최초에 홈페이지에 들어왔을 때 보여지는 화면에 포함되어있다.

하지만 해당 컴포넌트는 스크롤을 좀 내려야 볼 수 있다.

고객사 로고 컴포넌트

그렇다면 과연 고객이 처음 홈페이지에 들어왔을 때 해당 이미지들을 불러와야 할까?

현재는 처음 홈페이지 들어오면 아래 사진과 같이 해당 이미지들을 전부 불러온다.

lazy loading 적용 전 Img network

고객은 최초에 홈페이지에 들어왔을 때 보이지 않는 컴포넌트의 40개 img load를 기다려야한다.

물론 이미지의 사이즈가 크지 않지만, 언제든 고객사 로고는 추가될 수 있으며 인터넷이 좋지 않은 상황에서는 더욱 차이가 날 수 있다.

2. lazy loading 적용 방식

위의 문제점을 해결하기 위해 img lazy loading을 적용하여 고객사 컴포넌트가 고객에게 보일 때 img load하는 방식으로 개선하였다.

Intersaction Observer API를 사용하여 스크롤을 내려 고객사 컴포넌트가 보일 때 img를 불러온다.

고객은 최초에 홈페이지에 들어왔을 때 40개의 img load를 기다리지 않아도 되어 그만큼 더 빠른 UX를 경험할 수 있게 된다.

3. lazy loading 적용 후 

고객이 최초에 홈페이지에 들어왔을 때 40개의 img를 요청하지 않는다.

lazy loading 적용 후 Img network

  • lazy loading 적용 전후 변화
    • requests : 58 => 18
    • resources : 540 KB  => 422 KB
    • Load time : 1.86s => 1.53s

사실 이미지 사이즈가 크지 않기 때문에 load time을 보면 0.3초밖에 줄어들지 않았다. 

하지만, 현재는 40개인 이미지가 언제든지 늘어날 수 있으며 인터넷 환경이 좋지 않은 상황에서는 차이가 더 나게된다.

 

network의 속도를 Fast 3G로 측정했을 때의 변화를 확인해보자.

[Fast 3G] lazy loading 적용 전 Img network
[Fast 3G] lazy loading 적용 후 Img network

  • lazy loading 적용 전후 변화
    • requests : 59 => 22
    • resources : 540 KB  => 423 KB
    • Load time : 35.11s => 31.89s

Fast 3G 네트워크 환경에서는 Load Time이 4초가 줄어드는 것을 확인할 수 있다.

 

4. 후기

이미지 최적화를 하는 방법은 lazy loading 외에도 webp를 사용하는 방법, cdn 캐싱 등 여러가지가 있다.

webp를 사용하면 더 작은 사이즈의 img를 load할 수 있어 적용해보았는데, 화질이 좀 별로였다.

화질을 높였더니 webp 사이즈가 png 사이즈와 비슷해서 적용하지 않았다.. 제플린에 있던 webp가 이상한걸까?..

 

결과적으로 아래 영상과 같이 스크롤을 내렸을 때 이미지를 불러오도록 하였다.

(회사를 공개하지 않기 위해 모자이크 처리하였습니다.)

lazy loading 후 img load 영상

 

728x90