1.    서론
 
HTTP Compression 은 웹사이트의 응답 성능을 향상 시키는데 많은 일조를 합니다. 압축 정도와 데이터의 타입에 따라 압축율은 다르지만, 최소 30% 이상의 체감 속도의 향상을 가져온다고 합니다. 제가 운영하고 있는 [Umc Projects/Umc Blog] - [UmcBlog] 블로그 소스 다운로드 의 메인화면의 HTML 만해도 101,430 Bytes 지만, GZip 압축을 적용한 결과 15,450 Bytes 로 7배 정도로 작아진 트래픽이 발생합니다.
 

[그림1] Umc Blog 메인 화면을 HTTP 압축한 비교표
 
위 압축은 ShartZipLib 를 이용하여 최고 압축율로 압축한 결과 입니다.
자~ 어떻습니까? 이제 HTTP 압축을 자신의 사이트에 도입해 보려고 한다면, 우선 다음의 강좌를 참고하여 선수 지식을 익히시기 바랍니다.
 
최고의 가이드 문서인 유경상님의 HTTP 압축 (1) : 성능 향상을 위한 다른 접근 기법
서동진님의 [1000원짜리] GZip 이용한 웹 페이지의 압축 전달
 
제가 아는 포스팅은 이것 뿐인지, 아니면 제가 못 찾는 것인지 모르겠지만, 어쨌든 왜 써야 하며, 어떻게 구현하는지는 보셔야 다음 내용을 이해할 수 있습니다.
 
 
2.    문제 제기
 
위 내용 중 특히 유경상님의 문서에서 볼 수 있듯이 HTML 과 XML Web Service 에서 압축방법과 압축해제 방법을 너무나 잘 설명해 주셨습니다. (쵝오!) .NET Framework 가 버전업이 되면서 편리한 API 와 옵션들이 추가되어 깊은 이해보다 코드 한 줄로 해결할 수 있는 방법들이 너무나 다양해 졌습니다.
 
좋습니다. 어찌되어건, HTTP Compression 은 서버의 CPU 가 가져가는 부하가 경미하기 때문에 보다 훨씬 많은 이점이 있습니다. 그렇기 때문에, 웹 사이트는 특별한 상황이 아니라면 HTTP Compression 을 활용하도록 해야 합니다.
 
IIS HTTP Compression 을 사용하지 말아야 할 때
IIS 서비스 압축은 기본적으로 DLL 도 GZip 압축 하도록 되어있습니다. 스마트클라이언트 시나리오에서는 클라이언트가 GZip 압축된 어셈블리(*.dll) 등을 다운로드 하였을 때 다운로드 된 클라이언트는 GZip 압축을 복호화 하지 못합니다. 유경상님의 HTTP Compression (III) : IIS Support 을 참고 하세요.
 
자.. 문제는 여기서 부터입니다. HTTP Compression 의 구현은 쉽지만, HTML(CSS/JS) 이나 XML Web Service 에 국한된 포스팅 입니다. 특히, 클라이언트 어플케이션일 경우 의 GZip 압축의 범위가 XML Web Service 에 국한됩니다. 하지만, 불특정 다수의 웹 서비스 사이트를 생각한다면 HTML Compression 만으로 부족한 것을 알 수 있습니다.
 

[그림2] HTML 뿐만 아니라 다양한 데이터를 클라이언트는 내려받습니다 (클릭하면 확대 됩니다)
 
우리가 웹 사이트를 접속하였을 때, 보여지는 것은 HTML/CSS/JS 만 있는 것이 아닙니다. 수십 개의 콘텐츠 중 고작, 10여개의 텍스트 용량을 줄였다고 체감속도가 향상 되었다는 것은 억지에 불과합니다.(그나마 안하는 것보다는 나은듯^^;) 왜냐하면, 웹 사이트를 접속할 때 XML, BMP 등과 같은 압축되지 않은 다양한 콘텐츠도 다운로드 되기 때문 입니다.
 
물론, HTTP Compression 을 하느냐 안하느냐도 중요합니다. 하지만 압축이 전부는 아닙니다. 자신이 개발하거나 관리하는 사이트가 이런 문제로 고민을 한다면 다양한 웹 사이트 최적화 기법을 통해서 빠른 응답을 기대할 수 있습니다.
 
웹 사이트 최적화 튜닝 방법
 
ASP.NET 개발 환경을 무척 편리해 졌습니다. .NET Framework 2.0 부터 추가된 WebResource 와 ScriptResource 를 이용하여 컴포넌트 배포시에 별도의 스크립트 파일이 없이도 동작하도록 어셈블리의 리소스에 포함시킬 수 있게 되었습니다. 무척 배포가 쉬워졌지요.
 
하지만, ASP.NET 웹사이트로 구축된 기업의 인트라넷의 경우 다양한 컴포넌트를 사용하여 개발하게 될 때, 수십여 개의 WebResource 와 ScriptResource 를 뱉어내게 됩니다. 이 리소스들은 압축되었다는 보장을 할 수 없고, 실제로 압축되지 않은 리소스들이 더 많습니다. 이런 웹 사이트의 성능 저하 주 원인이 바로 리소스입니다.
 
문제는 여기에서 생깁니다. 어떻게 이 리소스들을 압축하시겠습니까?
AJAX.NET 의 ScriptManager 컨트롤은 3개의 ScriptResource 를 포함합니다. ScriptResource 는 아무런 작업을 하지 않아도 gzip 압축이 되는데, 특정 컴포넌트의 ScriptResource 는 gzip 압축을 하지 않습니다.
 

[그림3] 아무 작업 없이도 ScriptResource 는 압축이 되기도 합니다.
 
특히 ScriptResource 의 경우는 아무런 생각 없이 압축을 수행하다가는 이미 압축된 리소스가 추가적으로 GZip 압축이 되어, 브라우져는 중복 압축된 콘텐츠를 제대로 복호화 하지 못합니다. 결국 사이트는 바보가 됩니다.
 
Next… (다음 아티클)
저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 땡초 POWERUMC

댓글을 달아 주세요