[WP] Gzip 압축 vs Brotli 압축: 2개 압축 알고리즘 차이점

워드프레스 CMS를 비롯한 웹 사이트를 빠르게 만들기 위해, 서버에서 데이터를 압축하는 설정을 하는 것이 유용합니다. 이렇게 하면 웹 서버와 브라우저 간에 전송되는 데이터를 더욱 빠르게 로딩할 수 있으며, 웹 사이트의 속도를 더 빠르게 만들어 줍니다. 이는 웹사이트를 운영하는 관리자들이 많이 고려하는 요소 중 하나입니다. gzip 압축은 많이 사용되고 있으며, 많은 웹 서버에서 gzip에서 점차 Brotli 압축으로 변경되고 늘어나는 추세입니다.

1️⃣ 압축이란?

사이트 URL에 접속하면, 브라우저와 서버 간에 대화가 시작됩니다. 이때 브라우저는 서버에게 콘텐츠의 압축(Compression)을 해제할 수 있는지와, 어떤 압축 알고리즘을 사용하는지에 대한 정보를 전달합니다. 이는 서버가 압축 된 데이터를 전송할 때, 브라우저가 이를 올바르게 해제할 수 있도록 돕는 역할을 합니다. 따라서 압축 알고리즘을 지원하는 서버와 브라우저를 사용하면, 웹 사이트의 로딩 속도를 더욱 빠르게 할 수 있습니다.

웹 브라우저는 서버에 접속하면 gzip 압축 or Brotli 압축과 같은 헤더를 보내게 됩니다. 둘 중 하나의 압축된 데이터가 브라우저에 출력되며 압축된 데이터는 압축되지 않은 데이터보다 빠르게 로딩됩니다.

Content-encoding: gzip
Content-encoding: br

압축되는 파일은 주로 텍스트입니다.
· HTML
· CSS
· JavaScript

2️⃣ Gzip 압축이란?

웹 호스팅 업체에서 많이 사용하는 일반적인 압축 알고리즘은 Gzip과 Brotli입니다. Gzip은 1992년에 베타 버전이 만들어 졌으며, 1993년에 1.0 버전이 릴리스 되었습니다. 보통 Gzip이란 인터넷에서 데이터를 전송할 때 압축을 하기 위한 표준 압축 방법 중 하나입니다. 이 방법은 초기 압축 알고리즘인 DEFLATE 압축을 기반으로 하며, 이전에 개발된 Unix의 파일 압축 프로그램인 gzip에서 이름을 따온 것입니다.

DEFLATE 압축은 LZ77(Lempel-Ziv 1977) 알고리즘과 Huffman 코딩 방식을 결합한 압축 방식입니다. LZ77은 중복되는 데이터를 검색하여 일치하는 문자열을 찾고, 그 문자열을 코드로 대체함으로써 압축을 수행합니다. Huffman 코딩 방식은 각 문자의 등장 빈도를 이용하여 가장 짧은 비트 코드를 할당하는 방식으로 압축을 수행합니다.

Gzip은 DEFLATE 압축 방식을 이용하여 데이터를 압축하고, HTTP 요청 및 응답에서 ‘Accept-Encoding: gzip’ 헤더를 사용하여 클라이언트가 Gzip 압축을 지원하는 경우에만 압축을 수행하도록 합니다. 이를 통해 데이터 압축을 실행하여 웹 사이트의 로딩 속도를 향상시킬 수 있습니다.

3️⃣ 브로틀리 압축이란?

브로틀리 압축은 2013년 Google 직원 Jyrki Alakuijala와 Zoltán Szabadka가 개발했습니다.

Gzip은 원래 파일을 압축하기 위한 것이었지만, 웹에서도 사용할 수 있도록 변경되었습니다. 반면, 브로틀리 압축은 웹에서 사용할 목적으로 개발되었습니다. 따라서, Brotli를 사용하면 웹 서버가 콘텐츠를 브라우저로 전송하기 전에 압축할 수 있습니다. 브라우저로 스트리밍 되기 전에 압축되기 때문에 더 나으며 발전된 방식입니다.

Brotli 압축은 다음과 같은 GZIP 압축과 동일한 LZ77과 Huffman 코딩 방식 두 가지의 핵심 기본 기술을 사용합니다.

4️⃣ Gzip 압축 Vs Brotli 압축

Gzip은 DEFLATE 방식을, Brotli는 LZ77과 허프만 코딩에 문맥 모델링을 더한 자체 형식을 사용하여 데이터를 압축(& 압축 해제)합니다.

• Gzip이 Brotli보다 압축 속도가 더 빠릅니다.
• Brotli는 웹 전용으로 설계되었습니다.
• Brotli는 모든 압축 수준에서 더 나은 압축률(즉, 더 작은 압축 파일 생성)을 제공합니다.
• Brotli는 Gzip보다 3가지 파일의 압축률이 각각 HTML 21%, CSS 17%, JavaScript 14% 더 좋습니다.

Gzip보다 Brotli를 선호하는 웹 서버가 점점 많아지고 있는 추세입니다. Brotli는 스트림을 즉시 압축하도록 설계되었기 때문에 Gzip에 비해 전체 프론트 엔드 압축 해제 속도가 최대 64% 더 빠른 것으로 알려져 있습니다.

1996년 5월에 나온 RFC 1952는 Gzip 형식이 DEFLATE 압축 방식을 사용하며, 데이터 손상을 확인하는 CRC 값을 포함한다고 설명합니다. 압축한 데이터 끝에는 원본 데이터의 CRC-32 값과 크기가 기록됩니다.

2016년 7월에 나온 RFC 7932는 Brotli가 LZ77 알고리즘과 허프만 코딩을 결합해 압축한다고 적고 있습니다. 여기에 압축 전 데이터의 앞 두 바이트를 문맥으로 사용해 허프만 코드를 선택하며, 반복 문자열 대신 122,784바이트 크기의 정적 사전에 있는 단어를 참조할 수도 있습니다.

두 형식은 응답 헤더에 [Content-Encoding: gzip]과 [Content-Encoding: br]로 표시됩니다. [br] 값은 RFC 7932에서 HTTP 콘텐츠 코딩으로 등록되었습니다.

5️⃣ Gzip 압축과 Brotli 압축 실측: Nginx + Apache 서버

Nginx와 Apache를 함께 사용하는 워드프레스 서버에서 같은 글 한 편과 워드프레스 기본 블록 CSS 파일, jQuery 파일의 응답을 요청 헤더만 바꿔 비교했습니다. [Accept-Encoding]에 gzip만 넣은 요청과 br만 넣은 요청, 헤더가 없는 요청을 같은 서버에서 curl로 전송했습니다.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

글 한 편의 HTML은 gzip 요청에 21,390바이트, br 요청에 20,190바이트로 압축되었고, 헤더가 없는 요청에는 압축하지 않은 90,833바이트로 응답했습니다. br 응답이 gzip보다 1,200바이트(5.6%) 작았습니다.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

CSS 파일은 gzip 요청에 19,655바이트, jQuery 파일은 30,633바이트로 압축되었습니다. br만 요청하거나 헤더가 없으면 [Content-Encoding] 헤더 없이 140,829바이트와 87,553바이트의 원본을 그대로 응답했습니다.

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

CSS와 JS 같은 정적 파일은 Nginx가 직접 응답하고 압축하며, 이 구성의 Nginx에는 Brotli 모듈이 없어 gzip으로만 압축합니다.

HTML은 Nginx가 Apache로 전달한 요청에 워드프레스가 응답하고 Apache가 압축합니다. Apache에는 Brotli 모듈과 Gzip 압축을 담당하는 [mod_deflate] 모듈이 모두 있습니다.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

서버에 Brotli 모듈이 있다고 브라우저가 Brotli로 압축된 응답을 받는 것은 아닙니다. 엣지 155가 보내는 값과 같은 [gzip, deflate, br, zstd]로 요청하자 Apache도 HTML을 gzip으로 압축해, 세 파일 모두 gzip으로 응답했습니다.

br을 gzip보다 앞에 두거나 [br;q=1.0, gzip;q=0.5]처럼 br을 우선한다고 표시해도 HTML은 gzip으로 응답했습니다. 엣지로 같은 글과 두 파일을 열었을 때도 모두 gzip으로 전송되었습니다.

첫 바이트 시간은 요청 순서를 섞어 40번씩 잰 curl [time_starttransfer] 값의 중앙값이며, 요청마다 새로 연결해 TLS 연결 시간도 포함됩니다. HTML은 압축하지 않은 응답이 22.7ms, gzip 26.3ms, br 26.5ms, 브라우저와 같은 요청이 25.0ms였습니다. CSS와 JS는 압축 여부와 상관없이 18~21ms였습니다.

Gzip과 Brotli의 압축 속도는 직접 측정하지 않고 공개 자료로 비교했습니다. RFC 7932는 Brotli가 gzip 프로그램보다 상당히 높은 압축률로 압축하고, 현재 LZMA 구현보다 훨씬 빠르게 압축을 해제한다고 적고 있습니다. 구글은 Brotli 저장소에서 Brotli가 deflate와 속도가 비슷하면서 더 촘촘하게 압축한다고 설명합니다.

2015년 클라우드플레어는 HTML과 CSS, JavaScript 파일 10,655개로 두 방식을 시험했습니다. Brotli 최고 품질의 결과는 zlib 최고 품질보다 평균 1.19배 작았지만, 압축 속도는 초당 0.5MB로 zlib 9단계의 41.9MB보다 크게 느렸습니다. Brotli 4단계는 zlib 8단계와 압축률이 비슷했으며, 전체 평균으로는 조금 빨랐지만 64KB보다 작은 파일만 보면 1.48배 느렸습니다.

HTML, CSS, JavaScript와 같은 파일 압축으로 웹 사이트 최적화 과정에 대해 알아 봤습니다. 웹 사이트의 속도 개선을 위해 파일 압축과 이미지 최적화는 필수 요소 중 하나라고 할 수 있습니다.

🔢 FAQ & 추천 콘텐츠

ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액^{(이벤트 할인 시 금액이 내려갑니다↓)}은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.