🌍 HTTP/2와 Webpack

DoonDoon·2018년 10월 21일

TL;DR
이미 웹팩은 HTTP/2 와 관계 없이도 많은 역할을 수행하고 있으며
HTTP/2 에서 웹팩의 번들링 전략에 따라, 성능 향상을 도모할 수 있습니다!

Overview

Webpack 설정파일을 열심히 작성하다 문득 HTTP/2 는 멀티 리소스 로딩도 빠르다는데
(2018년 10월 기준 약 30% 가량의 웹 사이트는 HTTP/2 를 지원하고 있습니다)
'이 어렵고 귀찮은 Webpack 설정을 안해도 괜찮지 않을까?' 라는 생각이 문득 들어서 정리한 내용입니다!

HTTP/1 & Webpack

Webpack을 사용하는 이유는 아래와 같이 설명할 수 있습니다

Multiple Resources에 대한 HTTP Request Overhead를 줄일 수 있도록
Single Resource로 만들어 Request Overhead를 줄이고, 성능 개선을 도모하자.

HTTP/1 에서 사용자가 웹 페이지에 접근할 경우 아래와 같은 리소스가 필요하다고 가정할게요

HTML * 1
Stylesheet * 2
PNG * 10
Script * 4

위 상황에서는 최초 HTML 파일을 가져온 뒤에, 나머지 16개(HTML 제외)의 resources만큼의 TCP 연결이 생깁니다
(HTTP KEEP-ALIVE TCP연결은 max 한도 내에서 끊기지 않고 계속 생성되기 때문에 다를 수 있음)

KEEP-ALIVE와 이를 활용한 병렬 연결을 하더라도,
리소스 요청에 대해 Connection이 여러번 발생하는 것은 막을 수 없습니다
(그리고, 당연하게도, 이 부분에서 Request Overhead가 발생합니다)

그리고, 작은 (또는 클 수도 있는) 여럿의 리소스를 하나로 모아,
한 개의(또는 최소한의) Resource만 Serving 하기 위해 만들어 진 것이 Webpack!

Webpack의 장점은, 하나의 파일로 bundling하여 http connection을 최소화 한다는 점이지만,
하나의 작은 파일 변경에도 (bundle.js에 포함된 하나의 css파일이 변경되었다 하더라도)
전체를 다시 bundling 하기 때문에, bundle.js라는 큰 파일에 대한 캐싱이 어렵습니다.

http connection과 캐싱의 trade-off에서, connection 최소화에 더 많은 성능 개선이 있기때문에
HTTP/1 에서 webpack을 통한 bundling을 하는 이유라고 할 수 있겠습니다

그럼 HTTP/2 환경에서는 어떨까요?

HTTP/2 는 Multiplexed Streams 를 사용하여, 하나의 TCP Connection으로 여러 요청을 주고 받을 수 있습니다
한 번의 요청에 여러 종류의 resource 요청에 대한 stream frame을 생성하여 주고 받는 형식이므로,
Multiple resources가 필요한 환경에서도 RTT(Round trip time)가 자연히 줄어들게 됩니다

음 그럼 더 이상 웹팩이 필요없어지는 걸까요?

HTTP/2 와 웹팩

HTTP/2의 핵심 목표

HTTP/2의 주요 목표는 지연 시간을 줄이는 것이며 이를 위해 전체 요청 및 응답 다중화를 지원하고, HTTP 헤더 필드의 효율적 압축을 통해 프로토콜 오버헤드를 최소화하고, 요청 우선순위 지정 및 서버 푸시를 지원합니다. 이러한 요구사항을 구현하기 위해 다양한 프로토콜 개선사항(예: 새로운 흐름 제어, 오류 처리 및 업그레이드 메커니즘)이 지원되지만, 무엇보다 모든 웹 개발자들이 이해하고 애플리케이션에 활용해야 하는 가장 중요한 것들은 바로 이러한 기능들입니다.
출처: developers.google.com Web Fundamentals HTTP/2 소개

요청 및 응답 다중화가 된다면, 하나의 파일로 번들링을 도와주는 Webpack은
(물론 Webpack 은 그 외에도, code splitting, Tree shaking 등 다양한 역할을 수행합니다)
HTTP/2 세상이 도래하는 순간 Webpack은 필요 없어지는게 아닐까요?

결론적으로는, HTTP/2 에서도 bundle된 하나의 리소스를 요청하는 것이 성능 향상에 도움이 됩니다

좀 더 명확히 하자면, HTTP/1 시절과 같이 하나의 큰 bundle파일로 처리하기 보다는
Grouping된 여럿의 작은 bundles가 더 효과적일 것 입니다. (Benchmark 테스트에 근거)

더불어 Grouping된 여럿의 작은 bundle 파일들은 캐싱에도 더욱 효과적입니다.
(작은 하나가 변경된다고 큰 하나를 불러올 필요가 없기 때문입니다)

예상과 달리, Multiplexed Stream의 제한도 있기 때문에 (Nginx 설정도 있다!)
"HTTP/2 에서는 다중 요청이 가능하니까, bundle이 필요없겠다 "
라고 단순하게 생각했던 것과는 결과가 달라 의외였습니다

그리고 Webpack에서는 HTTP/2 환경에 대응할 수 있도록 내장 플러그인을 제공하고 있는데요
webpack.optimize.AggressiveSplittingPlugin 을 사용하면,
기존과 달리, 여러개의 작은 chunk가 생성되어, caching이 개선된다고 가이드하고 있습니다