webpack으로 성능 예산 설정

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

실제로 작동하는 모습을 보려면 새해까지 남은 날짜를 세는 앱을 참고하세요. Reactmoment.js로 빌드되었습니다. (점점 더 많은 프레임워크와 라이브러리를 사용하는 실제 앱과 마찬가지로 😉)

새해까지 남은 날짜를 세는 앱

측정

이 Codelab에는 이미 webpack으로 번들링된 앱이 포함되어 있습니다.

  1. 리믹스하여 수정을 클릭하여 프로젝트를 수정할 수 있도록 합니다.
  2. 터미널을 클릭합니다 (참고: 터미널 버튼이 표시되지 않으면 전체 화면 옵션을 사용해야 할 수 있음).
  3. 애셋과 크기의 색상 코딩된 목록을 가져오려면 콘솔에 webpack를 입력합니다.
webpack

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

번들 크기가 323KiB인 Webpack 출력
Webpack에서 대량의 JS 번들에 관해 경고 ⚠️

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

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

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

Webpack 성능 최적화 권장사항
Webpack 성능 최적화 추천 💁

맞춤 실적 예산 설정

적절한 성능 예산은 프로젝트의 특성에 따라 달라집니다. 직접 조사하는 것이 가장 좋습니다. 일반적인 규칙은 압축/최소화된 중요 요청 경로 리소스를 170KB 미만으로 제공하는 것입니다.

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

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

새 성능 예산은 바이트로 설정됩니다.

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

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

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

  1. warning (기본값): 노란색 경고 메시지를 표시하지만 빌드는 통과됩니다. 개발 환경에서 사용하는 것이 가장 좋습니다.
  2. error: 빨간색 오류 메시지가 표시되지만 빌드는 계속 통과됩니다. 이 설정은 프로덕션 빌드에 권장됩니다.
  3. false: 경고나 오류가 표시되지 않습니다.
빨간색 글꼴의 Webpack 성능 오류
Webpack 성능 힌트 '오류' 🚨

최적화

성능 예산의 목적은 성능 문제가 너무 심각해져서 해결하기 어려워지기 전에 사용자에게 경고하는 것입니다. 앱을 빌드하는 방법은 항상 여러 가지가 있으며, 일부 기법을 사용하면 로드 시간이 빨라집니다. (대부분은 JavaScript 최적화에 문서화되어 있습니다. 🤓)

프레임워크와 라이브러리는 개발자의 삶을 더 쉽게 만들어 주지만 최종 사용자는 앱이 어떻게 빌드되는지에는 관심이 없고 기능적이고 빠르기만 하면 됩니다. 성능 예산을 초과하는 경우 최적화할 수 있는 방법을 생각해 볼 때입니다.

실제로는 대규모 클라이언트 측 프레임워크를 교체하기가 어렵기 때문에 현명하게 사용하는 것이 중요합니다. 조금만 조사하면 작업을 똑같이 잘 수행하는 인기 라이브러리의 더 작은 대안을 찾을 수 있는 경우가 많습니다(date-fnsmoment.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입니다.

모니터링

webpack에서 성능 예산을 설정하는 데는 코드 몇 줄만 있으면 되며, 큰 종속 항목을 실수로 추가하면 경고가 표시됩니다. '눈에서 멀어지면 마음에서도 멀어진다'라는 말이 있지만 webpack을 사용하면 항상 성능 영향을 인식할 수 있습니다.