[우이삭] Vite JS

수연·2023년 12월 5일

Wooisac

목록 보기
2/9

번들러란?

브라우저에서 ES Modules 를 지원하기 전까지 자바스크립트의 모듈화는 네이티브 레벨에서 지원되지 않았다.

import App from './App.js' // 모듈화 그게 뭔데 1

export { App }; // 모듈화 그게 뭔데 2

그래서 이런 모듈 파일들을 브라우저에서 실행시킬 수 있는 형태로 파일을 연결하는 번들링 이 필요했다. 그리고 이를 가능케 해주는 것을 번들러 라고 부른다. 우리가 흔히 사용하는 Webpack, Rollup, Parcel, ESbuild 그리고 이번 글에서 다루는 Vite 도 번들러에 속한다.

번들러 과정은 중복 import 문제로 네트워크가 파일을 중복으로 불러오지 않도록 하고 이는 트리 셰이킹, 지연 로딩 등에서 더욱 효과적인 성능을 낸다. 또한 이제는 모듈을 불러오는 기능을 지원하는 브라우저가 많아졌음에도 모든 브라우저가 모듈 기능을 지원하는 것은 아님으로 번들링은 성능 최적화를 위해 사용되기도 한다.

Vite 를 쓰는 이유

애플리케이션의 규모가 커짐에따라 번들러가 파일을 처리하고 적용하는 속도가 늦어짐으로써 병목현상이 생겼고, 오히려 불편함으로 초래하게 되었다. Vite 는 이런 문제에 초점을 맞춰 번들링 시간을 효과적으로 줄인 번들러 도구이다.

글을 읽기 전, 이 모든 장점은 개발 빌드에서 적용된다는 것을 인지하고 넘어가야 한다!

1. 캐싱된 데이터가 없어도 빠른 빌드를 한다

콜드 스타트 방식이란 처음 번들링을 하여 이전에 번들링한 소스 코드가 없는 상태로 번들링을 하는 것을 의미한다. 이 경우 폴더 내에 존재하는 모든 파일에 대해 크롤링과 빌드작업이 끝난 후에 코드가 만들어진다. 이렇게 긴 과정을 Vite 는 어떻게 해결했을까?

Vite 는 애플리케이션 내의 데이터를 아래 두가지로 카테고리화 하여 빌드 시간을 단축시켰다.

dependencies

dependencies 파일들은 개발 시 수정이 거의 없는 소스 코드를 의미한다. Vite 는 처음 실행될 때 개발 도중에 바뀌지 않을 Javascript 모듈 파일 들에 대해 사전 번들링을 진행함으로써 번들링 속도를 단축했다. Vite 의 사전 번들링은 Esbuild 를 사용하고 있다.

주로 Javascript 모듈 들로 이뤄진 라이브러리 파일들이 이에 해당한다.

source code

자주 변경되는 컴포넌트, 혹은 JSX, CSS, Vue, Svelt 와 같이 컴파일이 필요한 non-plain JavaScript 코드, 즉 순수 자바스크립트 코드가 아닌 파일들은 브라우저에게 번들링 작업의 일부를 위임하여 시간을 단축한다. 이를 Native ESM 번들링이라고 한다.

기존 번들링

모든 파일의 번들링이 끝난 이후 서버가 준비된다.

Native ESM 번들링

서버가 준비된 뒤 동적으로 파일을 번들링 하여 로딩 시간을 단축시킨다.

브라우저에서 동적으로 import 하는 방식을 지원함으로 Vite JS 은 동적으로 불러오는 모듈에 대해서만 처리를 하면된다.

2. 소스 코드 변경 시 일부만 교체한다.

기존의 번들러들은 소스 코드가 변경되면 모든 코드를 다시 번들링 과정을 거쳐야했다. 아주 일부만 변경되었을 뿐인데도 모든 코드를 다시 번들링 하는 과정은 무척이나 비효율적이었다. Vite 는 다음 방법을 통해 소스 코드의 변경을 빠르게 반영할 수 있다.

  1. **HMR**

HMR(Hot Module Replace) 는 변경된 코드를 즉시 확인할 수 있도록, 나머지 코드에 영향을 끼치지 않고 특정 모듈만 변경을 할 수 있도록 도와준다. 하지만 애플리케이션의 규모가 커질 수록 모듈간의 종속성이 커지고, 변경되는 모듈을 찾는 데 더 오랜 시간이 걸린다.

Vite 는 ES 모듈을 기반으로 수정된 모듈과 가장 가까운 모듈의 연결 고리를 찾이 무효화 한 뒤, 다시 연결하면 되므로 애플리케이션의 크기와 상관없이 HMR 을 항상 일관되게 처리할 수 있도록 한다.

  1. **캐싱**

뿐만 아니라 http 헤더를 사용하여 속도를 높일 수 있다. 위에서 카테고리한 source Codedependencies 의 경우 각각 304 Not ModifiedCache-Control: max-age=31536000,immutable 로 캐싱되어 요청을 최소화한다.

Vite JS 한계?

개발 빌드 시에만 용이하다.

빌드는 두가지가 있다. 개발 진행 사항을 확인하기 위한 개발 빌드, 그리고 실제 배포를 위한 프로덕션 빌드.

Vite JS 는 개발 빌드를 위한 서버를 자체적으로 제공해준다. (npm run dev…) 프로젝트 시 Vite 로 실행한 개발 서버가 변경 사항을 몹시 빠르게 반영해준 것을 알고 있을 것이다. 그리고 디버깅을 쉽게 하기 위해 여러 오류 문구들을 출력해준다.

반대로 프로덕션 빌드 시, 이런 오류 문구들은 애플리케이션을 더 크고 무겁게 만들기 때문에 사용자들을 위해선 프로덕션 빌드를 해줄 필요가 있다. 또한 프로덕션 빌드 시에는 모든 파일을 한 번에 번들링 해야하는 작업을 거쳐야하기 때문에 다른 번들러와 비교했을 때 큰 성능의 이점이나 차이점을 기대할 수 없다.

다중 최적화를 보장하지 않는다

프로덕션용 빌드를 최적화 하기 위해선 런타임 최적화, 환경에 기반한 특정 최적화가 필요하다. 하지만 Vite JS 는 개발에 용이한 최적화만을 보장하고 있기 때문에 프로덕션 빌드 최적화를 위한 플러그인이나 다른 최적화는 지원하지 않는다.

출처


Vite 공식 문서

velog - (번역)이제는 웹팩과 작별할 때일까?

0개의 댓글