• Stat size : Minification, Uglify 등의 변형이 일어나기 전의 크기
• Parsed size : Minification, Uglify 등의 변형이 일어난 후의 크기(최적화 후), 브라우저에서 파싱 후, 실행할 크기
• Gzipped size : Gzip 알고리즘으로 압축된 파일 크기, 네트워크를 통해 전송되는 크기
  Parsed size 와 Gzipped size를 줄이면, 브라우저에서 JS를 다운로드하고 실행하는 시간과 네트워크 상에서 전송되는 시간을 단축시킬 수 있다.
  
  

Next 빌드를 실행하면 chunk 번들과, 페이지 번들이 생성된다.
chunk 파일은 페이지 공통적으로 사용되는 것을 말하기 때문에 파일 사이즈를 줄이는 것이 좋다.
o : Static(정적) 페이지들
f : Dynamic(동적) 페이지들
First Load JS : 각 페이지 첫 로딩 시 필요한 JS 파일 크기
First Load JS shared by all : 모든 페이지가 공유하는 JS 파일들
✔️ chunks 추리

• chunks/447-0f6aa10a2699cdd3.js (116 kB)
  이 chunk는 next/dist, components, router.js 등 Next.js의 핵심 기능들을 포함
  @sentry 관련 코드도 포함되어 있어 에러 추적 기능도 담당

• chunks/4bd1b696-055358bcdc209afd.js (53.1 kB)
  react-dom-client.production.js를 포함
  React의 클라이언트 사이드 렌더링에 필요한 핵심 코드

• chunks/ec9a1384-54f8e1f68dc28c8e.js (36.9 kB)
  index.js 관련 코드들을 포함
  다양한 모듈의 진입점(entry point) 역할을 하는 파일들이 포함

next/dist와 Sentry 분리 최적화

• before
  
  
  

• Sentry 로딩 전략 변경
  기존: 모든 페이지 접속 시 Sentry 코드가 무조건 로드
  변경: 에러 발생 시에만 Sentry 코드를 동적으로 로드

즉, "Sentry를 동적 임포트로 전환하여 초기 번들 사이즈를 감소시키고, 실제 필요한 시점에만 로드되도록 최적화했다" 라고 설명할 수 있습니다.
비록 Sentry chunk 자체의 크기는 약간 증가했지만(70.98KB → 77.28KB), 이는 대부분의 사용자 경험에 영향을 주지 않는 트레이드오프라고 볼 수 있습니다.

• after

Before	After

Before	After

참고

[nextjs] bundle-analyzer를 사용한 최적화 일기 > pds
[Next.js] 페이지 성능 개선하기2-번들 사이즈 개선, Tree Shaking > 철스커의 멀티 저장소
[Web] Light house를 이용한 페이지 최적화 > devflate
Next.js에서 번들 사이즈 최적화하기 > Marshall K