Webpack 빌드 속도 최적화, 단일 번들 최적화 방법 | noParse

 

 

---

 

개요

noParse 옵션을 활용해 jQuery, Lodash, React 등 대형 라이브러리의 빌드 시간을 줄이고 효율적으로 관리하는 방법을 알아봅니다.

 

 

Webpack의 JS 파일 처리 흐름

웹팩(Webpack)은 JavaScript 파일을 처리할 때 기본적으로 다음 세 단계를 거칩니다.

1. 파싱(Parsing)
   • import, require, export, 동적 import() 같은 구문을 읽어 의존성 그래프를 만듭니다.
2. 로더(Loader) 변환
   • 설정된 로더를 적용해 코드 변환을 수행합니다.
     (예: TypeScript → JS, SCSS → CSS)
3. 번들(Bundle) 생성
   • 최종적으로 여러 모듈을 하나 또는 여러 청크로 합쳐 번들링합니다.

빌드 시간을 최적화하려면 각 단계의 처리 범위를 줄이거나 건너뛰는 것이 효과적입니다.
이때 noParse 옵션을 사용하면 파싱 단계를 생략할 수 있습니다.

 

 

파싱 과정을 건너뛰면 좋은 이유

React, Lodash, jQuery 같은 대형 라이브러리는 파일 크기가 크기 때문에 매번 파싱하면 빌드 시간이 길어집니다.
noParse를 적용하면 Webpack이 내부를 불필요하게 분석하지 않으므로 빌드 속도가 훨씬 빨라집니다.

 

 

728x90

 

noParse란?

noParse 옵션은 웹팩에게 특정 파일이나 디렉토리를 파싱하지 말라고 지시하는 설정입니다.

주로 이미 번들링된 라이브러리나 외부 라이브러리에 사용됩니다. 의존성 분석이 필요 없으므로, 내부를 열어보지 않고 그대로 번들에 포함합니다.

• 예시: jQuery, Lodash, React.production.min.js 등

 

noParse 적용 예시

webpack.config.js

const path = require('path');

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader',
      },
    ],
    // noParse 설정
    noParse: [
      /jquery|lodash/, // 정규식
      path.resolve(__dirname, 'src/libs/react.production.min.js'), // 단일 파일
    ],
  },
};

 

 

Webpack noParse 설정 방법

정규식 설정

// webpack.config.js
module.exports = {
  module: {
    rules: [
      // 로더 설정 예시
      {
        test: /\.js$/,
        use: 'babel-loader',
      },
    ],
    noParse: /jquery|lodash/, // 정규식으로 noParse 대상 지정
  },
};

경로를 지정하여 설정

const path = require('path');

module.exports = {
  module: {
    noParse: [
      path.resolve(__dirname, 'src/libs/jquery.min.js'),
      path.resolve(__dirname, 'src/libs/lodash.min.js'),
    ],
  },
};

함수로 조건 설정

module.exports = {
  module: {
    noParse: (content) => {
      // 파일 경로에 특정 문자열이 포함되면 noParse
      return /jquery|lodash/.test(content);
    },
  },
};

 

 

noParse 적용 대상과 조건

적용 가능한 경우

• 단일 UMD/IIFE 번들에만 적용 → 하나의 파일로 완전하게 동작 가능
• 내부 의존성 트리가 없는 라이브러리 → 파일 내부에서 require()나 import를 사용하지 않음
• 파싱할 필요가 없는 완성된 파일
• AMD 또는 CommonJS 스타일로 작성된 외부 라이브러리

예시) 아래처럼 프로젝트에 파일 저장하여 사용

src/lib/some-lib.min.js

 

 

적용 불가 경우

• ESM 기반 라이브러리 → 내부 모듈 트리가 있어서 파싱 필수
• 트리쉐이킹이 필요한 구조 → 웹팩이 코드를 읽어야 최적화 가능
• 런타임 템플릿 처리·조건문 등이 많은 라이브러리 → 실행 전 파싱 필요
• 번들링된 단일 파일 형태로 제공되지 않는 경우 → 모듈 해석 필요
• node_modules에서 ESM으로 import되는 대부분의 라이브러리 → noParse 불가

 

대표적인 단일 UMD/IIFE 번들

카테고리	라이브러리	파일명
React 생태계	React	react.production.min.js, react.development.js
	ReactDOM	react-dom.production.min.js, react-dom.development.js
jQuery 계열	jQuery	jquery.min.js, jquery.slim.min.js
Moment / Date 계열	Moment.js	moment.min.js
	Day.js	dayjs.min.js (의존성 없음, standalone)
Utility (Lodash/Underscore)	Lodash	lodash.min.js
	Underscore	underscore-min.js
HTTP 클라이언트	Axios	axios.min.js (IIFE/UMD 단일 파일)
Chart / Visualization	Chart.js	chart.js (standalone UMD 포함)
	D3.js	d3.min.js (UMD 단일 번들 버전도 제공)
Redux 계열 UMD	Redux	redux.min.js
	Redux Thunk	redux-thunk.min.js
	Redux Toolkit	redux-toolkit.umd.js
Utility UMD	uuid	uuid.min.js
	validator	validator.min.js
	anime.js	anime.min.js
	Three.js	three.min.js (UMD 제공)
Polyfill / Runtime	regenerator-runtime	regenerator-runtime.js
	core-js	core-js-bundle.min.js (bundle 버전은 단일 파일)

 

noParse 적용하면 안 되는 라이브러리

카테고리	라이브러리	설명
CSS-in-JS	styled-components	런타임에 태그드 템플릿 처리·해싱 필요 → 내부 코드 실행 필수
상태관리 / Redux 계열	redux-toolkit	내부에서 여러 모듈을 조합해 빌드됨 → 실제 의존성 트리 해석 필요
라우팅	react-router	동적 import, 조건부 로직 포함 → AST 파싱 필요
HTTP 클라이언트	axios (npm import 사용 시)	ESM 구조와 하위 모듈 읽기 필요 → noParse 시 정상 동작 보장 안 됨
백엔드 SDK	firebase	내부에서 tree-shaking 및 모듈 기반 구조 → 파싱되어야 번들 최적화 가능
상태관리 라이브러리	zustand	ESM 구조 + 내부 합성 로직 포함
	recoil	동작에 필요한 내부 모듈 로딩 존재
UI 컴포넌트	MUI (@mui/**)	대부분 ESM, 내부 의존성 매우 복잡 → 파싱·트리쉐이킹 필수
Utility (ESM 버전)	lodash-es	ESM 기반이라 tree-shaking 필요 → noParse 적용 시 최적화 불가

 

빌드 시간을 줄이는 다른 방법

noParse로도 처리할 수 없는 경우,Webpack의 코드 분리 기능(splitChunks)을 활용하면 빌드 효율을 높일 수 있습니다.

즉 noParse가 적용되지 않는 ESM 기반 라이브러리나 트리쉐이킹이 필요한 코드도 splitChunks를 통해 효율적으로 관리할 수 있습니다.