Standalone Components 및 Chunk 전략으로 번들 크기 40MB에서 15MB로 최적화

Desconstruindo o Build: Chunks, Raio-X e a Anatomia do Navegador

Erick Gabriel dos Santos Alves2026년 6월 4일6분intermediate

AI 요약

Context

초기 번들 크기가 40MB에 달해 TTI(Time to Interactive) 지연 및 브라우저 메인 스레드 블로킹으로 인한 사용자 경험 저하 발생. 대규모 기업용 시스템(YMS) 특성상 복잡한 의존성으로 인해 빌드 결과물의 분석과 제어가 어려운 구조였음.

Technical Solution

Standalone Components 및 Tree-Shaking 도입을 통한 미사용 코드 제거 및 패키지 경량화
Esbuild 기반의 Chunking 전략을 적용하여 전체 시스템을 390개의 독립적 Fragment로 분할
Initial Chunk(로그인 등 필수 화면)와 Lazy Chunk(온디맨드 로드 화면)를 엄격히 구분하여 초기 로딩 부하 감소
Cache Busting을 위한 알파뉴메릭 파일 네이밍 적용으로 효율적인 브라우저 캐싱 메커니즘 구축
stats.json 기반의 Esbuild Bundle Analyzer를 활용해 중복 라이브러리 및 정적 데이터 포함 여부 정밀 진단
angular.json 내 Performance Budgets 설정을 통한 CI/CD 단계의 번들 크기 강제 제어

Impact

전체 번들 크기 40MB에서 15MB로 감소
Initial Bundle 크기 1.18MB 달성으로 3G 네트워크 환경 내 3초 미만 진입 보장
Lazy Chunk 개별 크기 500KB 이하 제한을 통한 런타임 성능 최적화

실천 포인트

- Initial Bundle 크기를 2MB 이하로 유지하여 TTI 최적화 - 500KB를 초과하는 Lazy Chunk 발견 시 @defer 블록이나 서브 라우팅으로 분리 검토 - TypeScript 파일 내 대규모 정적 JSON 포함 여부를 확인하고 assets 경로 또는 API 호출로 전환 - 중복 설치된 유사 기능 라이브러리(예: 다수의 Chart 라이브러리)를 단일 표준으로 통합

태그

#Tree-shaking #esbuild #Performance Budgets #Chunking #TTI

원문 읽기