빌드타임, 런타임 코드 스플리팅

https://medium.com/hackernoon/the-100-correct-way-to-split-your-chunks-with-webpack-f8a9df5b7758

 

요약

번들 스플리팅

사람들은 코드 스플리팅이라고하면 런타임 코드 스플리팅만이 중요하다고 오해한다. 하지만 사실 더 중요한것은 빌드타임에 스플리팅하는것이다.(번들 스플리팅) 코드를 여러개의 번들로 잘 나누면 브라우저 캐시를 좀 더 잘 활용할 수 있게 된다.

 

하나의 큰 파일을 클라이언트로 내려주면 그 파일의 아주 일부분이라도 수정될 경우 브라우저 캐시를 활용하지 못하고 새로 파일을 서버에서 받아와야한다. 따라서, 최대한 작은 파일로 쪼개서 내려주어야 한다. 그렇게 되면 수정된 파일만 캐시 버스트 하면 되므로 훨씬 효율적으로 브라우저 캐시를 활용할 수 있다.

 

물론 코드를 쪼갤수록 웹팩의 보일러플레이트가 들어가서 총량은 더 많아질 수 있으며 페이지에 처음 진입한 유저는 여러번의 HTTP요청을 보내야 하기 때문에 로드 시간이 더 오래 걸릴수 있겠지만 대부분의 경우 파일 하나를 내려줄때와 큰 차이는 없으며, 오히려 다음에 재방문했을때 캐시된 많은 스플리팅된 코드 덕분에 훨씬 빠른 속도로 페이지를 로드 할 수 있다.

코드 스플리팅

위 저자는 20/20 룰이라는 본인만의 철칙을 만들었다. 대략 20% 정도의 유저가 사용하면서 전체 코드의 20%이상의 비중을 차지하는 부분을 코드 스플리팅 한다는 룰이다. 웹팩의 dynamic import를 사용하지 않으면 사람들이 자주 방문하지 않는 페이지의 코드들도 초기 번들에 들어가게 된다. 대부분의 사람은 그 페이지에 진입할 일이 별로 없으므로 이런 코드들은 코드 스플리팅 해주는게 좋다. 

 

위 20/20룰 이외에도 해당 코드가 얼마나 다른 코드와 독립적인지가 코드 스플리팅 대상 선정에 중요한 역할을 한다. 리액트 앱인경우 스토어, 리듀서, 라우팅, 액션과 같은 코드들은 전 페이지에서 사용되어야 하기 떄문에 스플리팅 하기 힘들다. 독립적인 컴포넌트 위주로 스플리팅 해야 한다.

 

저자는, 307KB의 번들 스플리팅된 코드를 한번더 코드 스플리팅 하고자 할때 유니크한 부분이 고작 7KB였다고 말하면서 코드 스플리팅이 크게 중요하지 않다고 얘기한다. 오히려 코드 스플리팅을 하게 되면서 모듈을 비동기로 불러와야 하고 그런 모듈이 많아지면 코드가 복잡해진다고 얘기한다. 얻는것에 비해 잃는게 크다는 뉘앙스로 얘기한다.

 

하지만 polyfill과 같이 90%이상의 브라우저에서는 필요하지 않은 코드들은 스플리팅 해주는게 좋다고 얘기한다. 이런 polyfill을 dynamic import하지 않으면 초기 번들에 포함되지만 대부분의 사람들은 polyfill이 필요하지않은 코드를 쓸데없이 받게 되는것이다.

 

따라서, 소수의 사용자에게 사용되며 적절히 사이즈가 큰 코드를 위주로 코드 스플리팅해야한다.