Webpack은 가져온 모든 파일을 결합하여 번들이라는 하나 이상의 출력 파일로 패키징합니다. 번들링은 좋지만 앱이 성장함에 따라 번들도 커집니다. 번들 크기가 너무 커져 애플리케이션을 로드하는 데 걸리는 시간에 영향을 미치지 않도록 번들 크기를 모니터링해야 합니다. Webpack은 애셋 크기를 기반으로 성능 예산 설정을 지원하며 번들 크기를 자동으로 확인할 수 있습니다.
작동하는 모습을 확인하려면 새해까지 남은 일수를 계산하는 앱을 살펴보세요. React 및 moment.js로 빌드됩니다. 프레임워크와 라이브러리를 점점 더 많이 사용하는 실제 앱과 마찬가지로 😉)
측정
이 Codelab에는 이미 webpack과 번들로 묶인 앱이 포함되어 있습니다.
- 리믹스하여 수정을 클릭하여 프로젝트를 수정할 수 있도록 합니다.
- 터미널을 클릭합니다 (참고: 터미널 버튼이 표시되지 않으면 전체 화면 옵션을 사용해야 할 수 있음).
- 색상으로 구분된 애셋 및 크기 목록을 보려면 콘솔에
webpack
를 입력합니다.
webpack
기본 번들은 244KiB (250KB)보다 크기 때문에 노란색으로 강조 표시됩니다.
![번들 크기가 323KiB인 webpack 출력](https://web.developers.google.cn/static/articles/codelab-setting-performance-budgets-with-webpack/image/webpack-output-showing-bu-b3af83f2a88bd.png?hl=ko)
이러한 경고는 프로덕션 모드에서 기본적으로 사용 설정되며 기본 임곗값은 애셋과 진입점(페이지의 초기 로드 중에 사용되는 모든 애셋의 조합) 모두에 대해 244KiB 비압축입니다.
![애셋이 권장 크기 한도를 초과한다는 Webpack 경고](https://web.developers.google.cn/static/articles/codelab-setting-performance-budgets-with-webpack/image/webpack-warning-the-asse-27a6d7431ec24.png?hl=ko)
Webpack은 경고를 제공할 뿐만 아니라 번들 크기를 줄이는 방법에 관한 권장사항도 제공합니다. 권장 기법에 대한 자세한 내용은 웹 기초를 참고하세요.
![Webpack 성능 최적화 권장사항](https://web.developers.google.cn/static/articles/codelab-setting-performance-budgets-with-webpack/image/webpack-performance-optim-d16a700a697eb.png?hl=ko)
맞춤 실적 예산 설정
적절한 실적 예산은 프로젝트의 특성에 따라 달라집니다. 항상 직접 조사하는 것이 가장 좋습니다. 압축/축소된 주요 경로 리소스를 170KB 미만으로 전송하는 것이 좋습니다.
이 간단한 데모에서는 더 보수적으로 예산을 100KB (97.7KiB)로 설정해 보세요. webpack.config.js
에 다음을 추가합니다.
module.exports = {
//...
performance: {
maxAssetSize: 100000,
maxEntrypointSize: 100000,
hints: "warning"
}
};
새 실적 예산은 바이트 단위로 설정됩니다.
- 개별 애셋 100,000바이트 (maxAssetSize)
- 진입점의 경우 100,000바이트 (maxEntrypointSize)
이 경우 진입점 역할을 하는 번들은 하나뿐입니다.
hints의 가능한 값은 다음과 같습니다.
warning
(기본값): 노란색 경고 메시지를 표시하지만 빌드는 통과합니다. 개발 환경에서 사용하는 것이 가장 좋습니다.error
: 빨간색 오류 메시지가 표시되지만 빌드는 여전히 통과합니다. 이 설정은 프로덕션 빌드에 권장됩니다.false
: 경고나 오류가 표시되지 않습니다.
![빨간색 글꼴로 표시된 Webpack 성능 오류](https://web.developers.google.cn/static/articles/codelab-setting-performance-budgets-with-webpack/image/webpack-performance-error-7a9bd2fa41f47.png?hl=ko)
최적화
성능 예산의 목적은 성능 문제가 해결하기 어려워지기 전에 이를 경고하는 것입니다. 앱을 빌드하는 방법은 항상 두 가지 이상 있으며, 일부 기법은 로드 시간을 단축합니다. (이러한 방법 중 다수는 JavaScript 최적화에 설명되어 있습니다. 🤓)
프레임워크와 라이브러리는 개발자의 작업을 더 쉽게 해 주지만 최종 사용자는 앱이 어떻게 빌드되는지보다는 앱이 작동하고 빠른지 여부만 중요하게 생각합니다. 실적 예산을 초과하는 경우 최적화 방법을 고려해 보세요.
실제 환경에서는 대규모 클라이언트 측 프레임워크를 교체하기가 어렵기 때문에 현명하게 사용하는 것이 중요합니다. 약간의 조사를 통해 인기 라이브러리와 동일한 작업을 수행하는 더 작은 대안을 찾을 수 있습니다(date-fns는 moment.js의 좋은 대안입니다). 프레임워크나 라이브러리가 성능에 상당한 영향을 미치는 경우 아예 사용하지 않는 것이 더 나을 때도 있습니다.
사용되지 않는 코드를 삭제하는 것은 대규모 서드 파티 라이브러리가 포함된 앱을 최적화하는 좋은 방법입니다. 사용되지 않는 코드 삭제 가이드에서 이 프로세스를 자세히 설명합니다. 다음은 moment.js를 사용하지 않고 카운트다운 코드를 재작성하는 빠른 방법입니다.
app/components/Countdown.jsx에서 다음을 삭제합니다.
const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');
다음 줄을 삭제합니다.
const moment = require('moment');
약간의 수학이 필요하지만 표준 JavaScript로 동일한 카운트다운을 구현할 수 있습니다.
const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));
이제 package.json
에서 moment.js
를 삭제하고 콘솔에서 webpack을 다시 실행하여 최적화된 번들을 빌드합니다.
짜잔! 223KiB (230KB)를 줄였으며 앱이 예산 범위 내에 있습니다.🎉
![최적화 후 Webpack 번들 크기 출력은 97.7KiB입니다.](https://web.developers.google.cn/static/articles/codelab-setting-performance-budgets-with-webpack/image/webpack-bundle-size-outpu-3d8bf5c8774b7.png?hl=ko)
모니터링
webpack에서 성능 예산을 설정하는 데는 몇 줄의 코드만 있으면 되며 실수로 큰 종속 항목을 추가하면 경고가 표시됩니다. '눈에 띄지 않으면 잊어버린다'는 속담이 있지만 webpack을 사용하면 언제든지 성능 영향을 파악할 수 있습니다.