이미지 최적화 후 Lighthouse로 성능 측정하기
먼저 Lighthouse는 무엇이며, 뭐하는 친구인지 알아보자.
Lighthouse란 구글에서 개발한 웹 페이지의 품질을 개선할 수 있는 오픈 소스 형태의 자동화 도구이다.
Lighthouse에서 확인할 수 있는 지표는 아래와 같다.
First Contentful Paint
FCP
사용자가 특정 웹 페이지로 이동했을 때, 브라우저가 첫 번째 DOM의 콘텐츠를 렌더링하는 데 걸리는 시간
First Meaningful Paint
FMP
사용자가 페이지를 불러오기 시작하면서 스크롤을 내리지 않은 채 제일 먼저 볼 수 있는 영역에 존재하는 주요한 콘텐츠를 렌더링하는 데 걸리는 시간
Speed Index
웹 페이지를 불러올 때, 콘텐츠가 시각적으로 표시되는 데까지 걸리는 시간
First CPU Idle
웹 페이지가 최소한으로 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
Lighthouse 버전 6.0 이후로 사용되지 않는다. (Time To Interactive와 측정 기준이 유사했지만 의미 있는 결과값을 보이지 못했다.)
Time To Interactive
웹 페이지가 완전히 상호작용할 수 있는 상태가 될 때까지 걸리는 시간
Max Potential First Input Delay
FID
사용자가 웹 사이트와 처음 상호작용(버튼 클릭)할 때부터 브라우저가 실제로 해당 상호작용에 응답할 수 있을 때까지 걸리는 가장 긴 시간
(즉, 최악의 경우를 측정)
Total Blocking Time
TBT
웹 페이지가 사용자 입력에 응답하지 못하도록 차단된 총 시간
로딩 중 메인 스레드가 긴 시간동안 중단되어 응답을 받을 수 없을 정도로 걸린 시간
Largest Contentful Paint
LCP
뷰포트에서 가장 큰 콘텐츠 요소가 화면에 렌더링 될 때까지 걸리는 시간
Cumulative Layout Shift
CLS
이미지/광고의 느린 로딩, 비동기 동작, 동적 DOM 변경 등으로 웹 페이지의 레이아웃이 얼마나 변하는 지 측정한 값
사용자가 잘못된 클릭을 하도록 유발하는 시각적 불안정성을 체크하는 지표
** 초기 스윗의 라이트하우스 점수를 참고해보자!
성능을 측정하는 방식은 매우 간단하다.
크롬 익스텐션에서 설치 후, 탭 중 Lighthouse 탭에서 바로 확인이 가능하다.
정말 충격이 아니지 않을 수 없습니다... 열심히 개발했는데 11점이라니!
우리 팀 스윗의 서비스 특징상 이미지와 애니메이션, 3d이미지가 많이 사용되어서 성능이 좋지는 않을 것이라고 판단했지만,
11점???
말도안된다...
따라서 우리는 성능을 개선하기 위해 선택할 수 있는 방법 중
이미지를 최적화를 진행해야겠다고 다짐했다.
이미지 최적화를 진행하기에 가장 먼저 할 수 있는 것은 바로 '용량 줄이기'인데,
그 방법에는 여러 방법이 있지만,
저희는 'react-image-file-resizer' 라이브러리를 사용했다.
자세한 사용 방법은 다음에 기술하는 걸로 하고,
성능이 얼마나 올라갔나 봅시다.
11점에서 47점으로 꽤 오르기는 했는데...
그러나 여전히 좋은 성능은 아닌 것 같다.
**성능 최적화를 왜 해야할까?에 대한 개인적인 생각
현업에 계신 멘토님들 께서 흔히 하시는 말씀 중 하나가
'기능 구현은 가장 아랫단계의 고민거리다.'
라고 말씀하신다.
우리는 기능을 구현하는데에 급급하게 개발하고, 공부한다.
그만큼 우리는 기능 구현에 많은 비중을 두고 있는데,
사실 지난 웹잼에서 기능 구현을 진행할 때 보다, 빠르게 기능 구현 후 코드를 리팩토링 하고,
성능을 측정하며 어떻게 하면 성능을 개선할 수 있을지 생각하는 부분이 훨씬 즐거웠고,
정말 찐 개발자가 된 것 같아 스스로에게 취했던 기억이 있다.
우리의 꿈은 결국 '문제를 해결하는' 개발자이기 때문에, 이런 성능도 고려해가며 개발하고, 공부한다면
더욱 경쟁력 있는 개발자로 거듭나지 않을까 생각한다.
