Gzip 대 Brotli – 어떤 압축 방법을 사용해야 하며 그 이유

게시 됨: 2018-03-02

Gzip은 1990년대 초에 파일 압축의 표준이 되었지만 2018년에도 여전히 사용하고 있다면 새로운 압축 방법으로 전환하는 것을 고려할 수 있습니다.

Gzip은 여전히 ​​많은 사람들의 마음에 자리 잡고 있지만 웹 개발자는 점점 더 Google의 Brotli 압축 알고리즘과 같은 우수한 옵션으로 눈을 돌리고 있습니다.

파일 압축의 간략한 역사

Gzip의 "G"는 GNU의 약자입니다. GNU는 1980년대에 개발된 오픈 소스 Unix 기반 운영 체제입니다. 그 당시 Unisys와 IBM은 이미 파일 압축 및 압축 해제를 위한 자체 알고리즘에 대한 특허를 취득하여 더 많은 데이터를 저장할 수 있었습니다. 따라서 프로그래머 Jean-loup Gailly와 Mark Adler는 GNU 사용자를 위한 무료 대안으로 Gzip을 만들었습니다.

새로운 Gzip은 단순히 싸구려 제품이 아닙니다. 저작권이 있는 경쟁업체보다 실제로 더 빨랐습니다. 결과적으로 사람들은 오늘날까지 여전히 파일 압축에 사용합니다. 익숙한 것을 고수하는 것은 쉽지만 현재 Gzip보다 더 나은 압축 결과를 제공하는 다양한 압축 알고리즘이 있습니다. 바로 여기에서 Brotli가 등장합니다.

브로틀리란?

Brotli는 여러 알고리즘을 활용하여 Gzip보다 더 효율적으로 데이터를 압축하는 최신 데이터 형식 사양입니다. 2015년에 Brotli 사양은 콘텐츠 인코딩 유형 'br'로 HTTP 스트림 압축을 위해 일반화되었습니다.

Brotli Content Encoding

Jyrki Alakuijala와 Zoltan Szabadka가 개발한 Brotli는 Gzip과 동일한 압축 알고리즘을 사용하지만 더 나은 압축 비율을 제공하기 위해 자주 사용하는 단어 및 구문 사전도 지원합니다.

Gzip 및 Brotli는 텍스트 파일을 압축하는 데만 사용해야 합니다. JPEG 및 MP4와 같은 이진 파일은 자체 형식별 압축 알고리즘에 의존합니다. Brotli로 JPEG를 압축하려고 하면 결과 파일이 실제로 원본보다 커집니다.

항상 그런 것은 아니지만 Brotli는 이제 모든 주요 브라우저에서 지원됩니다.

Brotli Support

Brotli를 지원하지 않는 브라우저가 Brotli 압축 파일을 제공하는 사이트에서 자산을 요청하는 경우 서버는 Gzip으로 대체하고 브라우저가 지원하는 인코딩된 자산을 전달합니다.

무엇이 Brotli를 더 좋게 만드는가?

CertSimple에서 수행한 연구에 따르면:

  • Brotli로 압축된 JavaScript 번들은 Gzip으로 압축된 Javascript 번들보다 14% 작 습니다.
  • Broti에서 압축한 HTML 파일은 동등한 Gzip 파일보다 21% 작 습니다.
  • Brotli로 압축된 CSS 파일은 Gzip으로 압축된 것보다 17% 작 습니다.

대부분의 웹 사이트는 이러한 세 가지 유형의 자산에 모두 의존하기 때문에 Gzip과 비교할 때 자산 크기에서 상당한 차이가 있습니다. 이러한 절감은 차례로 앱 성능을 눈에 띄게 향상시킵니다.

Gzip 대 Brotli: Brotli 최대한 활용하기

Brotli로 자산을 압축하는 것이 Gzip보다 느리지 않다는 것을 들어보셨을 수도 있습니다. 즉, Gzip 및 Brotli는 다양한 수준의 압축을 제공하며 Brotli의 기본 설정은 Gzip의 기본 설정보다 압축 속도가 느려질 수 있습니다. 파일 크기와 압축 속도 사이에서 적절한 균형을 유지하려면 Brotli를 약간 조정해야 합니다.

이상적인 압축 설정은 압축 대상과 시기에 따라 다릅니다. 좋은 출발점은 동적 콘텐츠의 더 빠른 압축을 위한 Brotli 4입니다. 반면에 정적 자산은 속도 저하 없이 미리 더 조밀하게 압축할 수 있으므로 이러한 콘텐츠에는 기본 설정인 "11"이 더 적합합니다.

웹 서버에 Brotli 설치

Brotli에 대한 지원을 추가하면 최소한의 노력으로 상당한 이점을 얻을 수 있습니다. 사용 중인 웹 서버 소프트웨어에 따라 Brotli를 통합하는 데 사용해야 하는 통합 방법이 결정됩니다. 다음은 사용 가능한 몇 가지 옵션에 대한 개요입니다.

  • Nginx 에는 Google에서 제공하는 Brotli 확장이 있습니다.
  • Apache는 전용 Brotli 확장을 제공합니다.
  • Microsoft IIS 는 공식적인 Brotli 지원을 제공하지 않지만 지원을 추가하는 커뮤니티 모듈이 있습니다.
  • Node.js 는 공식 지원이 없지만 커뮤니티 모듈이 있다는 점에서 Microsoft와 유사합니다.

빠른 설치 예를 보여주기 위해 Nginx를 실행 중이라고 가정해 보겠습니다. 이 경우 다음을 사용하여 ngx_brotli 모듈을 설치할 수 있습니다.

cd nginx-1.x.x
$ ./configure --add-module=/path/to/ngx_brotli
$ make && make install

그런 다음 HTTPS 블록에 다음을 추가합니다(Brotli는 HTTPS를 통해서만 실행됨).

brotli on;
brotli_static on;
brotli_comp_level 4;
brotli_types text/plain text/css application/javascript application/json image/svg+xml application/xml+rss;

위의 지시문을 적절하게 수정할 수 있습니다.

마지막으로 다음을 입력하여 NGINX를 다시 시작하고 이점을 누리십시오.

sudo systemctl restart nginx
사전 압축된 자산과 함께 Brotli 사용

Brotli는 Gzip보다 훨씬 빠르게 사전 압축된 자산을 제공하는 데 적합합니다. 이것은 Brotli의 최고 수준(11)에서 압축한 다음 요청될 때마다 원본 서버에서 선택하도록 할 수 있기 때문입니다.

이러한 종류의 설정은 Webpack 플러그인을 사용하여 정적 자산을 Gzip 및 Brotli로 자동 압축할 수 있으므로 Webpack과 잘 작동합니다. 따라서 즉석 압축이 필요하지 않으므로 그렇지 않으면 파일을 압축하는 데 소요되는 시간이 절약됩니다.

Webpack을 사용하여 Brotli 압축 자산을 생성하는 방법에 대해 자세히 알아보십시오.

CDN이 Brotli를 지원합니까?

Brotli의 이점을 최대한 활용하려면 이를 지원하는 콘텐츠 전송 네트워크가 필요합니다. 예를 들어 KeyCDN은 작년에 추가 비용 없이 모든 고객에게 Brotli 지원을 도입했습니다. 따라서 Brotli 압축이 향상되어 사이트의 파일 크기가 줄어들 뿐만 아니라 방문자에게 더 가까운 에지 서버에 자산이 캐시되어 대기 시간이 단축되는 이점도 있습니다.

이 방법을 사용하려면 원본 서버가 Brotli를 지원하고 실제 압축이 원본 서버 측에서 발생해야 합니다. 다시 말하지만, 이는 시간을 절약하고 성능을 저하시킬 수 있는 즉석 압축의 필요성을 방지하는 데 도움이 됩니다.

Gzip 대 Brotli: 요약

웹 서버에 Brotli를 추가하는 데 필요한 약간의 노력은 상당한 파일 크기 절감의 가치가 있습니다. Brotli는 때때로 최고 압축 설정에서 느리게 실행될 수 있지만 설정을 조정하여 압축 속도와 파일 크기 사이의 이상적인 균형을 쉽게 얻을 수 있습니다.

Brotli를 사용하면 빠른 웹 앱을 더 빠른 앱으로 바꿀 수 있지만 느린 앱을 반드시 빠르게 만드는 것은 아닙니다. Brotli는 텍스트 기반 자산만 압축하므로 다른 방법으로 이미지를 최적화해야 합니다. 아직 HTTP/2로 전환하지 않았다면 그렇게 하면 앱 성능에 큰 차이를 만들 수 있습니다. 모든 밀리초가 중요하므로 애플리케이션 속도를 높이기 위해 취하는 모든 조치는 사용자를 유지할 가능성을 높입니다.