vite

25 Apr 2022

브라우저에서 ESM(es 모듈)을 지원하기 전까진 자바스크립트 모듈화를 사용하기 위해 webpack, rollup, parcel 같은 번들러들을 썼다.

이런 번들러들을 사용할 때 1000개가 넘는 js모듈이 있는 거대한 프로젝트일수록 트랜스파일이나 HMR을 사용할 때 편집한 코드가 브라우저까지 반영될 때 까지의 시간이 많이 들었다.

vite는 ESM을 활용하는 자체 개발 서버를 가지고 있고 네이티브 언어로 작성된 js 도구등을 활용하여 웹팩보다 훨씬 더 빠른 속도를 제공한다.

신속한 서버구동

cold-starting 방식으로 개발서버를 구동할 때 번들러 기반의 도구일 경우 모든 소스코드에 대해 크롤링과 빌드작업이 선행되어야한다.

vite는 dependencies(개발시 내용이 바뀌지 않는 코드)와 source code(jsx, css, 컴포넌트처럼 컴파일링이 필요하고 수정이 잦은 non-plain javascript) 두 가지 카테고리로 나누어 개발서버를 시작하도록 함으로 성능을 높였다.
vite의 사전 번들링 기능은 Esbuild를 사용하고 있다. Go로 작성된 Esbuild는 기존 번들러 대비 10배 빠른 번들링 속도를 갖고있다.
vite는 Native ESM을 이용해 소스코드를 제공한다. 즉, 브라우저가 곧 번들러의 역할을 한다.
vite는 브라우저의 판단 아래 특정 모듈에 대한 소스코드를 요청하면 이를 전달한다.

webpack의 bundle based dev server

vite의 native ESM based dev server

기존 번들러의 느렸던 소스코드 갱신

기존 번들러기반으로 개발을 진행할 때 소스코드를 업데이트 하게되면 번들링을 다시 해야했다. 즉, 서비스가 커질수록 소스코드 갱신시간 또한 증가할 수 밖에 없었다. 모든 파일을 번들링하고 웹페이지에서 불러오는 비효율적인 이슈를 우회하고자 HMR(Hot Module Replacement)라는 대안이 나왔으나 HMR도 마찬가지로 앱 사이즈가 커질수록 갱신에 필요한 시간이 늘어났다.

vite는 ESM을 이용해 HMR을 지원한다. 어떤 모듈이 수정되면 vite는 수정된 모듈과 관련된 부분만을 교체하며 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐이다. 전 과정에서 ESM을 이용하기에 앱사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않는다.
vite는 HTTP 헤더를 이용해 소스코드는 304 Not Modified로, 디펜던시는 Cache-Control: max-age=31536000,immutable 을 이용해 캐시되도록 하여 퍼포먼스를 높였다.

배포시 번들링 과정은 필요하다

ESM은 비교적 최근에 지원되기 시작하여 실제 배포시 사용이 브라우저 환경이 있을 수 있다. 또 네트워크를 통해 필요한 시점에 해당 모듈을 요청하기에 HTTP/2를 이용하더라도 오버헤드가 발생될 수 있다. 따라서 배포시에는 번들링 과정이 필수적이기 때문에 빌드커맨드를 이용하고 빌드 퍼포먼스 최적화를 진행한다.

번들링시엔 Rollup을 쓰는데 왜?

Esbuild는 코드스플리팅과 css와 관련된 처리가 아직 미비하여 조금 더 검증된 Rollup을 채용하였다.

여담이지만 웃긴 이미지를 찾아서 가져와봤다

참고: vite 공식문서