HTTP/1과 HTTP/2의 비교 그리고 CSS 스프라이트(Sprite) 기법의 유효성

 

맨 처음 프론트엔드 공부를 시작할 때는 스프라이트 기법을 경험해보지 못했다가, 학원에서 웹 프로그래밍 미니 프로젝트를 진행할 때 처음 접하고 굉장히 신기했었다. background-image, background-position 프로퍼티를 매번 이용하며, 상당히 귀찮은 방법이라고 생각했는데, 나름 HTTP/1 프로토콜에서 리소스 요청을 덜 하기 위한 나름의 노력으로 탄생한 기법이었던 것이다.

 

우선 이 세 가지의 관계도를 보기 위해서는 HTTP/2와 HTTP/1의 차이점을 알아야 한다. HTTP는 웹 서비스에서 클라이언트와 웹 서버 간에 정보를 주고 받기 위해 사용되는 네트워크 프로토콜로, 여기에서도 새로운 기술이 기존의 기술을 보완하는 방향으로 발전하고 도입되는 것은 마찬가지다. HTTP/2 역시 HTTP/1의 한계를 극복하기 위해서 도입되었다.

 

HTTP/1

• 이미 나온 지 30년이 넘은 프로토콜. 심지어 웹 애플리케이션을 위한 프로토콜이라기보다는 최초에는 문서만을 읽기 위한 프로토콜로 설계가 되었다. 당연히 현재 우리가 쓰는 웹 앱을 제대로 지원해주지 못한다.
• HTTP/1에서는 프로토콜 차원에서 응답 다중화를 지원하지 않았다. 이 말은 즉, 응답을 병렬로 하나씩 처리해야 했고 브라우저가 커버하는 영역이었다는 의미이다. 당연히 브라우저별로 요청을 병렬처리할 때 가능한 갯수가 달랐다. (예, Opera, Firefox, Chrome 출처 별로 6개씩, Internet Explorer 출처별로 10~11개)
• 그러다보니 애플리케이션이 초기화될 때마다 리소스 요청 관리에 신경을 써야 했다. 최대한 리소스 요청 갯수를 줄이거나 리소스 자체의 용량을 줄이려는 노력이 있었다.
  • index.js나 style.css에 하나의 번들로 나머지 JavaScript 파일이나 CSS 파일을 담는 방식
  • 혹은 Minify, Uglify 같은 기법으로 용량을 줄이기
  • 그리고 흩어진 개별적인 이미지를 하나의 커다란 이미지 파일로 만들어 위치값을 조절해 마스킹하기. 이게 바로 스프라이트 방식이다.

스프라이트

다음 메인 페이지에서 개발자 도구를 열어 네트워크 -> Img의 여러 리소스 중 하나를 클릭해서 확인해보았다.

다음 같은 대규모 웹 컨텐츠를 제공해야 한다면 스프라이트 기법은 무척 유용할 것이다. 처음 애플리케이션을 초기화할 때 다운 받아야 하는 리소스의 양(HTTP 요청 횟수)을 줄일 수 있기 때문이다. 네트워크의 트래픽은 유저에게도, 서비스 제공자에게도 부담으로 작용할 수밖에 없다.

이런 스프라이트 기법은 게임 개발의 2D 그래픽 프로세스에서도 전통적으로 많이 사용해온 방식이라고 한다.

 

HTTP/2는 출처별로 최대 128개의 병렬 요청을 처리할 수 있다. 파일을 번들링하지 않아도, 스프라이트 기법을 쓰지 않아도 많은 양의 리소스를 동시에 요청하고 처리할 수 있는 것이다. 그런데, HTTP/2가 HTTP/1의 성능을 개선했다고 해도, HTTP/2 환경에서 스프라이트 기법을 쓰는 게 여전히 유효할까 궁금증이 남는다.

 

참고

CSS를 이용한 스프라이트(Sprite) 기법