...그리하여 Webpack의 가장 큰 사용목적인 모듈 패키징이 무엇인지 알기 위해, HTTP1.1에 대해서, 또 동시에 HTTP2에 대해서 알게되었습니다.
더 깊게 웹팩을 파기 전에, 저는 지금즘 한가지 생각이 들었는데
결론적으로 웹팩과 HTTP2를 병행하게된다면, 더 높은 성능향상을 꽤할 수 있다 입니다.
어찌보면 당연한 말입니다.
특정 페이지를 로딩할때 필요한 리소스들이 아래와 같다고 한다면
default.css
default.js
favicon.co
title.png
Http2를 이용한 서버에서 클라이언트가 처음으로 index.html을 요청하며 connection을 만들면,
서버는 5개의 스트림을 만들어 전송을 하게 됩니다.
하지만 웹팩을 통해 번들링을(예를들어) 통해 단 하나의 번들로 묶는다면,
스트림은 단 한번만 전송하면 되기 때문입니다.
또 이렇다고 마냥 모든 파일들을 번들링하기엔 석연찮은 구석도 있습니다.
번들링을 하게된다는것은 여러 파일들을 합쳐서 제공한다는 말입니다.
그렇다면 모든 js파일들을 번들링하는것은 옳은걸까요? 분명 connection/stream은 단 한번이니 좋을것 입니다. 하지만 다른쪽 성능을 생각해 본다면 어떨까요?
모던 js를 이용해 모듈화를 한 경우의 윂페이지라면, 페이지나 작업마다 사용하는 js파일들이 다를것 입니다. 이런 경우라면 모든 js파일들을 다운로드받고 싶지 않을것 입니다. 모듈화 한 이유가 없으니깐요.
모든 js파일들을 번들링 하게된다면, 모든 페이지마다 하나의 큰 파일을 받아야 할것입니다. 설상 그 js파일들이 쓸모없을지라도 말이죠.
그럼 특정 js파일들만 번들링을 하고, 필요에따라 제공하는것은 어떨까 하는 생각이 들것입니다. 번들링 된 파일로 stream 횟수는 적당히 줄어들며,불필요한 js를 로드하느라 성능 낭비를 할 필요도 없을거구요.
하지만 이 하이브리드 구조와, 번들링을 하지 않은 js파일들의 벤치마크를 했을때 결과는 놀랍게도 의도와 많이 달랐다고 주장합니다.
위의 글에 따르자면, 번들러를 사용할떄 쓰는 압축 기술은 대용량 파일의 압축에 더 유리하기 때문에, js 모듈따위의 작은 용량의 파일은 압축 비용이 원본비용보다 높은 문제를 지적합니다.
이러한 데이터들과 벤치마크를 통해 지금까지 중론처럼 나온 결론은
번들링은 HTTP1.1 과 HTTP2 를 막론하고 성능향상을 유도할 수 있으나,
과도한 번들링은 서버의 캐싱문제로 다른 퍼포먼스 이슈를 초래할 수 있습니다.
결과적으로 상황과 기능 등에 맞게 세분화 한 번들링 / 하지만 너무나도 세세한 경우라면 stream이 증가할 것이므로 너무 세세하지는 않게 적당한 번들링을 사용해야 한다는 것 입니다.
이제 기본적인 웹팩의 용도를 넘어 좀더 향상된 사용방법을 간단하게 훑어보았으며, 이제는 실제로 코드를 짜 봐야 할 시간인거 같군요.
댓글 없음:
댓글 쓰기