[웹 사이트 성능 향상시키기] gzip 을 적용해보자.

 Lighthouse 란 무엇인가
Lighthouse는 구글에서 개발한 오픈 소스 자동화 도구로, 웹 페이지의 품질을 개선하는 데 사용된다. 공개된 웹 페이지뿐만 아니라 

인증이 필요한 페이지에서도 사용할 수 있다.

 페이지 로딩 시간, 상호작용 시간, 시각적 안정성 등을 측정한다.
 웹 페이지가 다양한 사용자, 특히 장애를 가진 사용자들에게 접근 가능한지를 검사한다.
 웹 표준을 준수하고 있는지 확인한다.


chrome dev tool 에서는 개발자도구에 Lighthouse 탭을 사용하면 들어갈 수 있다.

 

이렇게 들어갈 수 있고 우리가 운영하는 사이트의 성능을 측정하면 다음과 같이 나온다.

 

오른쪽은 화면 미리보기인데 모자이크 한거다ㅎㅎ

측정 항목은 다음과 같다.

 

전엔 First Contentful Paint 가 중요했다고 하는데

요즘은 Largest Contentful Paint 가 중요하다고 한다.

왜냐하면 사용자들은 큰 이미지나 큰 컨텐츠가 다 로드가 되어야 

사이트가 로딩이 끝났다고 느낀다고 한다.

나도 그렇다.

 

아래로 스크롤하면 권고사항이 뜨는데 이런게 눈에 보인다.

 

 

여기서 집중한 것은 텍스트 압축이다! 

내가 알아본 것은 gzip 과 brotli이다. 

이는 텍스트 압축 알고리즘들인데 

요즘 사용하는 대부분의 브라우저는 이 알고리즘들을 지원한다고 한다.

 

gzip 은 무엇인가

 

gzip은 파일 압축 및 압축 해제에 사용되는 파일 형식이다.
파일 크기를 더 작게 만들어 더 빠른 네트워크 전송을 가능하게 하는 Deflate 알고리즘을 기반으로 한다. 
gzip은 일반적으로 웹 서버와 최신 브라우저(사실 gzip 인코딩 기능은 HTTP/1.1 명세에 포함되어 있으며 HTTP/1.1 을 지원하는 대부분의 현재의 브라우저는 gzip 으로 압축된 콘텐츠를 사용 가능하다.)에서 지원된다.  

서버는 파일을 보내기 전에 자동으로 gzip으로 압축할 수 있고, 브라우저는 파일을 받으면 압축을 풀 수 있다.

 

 gzip 알고리즘을 적용하면 얼마나 빨라질까?

 

우리가 운영하는 사이트에 적용해보았다.

 

높이 뛰었다. 측정 항목은 다음과 같다.

 

매우 빨라졌다.

압축률이 매우 좋은 것같다.

파일들은 전에는 아래와 같이 text/html 이 왔다면

 

이후에는

 

이와 같이 압축된 gzip 파일로 오는 것을 확인할 수 있다.

 

 

gzip 사용 시 주의할 점

압축 과정의 오버헤드:
Gzip은 서버에서 데이터를 압축하는 과정에서 CPU 자원을 사용한다. 압축 레벨이 높을수록 더 많은 CPU 자원을 소모하게 되어 페이지 로드가 더 느려질 수 있다. gzip_comp_level 값이 높을수록 압축은 더 효율적이지만, 그만큼 서버의 부담이 커져 시간이 더 걸릴 수 있다.

클라이언트 측 압축 해제:
압축된 데이터를 클라이언트(브라우저)에서 해제하는 과정이 추가로 필요하다. 압축률이 높거나 압축된 데이터가 크다면 클라이언트에서 이를 해제하는데 시간이 걸릴 수 있다.

짧은 전송 시간:
만약 초기 페이지 로드 시간이 매우 짧다면 (예: 19.29ms), 네트워크에서의 전송 시간이 차지하는 비중이 크지 않을 수 있다. 이 경우 Gzip의 압축으로 전송 크기를 줄여도 그로 인한 네트워크 전송 속도의 이점이 크지 않을 수 있으며, 압축 및 해제에 소요되는 시간이 더 크게 작용할 수 있다.

소규모 파일:
Gzip은 크기가 큰 파일을 전송할 때 특히 유리하다. 그러나 파일 크기가 매우 작은 경우(몇 kB 이하), 압축의 이점보다 압축 및 해제 오버헤드가 더 클 수 있다. 작은 파일에 대해 압축을 적용하면 전송 시간 절약보다는 오히려 성능 저하가 발생할 수 있다.

 

gzip 적용 방법

필자는 앞에 버츄얼 호스팅을 해주고 있는 nginx 서버를 쓰고있다.

그래서 nginx의 conf 설정을 주어서 간단하게 적용해보았다.

 

        ##
        # Gzip Settings
        ##

        gzip on;

        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 6;
        gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_types application/x-javascript text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss application/vnd.groove-tool-template text/javascript;

 

gzip_vary on;

HTTP 응답 헤더에 "Vary: Accept-Encoding" 를 추가한다.
프록시 서버가 압축된 버전과 압축되지 않은 버전을 적절히 캐시할 수 있게 한다.


gzip_proxied any;

프록시 요청에 대한 응답을 압축할지 결정하는 설정이다.
any는 모든 프록시 요청에 대해 압축을 수행한다는 의미다.


gzip_comp_level 6;

압축 레벨을 설정한다 (1-9 사이).
숫자가 높을수록 더 많이 압축되지만 CPU 사용량도 증가한다.


gzip_buffers 16 8k;

압축을 위한 버퍼의 수(16)와 크기(8k)를 설정한다.
16개의 8킬로바이트 버퍼를 사용한다는 의미다.


gzip_http_version 1.1;

HTTP 1.1 이상의 요청에 대해서만 압축을 수행한다.
HTTP 1.0은 압축과 관련된 일부 문제가 있을 수 있어 기본적으로 제외라고 한다.


gzip_types ...

압축할 MIME 타입을 지정한다.

application/x-javascript: 자바스크립트 파일
text/plain: 일반 텍스트 파일
text/css: CSS 스타일시트
application/json: JSON 데이터
application/javascript: 자바스크립트 파일
text/xml: XML 문서
application/xml: XML 데이터
application/xml+rss: RSS 피드
application/vnd.groove-tool-template: 특정 템플릿 파일
text/javascript: 자바스크립트 파일

 

더 나은 압축 방법에 대한 고민

이렇게 하면

캐싱되긴 하겠지만

그래도 nginx 서버가 매번 압축을 해야하니 부담이 될 수도 있다.

 

그래서 찾아본 더 좋은 방법은

빌드된 정적 파일을 gzip 으로 미리 압축을 해서

버킷에 올려두는 것이다.

이후에 gzip_static on; 을 넣어주면 이미 압축된 파일을 사용할 수 있다고 한다. 

 

 

다음 알아볼 것은 브로틀리이다!

 

s3 에서 웹사이트 호스팅 기능을 쓰면 br 이라는 

브로틀리로 압축된 파일이 온다.

이제 브로틀리를 사용한 후 파일의 압축률을 비교헤보겠다.