이 페이지는 Cloud Translation API를 통해 번역되었습니다.

webpack으로 성능 예산 설정

Milica Mihajlija

Webpack은 가져온 모든 파일을 결합하여 번들이라는 하나 이상의 출력 파일로 패키징합니다. 번들링은 좋지만 앱이 성장함에 따라 번들도 커집니다. 번들 크기가 너무 커져 애플리케이션을 로드하는 데 걸리는 시간에 영향을 미치지 않도록 번들 크기를 모니터링해야 합니다. Webpack은 애셋 크기를 기반으로 성능 예산 설정을 지원하며 번들 크기를 자동으로 확인할 수 있습니다.

작동하는 모습을 보려면 새해까지 남은 일수를 계산하는 앱을 살펴보세요. React 및 moment.js로 빌드됩니다. 프레임워크와 라이브러리를 점점 더 많이 사용하는 실제 앱과 마찬가지로 😉)

새해 첫날까지 남은 일수를 계산하는 앱

측정

이 Codelab에는 이미 webpack과 번들로 묶인 앱이 포함되어 있습니다.

리믹스하여 수정을 클릭하여 프로젝트를 수정할 수 있도록 합니다.
터미널을 클릭합니다. 터미널 버튼이 표시되지 않으면 전체 화면 옵션을 사용해야 할 수 있습니다.
색상으로 구분된 애셋 및 크기 목록을 보려면 콘솔에 webpack를 입력합니다.

webpack

기본 번들은 244KiB (250KB)보다 크기 때문에 노란색으로 강조 표시됩니다.

번들 크기가 323KiB인 webpack 출력 — Webpack에서 대용량 JS 번들에 관한 경고 ⚠️

이러한 경고는 프로덕션 모드에서 기본적으로 사용 설정되며 기본 임곗값은 애셋과 진입점(페이지의 초기 로드 중에 사용되는 모든 애셋의 조합) 모두에 대해 244KiB 비압축입니다.

애셋이 권장 크기 한도를 초과한다는 Webpack 경고 — Webpack에서 대용량 JS 번들에 관한 경고 ⚠️

Webpack은 경고를 제공할 뿐만 아니라 번들 크기를 줄이는 방법에 관한 권장사항도 제공합니다. 권장 기법에 관한 자세한 내용은 웹 기초를 참고하세요.

맞춤 실적 예산 설정

적절한 실적 예산은 프로젝트의 특성에 따라 달라집니다. 항상 직접 조사하는 것이 가장 좋습니다. 압축/축소된 중요 경로 리소스를 170KB 미만으로 전송하는 것이 좋습니다.

이 간단한 데모에서는 더 보수적으로 예산을 100KB (97.7KiB)로 설정해 보세요. webpack.config.js에 다음을 추가합니다.

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

새 실적 예산은 바이트 단위로 설정됩니다.

개별 애셋 100,000바이트 (maxAssetSize)
진입점의 경우 100,000바이트 (maxEntrypointSize)

이 경우 진입점 역할을 하는 번들은 하나뿐입니다.

힌트에 가능한 값은 다음과 같습니다.

warning (기본값): 노란색 경고 메시지를 표시하지만 빌드는 통과합니다. 개발 환경에서 사용하는 것이 가장 좋습니다.
error: 빨간색 오류 메시지가 표시되지만 빌드는 여전히 통과합니다. 이 설정은 프로덕션 빌드에 권장됩니다.
false: 경고나 오류가 표시되지 않습니다.

빨간색 글꼴로 표시된 Webpack 성능 오류 — Webpack 성능 힌트 '오류' 🚨

최적화

성능 예산의 목적은 성능 문제가 해결하기 어려워지기 전에 이를 경고하는 것입니다. 앱을 빌드하는 방법은 항상 두 가지 이상 있으며, 일부 기법은 로드 시간을 단축합니다. (이러한 방법 중 다수는 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에서 성능 예산을 설정하는 데는 몇 줄의 코드만 있으면 되며 실수로 큰 종속 항목을 추가하면 경고가 표시됩니다. '눈에 띄지 않으면 잊어버린다'는 속담이 있지만 webpack을 사용하면 언제든지 성능 영향을 파악할 수 있습니다.