[개선] 프로젝트 분리하여 빌드 속도 개선
참고
해당 게시글은 이전에 제가 빌드를 개선했던 방법 중 한가지를 소개하기 위해 작성했습니다.
너무 예전에 진행하였어서 동일한 환경이 아니고 비슷한 환경을 억지로 만들어서 진행했습니다.
프로젝트 개선
프로젝트를 개선하는 방법이 많이 있습니다.
- 이미지 캐싱
- 코드 스플릿
- 빌드 속도 개선
- 사용하는 패키지를 더 좋은 것으로 변경
- 등등등
이번 게시글에서는 빌드 속도를 개선한 사례를 작성해보도록 하겠습니다.
NextJS 기준으로 작성되어 있으나 다른 프레임워크에서도 비슷하게 할 수 있을 것 같습니다.
번들 사이즈 측정 방법
NextJS에서 번들 사이즈 측정하는 방법은 간단합니다.
next.config.js 파일에서 아래 설정을 해줍니다.
ANALYZE 값이 true인 경우만 분석도구를 실행하기 위함입니다.
const withBundleAnalyzer = require('@next/bundle-analyzer')({
enabled: process.env.ANALYZE === 'true',
});
// ...
module.exports = withBundleAnalyzer(nextConfig);
터미널에 아래 명령어를 입력해줍니다.
ANALYZE=true yarn build
사긴이 지나면 빌드가 되고 결과 페이지가 표시될 것입니다.
번들 사이즈 분석 및 개선하기
번들 사이즈 분석 결과는 아래와 같습니다.
편의상 결과 이미지는 stat, parsed, gzip 중 stat만 작성하도록 하겠습니다.
최종 값은 하단에 적어두겠습니다.
보시면 babylonjs 관련 패키지가 엄청 큰 것을 확인하실 수 있습니다.
거의 프로젝트의 50%를 담당하고 있습니다.
babylonjs를 사용은 해야하는데 어떻게 사용하면서 개선할 수 있을가요?
저희는 서비스를 분리하였습니다.
웹에서 3D 파일을 보여주기 위해 babylonjs를 사용하고 있었습니다.
3D 파일을 볼 수 있는 서비스를 하나 더 만들었습니다.
그리고 쿼리 파라미터로 값을 넘겨 해당 서비스에서 파일을 볼 수 있도록 하였습니다.
그 결과 메인 프로젝트에서는 babylonjs 관련 패키지를 모두 삭제하였습니다.
다시 번들 사이즈를 분석하였습니다.
(node_modules 관련 이미지를 지웠는지 없어서 올리지 못 하였습니다...)
파일 사이즈가 엄청 줄어든 것을 확인할 수 있습니다.
결과
정량적인 빌드 속도가 기억이 나지는 않습니다.
그러나 그 당시 체감상 40% 정도는 빨라졌던 것으로 기억합니다.
실제 위 결과의 차이만 보아도 많이 개선되었습니다.
- stat : 59.52MB -> 30.05MB (약 49.51%)
- parsed : 26.51MB -> 13.57MB (약 48.81%)
- gzip : 6.51MB -> 3.67MB (약 43.63%)
해당 게시글에서는 꼭 코드 스필릿이나 캐싱, 특정 패키지 변경이 아닌 다른 방법으로도 개선할 수 있다는 것을 전달하고 싶었습니다.
실제로 빌드 속도 뿐만이 아니라 서비스가 분리되어 배포와 버전 관리도 따로 할 수 있었습니다.
'공유 > 기타' 카테고리의 다른 글
VSCode 엔터 키, 정규식 검색하기 (0) | 2024.08.02 |
---|---|
headless 컴포넌트 도입 (0) | 2024.07.31 |
VSCode에서 특정 단축키가 안돼요. (0) | 2024.07.12 |
Dead Code 찾기, 사용하지 않는 파일, 변수 찾기 (1) | 2024.07.10 |
Visual Studio Code 단축키 (macOs) (0) | 2024.06.24 |