웹 서비스 성능 분석 (2)
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
웹 개발자, 성능 최적화 담당자
난이도: 중간 (기술적 개념과 실무 적용 전략 포함)
핵심 요약
- JavaScript 과부하 최소화:
_app.js
및 서드파티 라이브러리 최적화,async
/defer
속성 활용 - 코드 분할과 지연 로딩: 라우트/컴포넌트 기준으로 공격적 코드 분할 적용 (Next.js 기반)
- 캐싱 전략 강화: 반복 방문 주요 페이지에 애플리케이션 데이터/정적 에셋 캐싱
섹션별 세부 요약
- 어드민 서비스 성능 최적화 전략
- 주요 기능 (에디터, 파일 업로드)의 INP(TTI) 지표 개선
- 무거운 라이브러리 (lodash 등) 대체 및 트리쉐이킹 지원 라이브러리 사용
- 대량 데이터 처리 시 디바운스/스로틀 적용, 불필요한 DOM 조작 제거
- 사내 공통 라이브러리 구축 고려사항
- 마이크로 서비스 분리: 서비스별 독립적 배포/테스트, 코드 품질 향상
- 모노레포 구조 설계: 패키지 빌드/배포 표준화, 브라우저 지원 범위 통일 (예:
browserslist-config
) - 공통라이브러리 성능 영향: 번들 크기, DX, 애플리케이션 성능 전반에 직접적 영향
- 개선 우선순위 제시
- 즉시 적용 가능한 항목:
- lodash
등 트리쉐이킹 불가 라이브러리 대체
- __app.tsx
불필요 코드 제거
- async/defer
속성 적용
- CLS 유발 요소 (CSS 미디어 쿼리로 대체)
- 기술 스택 분석
- Next.js 12.x~14.x 기반 SSR 프로젝트:
__app.js
,__buildManifest.js
사용 - 라이브러리 활용: React 17.0.2, Apollo Client, React Query, i18next, Emotion, Axios 0.25.0
- 성능 병목 지점: 14,647KB의 41개 자바스크립트 파일 로딩 (Next.js 리소스 포함)
결론
- 실무 적용 팁:
- lodash
대체 시 _.debounce
/_.throttle
대신 requestIdleCallback
사용
- Next.js의 next.config.js
에 unoptimized
옵션 생략하여 이미지 최적화 강제
- __buildManifest.js
에서 /
경로에 필요한 최소한의 chunk만 로딩하도록 dynamicImport
적용
- 최종 권장사항:
- 애드민 서비스의 주요 기능에 대한 성능 지표(INP, TTI)를 주기적으로 모니터링
- 공통 라이브러리 구축 시 브라우저 지원 범위 명확화 및 모노레포 구조 설계 확보
- CLS 개선: @emotion/react
의 CacheProvider
사용 시 key
속성으로 레이아웃 불안정 방지
> Disclaimer: 분석은 배포된 번들 코드 기준으로 이루어졌으며, 실제 소스 코드와 차이가 있을 수 있음.