재테크 블로그 프로젝트 (8) - 리팩토링 [번들 사이즈 측정]

개요 

프로젝트가 마감되고 12월 셋째 주를 쉬고 크리스마스도 보내고 가족들과도 많은 시간을 보냈다.

이제껏 진행했던 여느 프로젝트처럼 막판에 부랴부랴 기능이 돌아가고 오류가 나지 않게끔 하느라 애썼다.

하지만, 불편하고 불필요한 코드가 계속 눈엣가시처럼 걸려서 한 번은 치워야겠다 하고 다짐을 했다.

 

이제는 정말 1월이 되기 전 끝 마쳐야 할 거 같아서 진행하려하고 당장 생각한 목표는 다음과 같다.

1. 번들사이즈 감소
2. 무한 스크롤 미반영 컴포넌트 반영
3. getServerSideProps 활용한 데이터 페칭
4. 불필요한 파일, 코드삭제
5. 비효율적인 로직 변경

 

각 요소들이 시간이 얼만큼 잡아먹을지는 모르겠지만, 첫 매듭을 번들 사이즈를 줄이면서 시작하려고 한다.

 

Next 프로젝트의 번들사이즈

NextJS로 만든 애플리케이션을 사용하려고 해당 서비스 주소(우리 서비스의 경우 FLEX앱 주소)로 접속하는 경우 클라이언트에게 전달되는 JS 파일의 크기를 의미하고 번들의 경우 해당 페이지를 보여주는 데 사용되는 라이브러리, 종속성을 하나의 파일로 묶은 것을 의미한다.

 

해당 번들 사이즈가 클 경우 발생하는 문제는 다음과 같다.

1. 로딩 속도 저하

• 큰 번들은 네트워크를 통해 다운로드하는 데 시간이 더 소요되고 네트워크가 느린경우 UX를 저하시킬 수 있다
• 또한, 우리 서비스와 다르게 모바일 서비스의 경우 모바일 네트워크 환경은 더욱 느리기에 더 큰 영향을 받는다.

2. TTI(Time to Interactive) 증가

• 다운뿐만 아닌 js파일을 파싱, 실행하는데 오랜 시간이 걸리기에 첫 상호작용시간인 TTI가 증가한다
• 당연히 위 아래 이유로 인해 사용자의 이탈률을 증가시키는 악영향을 초래한다.

3. 메모리, 성능 문제

• 번들 사이즈가 클수록 사용자의 디바이스의 더 많은 메모리를 소비하고 CPU사용량을 증가시킨다.

 

번들사이즈의 증가에 따른 문제들이 모두 서비스를 사용하는 사용자와 직관되기에 애플리케이션을 개발하고 마무리하는 과정에선 꼭 필요한 과정이라고 생각이 들었다.

 

번들사이즈 측정

번들 사이즈 측정방법에는 여러 가지가 있지만 난 간단한 방법 두 가지와 라이브러리를 설치해 측정하는 방법 총 세 가지 방법을 통해 측정해 보았다.

 

1. NextJS 내장 번들 사이즈 확인

흔히 사용하는 npm run build를 하는 경우 자동으로 번들크기를 분석 후 터미널을 통해 보여준다.

이를 통해 각 페이지의 First Load Js크기와 각 청크의 크기를 확인할 수 있다.

 

각 페이지별 Size(좌) First Load JS(우)에 대한 정보들이 나온다

Size : 페이지 자체의 번들크기로 해당 페이지 고유의 코드만을 포함

 - 해당 사이즈를 통해 해당 페이지의 최적화가 필요한지 분석이 가능하다.

First Load JS : 해당 페이지 처음 로드할 때 클라이언트로 전송되는 모든 JS의 총합을 의미(공용 청크, 라이브러리, 런타임 코드)

 - 사용자의 첫 로딩 성능이 어떨지에 대한 짐작이 이를 통해 가능하다.

 

두 요소를 보니 초기 코드자체가 많은 simulation의 경우 두 요소가 적절히 비례해서 증가한 반면, 초기 코드는 적지만 필요로 하는 청크 및 라이브러리가 많은 prediction페이지의 경우 Size에 비해 큰 First Load JS 크기를 가지는 것을 보인다.

 

2. light house를 이용한 번들 사이즈 확인

크롬 개발자모드에서 Lighthouse 탭을 통해 보고서를 생성하면 저번 포스트에 올린 거처럼 여러 분석 결과를 조회할 수 있다.

 

트리맵 조회를 클릭 시 아래처럼 리소스를 어디서 얼마큼 사용 중인지 조회가 가능하다.

또한, 사용되지 않는 JavaScript의 경우 얼마나 포함되었는지 또한 확인이 가능하다.

 

트리맵이 아닌 성능 분석에선 TBT, LCP, FCP 등 여러 관점에서의 로딩, 실행 시간들을 확인할 수 있다.

lighthouse를 통해 한 최적화에서 이 트리맵을 보거나  사용하지 않은 바이트를 고려하지 않았는데 저것도 추적하면 성능 점수를 향상할 수  있을 것 같다.

 

3. next/bundle-analyzer 통해 분석

나는 보통 공식 문서, 공식 라이브러리 이런 것들을 좋아하는데 일단 당연히 공식인 만큼 신뢰성이 높고 호환성 또한 높은 경우가 많은 데서 오는 호감이 아닐까 싶다.

추가로, 에러가 발생하더라도 깃허브 이슈에 반드시 나와 같은 문제를 겪는 사람이 있어 사용 중에 문제를 겪어도 탈출구가 있다는 게 장점이 아닐까 싶다.

 

아무튼 이건 NextJS에서 제공하는 공식 번들 분석 도구로, 위와 같은 시각화된 번들 내용을 조회가 가능하다. 

사용 방법은 다음과 같다.

1. next/bundle-analyzer 설치

npm install @next/bundle-analyzer

 

2. 라이브러리 설치 후 next.config.js에 추가

import withBundleAnalyzer from '@next/bundle-analyzer';

const nextConfig = {
 ... 기존 config 정보 ...
};

export default withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})(nextConfig);

 

3. 아래 명령어 실행 후 생성된. next/analyze/client.html을 통해 조회 가능

ANALYZE=true next build

 

client.html

우측의 경우엔 해당 트리맵에 대한 정보들이 있다.

 

당연히 번들을 구성하는 파일들 중 크기 별로 크게, 작게 시각화해 보여준 것으로, 클릭 시 해당 파일이 어떤 파일들로 이루어져 있는지 관계 또한 확인할 수 있다.

이 중 번호로 된 파일 8066.js 같은 경우  동적 코드 분할을 통해 분리된 청크 파일들을 의미한다. 따라서 페이지에서 사용되는 기본 파일은 페이지 파일로 페이지 폴더로 명시되어 있고, 필요시 가져오는 동적 코드의 경우에는 번호로 명시되어 있는 것을 볼 수 있다.

 

결론

이와 같은 동적 파일들을 적절하게 lazy 또는 dynamic을 통해 필요할 때만 파일들을 로드하도록해 분할 최적화를 할 수 있다.

또한 필요하지 않은 모듈이 포함된 경우 해당 모듈을 분리시키거나 코드를 잘게 쪼개 필요한 부분만 가져오도록 하는 것이 좋을 것 같다.

다음 포스트에선 위 세 방법을 통해 분석한 번들 사이즈를 통해 불필요 코드 삭제, 서드 파티 라이브러리 최적화, 정적 콘텐츠 최적화 등 번들 사이즈를 줄여보도록 하겠다