webpack으로 성능 예산 설정

밀리카 미하즐리야
밀리카 미하즐리야

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

실제로 새해까지 남은 일수를 계산하는 앱을 보여 드리겠습니다. Reactmoment.js로 빌드되었습니다. (프레임워크와 라이브러리에 점점 더 많이 의존하는 실제 앱과 마찬가지로, 😉)

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

측정

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

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

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

번들 크기가 323KiB임을 보여주는 Webpack 출력
대용량 JS 번들에 관한 Webpack 경고 ⚠️

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

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

Webpack은 경고를 표시할 뿐만 아니라 번들 크기를 줄이는 방법에 관한 권장사항도 제공합니다. 웹 기초에서 권장 기법을 자세히 알아보세요.

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

맞춤 실적 예산 설정

적절한 성능 예산은 프로젝트의 성격에 따라 다릅니다. 항상 직접 조사하는 것이 가장 좋습니다. 일반적으로 바람직한 규칙은 압축/축소된 critical-path 리소스를 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: 경고 또는 오류가 표시되지 않습니다.
빨간색 글꼴의 웹팩 성능 오류
웹팩 성능 힌트 '오류' 🚨

최적화

성능 예산의 목적은 성능 문제가 너무 어려워지기 전에 경고하는 것입니다. 앱을 빌드하는 방법에는 항상 여러 가지가 있으며 일부 기술로 로드 시간을 단축할 수 있습니다. (대부분 자바스크립트 최적화에서 바로 확인할 수 있습니다. 🤓)

프레임워크와 라이브러리는 개발자의 업무 효율을 높여주지만 최종 사용자는 앱이 빌드되는 방식에는 크게 신경 쓰지 않으며 앱이 정상적으로 작동하고 빠르다는 사실만은 신경 쓰지 않습니다. 성능 예산을 초과하게 된다면 가능한 최적화에 대해 생각해 볼 때입니다.

실제 환경에서 대규모 클라이언트 측 프레임워크는 일반적으로 교체가 어려우므로 현명하게 사용하는 것이 중요합니다. 약간의 조사만 수행하면 작업을 수행하는 인기 라이브러리의 작은 대안을 찾을 수 있는 경우가 많습니다(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');

약간의 계산이 필요하지만 바닐라 자바스크립트를 사용하여 동일한 카운트다운을 구현할 수 있습니다.

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을 사용하면 성능에 미치는 영향을 항상 인지할 수 있습니다.