gzip과 HTTP/3는 무엇이며, 웹페이지 로딩 성능은 무엇부터 개선해야 할까요?

gzip은 웹페이지의 텍스트 파일을 작게 압축해 전송해야 할 데이터량을 줄이는 방식이고, HTTP/3는 QUIC 위에서 HTTP를 전달해 여러 요청을 처리하고 패킷 손실에 대응하는 방식을 바꾸는 프로토콜입니다. 둘 다 페이지 로딩에 도움이 될 수 있지만, 같은 문제를 푸는 기술은 아닙니다. 따라서 “gzip과 HTTP/3 중 무엇이 더 빠른가”보다 “현재 페이지의 병목이 전송 바이트, 네트워크 손실, 서버 응답, 이미지, 렌더링, JavaScript 중 어디에 있는가”를 먼저 묻는 편이 정확합니다.www.rfc-editor.org↗datatracker.ietf.org↗

실무에서 가장 흔한 오해는 HTTP/3를 켜면 웹사이트 전체가 자동으로 빨라진다고 생각하는 것입니다. HTTP/3는 중요한 기반 개선이 될 수 있으나, 지나치게 큰 첫 화면 이미지나 렌더링을 멈추는 CSS·JavaScript, 느린 서버 응답을 대신 해결하지는 않습니다. 반대로 텍스트 응답이 아예 압축되지 않은 사이트라면 gzip 또는 Brotli 활성화는 비교적 작은 설정 변경으로도 전송량을 눈에 띄게 줄일 수 있습니다.web.dev↗developer.mozilla.org↗

gzip은 정확히 무엇인가요?

gzip은 HTTP에서 사용하는 대표적인 콘텐츠 인코딩(Content-Encoding) 입니다. 서버는 원본 HTML, CSS, JavaScript, JSON, SVG 등의 내용을 gzip 형식으로 압축해 보내고, 브라우저는 받은 뒤 압축을 풀어 원래 콘텐츠를 사용합니다. HTTP 의미 규격은 gzip을 LZ77 계열 압축과 32비트 CRC를 사용하는 콘텐츠 코딩으로 정의합니다.www.rfc-editor.org↗www.rfc-editor.org↗

핵심은 파일의 논리적 종류가 바뀌지 않는다는 점입니다. 예를 들어 서버가 app.js를 gzip으로 전송해도 브라우저가 실행하는 것은 결국 같은 JavaScript입니다. 달라지는 것은 네트워크를 지나는 동안의 바이트 수입니다. 파일이 작아지면 제한된 대역폭에서 내려받는 시간이 줄고, 사용자의 모바일 데이터 사용량도 감소할 수 있습니다.www.rfc-editor.org↗developer.chrome.com↗

브라우저와 서버는 어떻게 압축 방식을 정하나요?

브라우저는 요청 헤더의 Accept-Encoding으로 자신이 해석할 수 있는 압축 형식을 알립니다. 서버는 그 목록과 우선순위를 바탕으로 적절한 표현을 선택하고, 응답에 Content-Encoding: gzip 또는 Content-Encoding: br 같은 헤더를 붙입니다. br은 Brotli를 뜻합니다.www.rfc-editor.org↗developer.mozilla.org↗

서버나 CDN이 압축 방식에 따라 같은 URL의 서로 다른 응답을 제공한다면, 캐시가 이를 구분하도록 Vary: Accept-Encoding을 보내는 것이 일반적입니다. 그렇지 않으면 한 클라이언트에 맞춰 저장된 압축 표현이 다른 조건의 요청에 부적절하게 재사용될 위험이 있습니다.www.rfc-editor.org↗

다음은 개념적인 흐름입니다.

1. 브라우저가 Accept-Encoding: br, gzip처럼 지원 형식을 알립니다.
2. 서버 또는 CDN이 해당 파일의 Brotli·gzip·무압축 버전 중 하나를 선택합니다.
3. 응답 본문과 함께 선택된 형식을 Content-Encoding에 표시합니다.
4. 브라우저가 수신 과정 또는 수신 후 압축을 풀고, HTML 파싱·CSS 적용·JavaScript 실행을 이어 갑니다.

이 과정에서 gzip은 전송 시간을 줄일 수 있지만, 브라우저가 JavaScript를 파싱하고 실행하는 시간까지 없애지는 않습니다. 압축은 성능 문제의 한 조각이지, 모든 지연의 해결책은 아닙니다.developer.chrome.com↗web.dev↗

gzip은 어떤 파일에 효과적인가요?

gzip은 반복되는 문자열과 구조가 많은 텍스트에 특히 적합합니다. HTML 태그, CSS 선택자, JavaScript 식별자와 문법, JSON의 필드명처럼 반복이 많은 데이터는 압축 후 전송 크기가 크게 줄어들 수 있습니다. 일반적인 웹 성능 안내도 텍스트 리소스에는 압축을 적용하고, 이미 압축된 자산은 제외할 것을 권장합니다.developer.mozilla.org↗web.dev↗

JPEG, WebP, AVIF, 동영상, 오디오, 압축된 아카이브처럼 파일 형식 자체가 이미 압축을 수행하는 경우에는 gzip을 다시 적용해도 이득이 작을 수 있습니다. 작은 파일도 마찬가지입니다. 웹.dev는 약 1KiB보다 작은 리소스는 압축 효율이 낮거나 오히려 의미 있는 절감이 없을 수 있다고 설명합니다.developer.mozilla.org↗web.dev↗

여기서 중요한 구분은 전송 크기와 원본 크기입니다. 개발자 도구의 Network 패널에서는 압축 후 내려받은 크기와 압축 전 크기를 비교할 수 있으며, 응답 헤더의 Content-Encoding으로 실제 적용 여부도 확인할 수 있습니다.developer.chrome.com↗

gzip과 Brotli는 어떻게 다른가요?

Brotli는 gzip의 후속 버전이 아니라, HTTP 콘텐츠 압축에서 gzip과 함께 선택할 수 있는 다른 알고리즘입니다. 현대 웹에서는 텍스트 자산에 Brotli를 우선 제공하고, Brotli를 쓰지 못하는 클라이언트를 위해 gzip을 함께 제공하는 구성이 흔합니다. 브라우저의 Accept-Encoding과 서버의 협상이 있으므로, 같은 URL에 대해 클라이언트별로 다른 압축 표현을 보낼 수 있습니다.developer.mozilla.org↗developer.mozilla.org↗

일반적으로 Brotli는 웹 텍스트에서 gzip보다 더 작은 결과를 낼 가능성이 있습니다. 다만 이것이 항상 전체 페이지 체감 속도의 비례 개선을 뜻하지는 않습니다. 절감된 바이트가 작거나, 병목이 이미지·서버 처리·JavaScript 실행에 있다면 gzip에서 Brotli로의 교체 효과는 제한적일 수 있습니다. 동적으로 압축하는 서버에서는 압축률을 높이는 설정이 CPU 사용량과 응답 지연을 늘릴 수도 있으므로, 정적 자산은 빌드·CDN 단계에서 사전 압축하고 동적 응답은 실제 부하를 기준으로 조정하는 판단이 필요합니다.web.dev↗web.dev↗

즉, 선택 기준은 “Brotli가 무조건 더 낫다”가 아니라 다음에 가깝습니다.

• 텍스트 자산이 크고 반복 방문자가 아닌 신규 방문도 많다면 Brotli와 gzip의 이중 제공을 검토합니다.
• 이미 CDN이 적절한 압축을 제공한다면 애플리케이션에서 중복 압축하지 않습니다.
• 서버 CPU가 빠듯한 동적 서비스라면 압축 수준과 TTFB의 균형을 측정합니다.
• 이미지·동영상 비중이 크다면 텍스트 압축보다 미디어 최적화가 먼저일 수 있습니다.

HTTP/3는 무엇을 바꾸나요?

HTTP/3는 HTTP의 요청·응답 의미는 유지하면서, 전송 기반을 TCP 대신 QUIC으로 바꾼 표준입니다. QUIC은 UDP 위에서 동작하지만, 단순히 UDP로 HTTP를 보내는 방식은 아닙니다. 연결 설정, 암호화, 신뢰성, 혼잡 제어, 다중 스트림 같은 기능을 제공하며, HTTP/3는 이를 활용해 HTTP 메시지를 전달합니다.datatracker.ietf.org↗developer.mozilla.org↗

HTTP/1.1은 한 연결에서 요청 처리의 제약이 커서 여러 TCP 연결을 병행하는 방식이 널리 쓰였습니다. HTTP/2는 하나의 TCP 연결에서 여러 요청을 다중화해 이를 개선했습니다. 하지만 TCP는 수신 데이터의 순서를 보장하므로, 연결에서 패킷 하나가 유실되면 뒤에 도착한 데이터도 해당 손실이 복구될 때까지 애플리케이션에 순서대로 넘길 수 없는 문제가 생깁니다. HTTP/2에서는 이 TCP 수준의 지연이 여러 HTTP 스트림에 영향을 줄 수 있습니다.datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/3의 QUIC은 스트림별로 신뢰성 있는 순서 전달을 관리합니다. 따라서 어떤 스트림의 데이터가 유실됐다고 해서, 관련 없는 다른 스트림까지 반드시 멈춰야 하는 것은 아닙니다. RFC 9000은 패킷 손실 시 그 패킷에 있던 데이터의 스트림만 재전송 대기로 막히고, 다른 스트림은 진행할 수 있다고 설명합니다.www.rfc-editor.org↗

‘헤드오브라인 블로킹 제거’라는 표현은 어디까지 맞나요?

HTTP/3가 해결하려는 것은 주로 연결 전체에 걸쳐 발생하는 전송 계층의 헤드오브라인 블로킹입니다. 이것을 “모든 대기가 사라진다”로 이해하면 부정확합니다.

첫째, 하나의 스트림 안에서는 여전히 순서가 중요합니다. HTML 문서 본문이나 하나의 큰 이미지처럼 같은 스트림에서 앞부분이 유실되면, 그 스트림의 뒤 데이터는 필요한 순서가 갖춰질 때까지 완전히 활용될 수 없습니다. 둘째, 하나의 QUIC 패킷에 여러 스트림의 데이터가 함께 들어 있었다면 그 패킷의 유실은 그 안에 포함된 여러 스트림을 동시에 지연시킬 수 있습니다.www.rfc-editor.org↗

따라서 HTTP/3의 이점은 특히 패킷 손실이나 재정렬이 발생하는 네트워크에서 잘 드러날 수 있습니다. 반면 유선·저지연·저손실 환경에서 작은 페이지를 보는 경우에는 HTTP/2 대비 차이가 작거나 측정 조건에 따라 달라질 수 있습니다. 이는 HTTP/3가 바이트를 마술처럼 줄이는 기술이 아니라, 전송 과정의 대기 전파를 줄이는 구조이기 때문입니다.datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/3의 QPACK은 gzip과 무엇이 다른가요?

HTTP/3에는 QPACK이라는 헤더 압축 방식이 있습니다. 이것 때문에 HTTP/3가 gzip을 포함한다고 오해하기 쉽지만, 적용 대상이 다릅니다. QPACK은 Cookie, Content-Type, Cache-Control처럼 HTTP 요청과 응답의 헤더 필드를 효율적으로 표현하기 위한 방식입니다. gzip과 Brotli는 HTML·CSS·JavaScript 등의 응답 본문을 압축하는 콘텐츠 인코딩입니다.datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/2의 HPACK은 헤더 압축 상태가 순서대로 전달된다는 전제에 기대지만, QUIC의 독립 스트림 구조에서는 그 전제를 그대로 쓰기 어렵습니다. QPACK은 별도의 단방향 스트림을 통해 동적 테이블 상태를 관리해, 압축 효율과 헤더 블로킹 위험 사이에서 구현체가 균형을 잡을 수 있도록 설계됐습니다.datatracker.ietf.org↗datatracker.ietf.org↗

실제 페이지 성능 관점에서 보면 다음과 같이 역할을 나눠 생각하면 됩니다.

• gzip·Brotli: 텍스트 본문의 전송량을 줄입니다.
• QPACK: 요청·응답 헤더의 전송 효율을 높입니다.
• HTTP/3·QUIC: 다중 요청과 손실 상황에서 전송 지연이 다른 요청으로 번지는 정도를 줄입니다.
• 캐시: 이미 받은 리소스를 다시 전송하지 않게 합니다.
• 이미지·코드 최적화: 처음부터 내려받고 처리해야 할 작업량을 줄입니다.

이들은 서로 경쟁하는 단일 선택지가 아니라, 서로 다른 병목을 다루는 조합입니다.

웹페이지 체감 속도에서 더 큰 병목은 무엇인가요?

사용자가 느끼는 로딩 속도는 하나의 숫자가 아닙니다. 서버가 첫 바이트를 보내는 시간, 첫 화면의 주요 콘텐츠가 보이는 시간, 버튼과 입력이 반응하는 시간은 각각 다른 원인에 의해 늦어질 수 있습니다. 특히 LCP(Largest Contentful Paint)는 뷰포트 안에서 가장 큰 이미지·텍스트 블록·비디오가 렌더링된 시점을 나타내므로, 첫 화면 경험을 점검하는 데 유용합니다.web.dev↗

LCP가 느리다고 해서 언제나 네트워크 압축이 원인은 아닙니다. 웹.dev는 LCP를 진단할 때 TTFB, 리소스 로드 지연, 리소스 로드 시간, 요소 렌더링 지연을 구분해 보도록 안내합니다. 예를 들어 이미지를 빨리 내려받아도 큰 CSS가 렌더링을 막거나, 메인 스레드가 JavaScript 장기 작업으로 바쁘면 이미지를 화면에 표시하지 못할 수 있습니다.web.dev↗

첫 화면 이미지가 병목인 경우

상품 상세 페이지의 큰 제품 사진, 뉴스 메인의 대표 사진, 여행 페이지의 배너처럼 첫 화면에서 가장 큰 요소가 이미지인 경우가 많습니다. 이때 gzip을 켜도 JPEG·WebP·AVIF 자체에는 큰 도움을 주지 못합니다. 더 효과적인 접근은 표시 크기에 맞는 이미지를 제공하고, 적절한 현대 포맷을 사용하며, 첫 화면의 LCP 이미지를 loading="lazy"로 늦추지 않는 것입니다. 필요한 경우 fetchpriority="high"로 우선순위 힌트를 줄 수 있지만, 여러 이미지에 무분별하게 높은 우선순위를 주면 오히려 경쟁이 생길 수 있습니다.web.dev↗web.dev↗

CSS와 JavaScript가 병목인 경우

CSS는 화면을 스타일 없는 상태로 보이지 않게 하기 위해 렌더링을 막는 성격이 있습니다. 그러나 너무 큰 CSS, 초기 화면에 필요 없는 CSS, 동기적으로 불러오는 스크립트는 주요 콘텐츠 표시를 늦출 수 있습니다. 대형 JavaScript 번들은 전송이 끝난 뒤에도 파싱·컴파일·실행을 위해 브라우저 메인 스레드를 사용하므로, gzip으로 다운로드 크기만 줄여서는 충분하지 않을 수 있습니다.developer.chrome.com↗web.dev↗

따라서 JavaScript 성능은 압축과 별도로 살펴야 합니다. 미사용 코드를 제거하고, 초기 화면에 필요 없는 기능을 지연 로드하며, 긴 작업을 쪼개고, 가능하다면 서버 렌더링·사전 렌더링으로 초기 HTML에서 핵심 콘텐츠와 리소스를 발견할 수 있게 하는 방식이 후보가 됩니다. 다만 서버 렌더링도 서버 처리 시간을 늘려 TTFB에 영향을 줄 수 있으므로, 구조 변경은 측정과 함께 판단해야 합니다.web.dev↗

서버 응답과 캐시가 병목인 경우

TTFB가 길면 브라우저는 HTML을 받기 전까지 후속 리소스를 발견하기 어렵습니다. 서버가 먼 지역에 있거나, 데이터베이스 처리와 개인화가 오래 걸리거나, 불필요한 리디렉션이 있거나, 캐시가 활용되지 않는 경우가 대표적입니다. 이때 HTTP/3는 전송 단계의 일부를 개선할 수 있지만, 서버가 첫 응답을 생성하는 시간을 직접 줄이지는 않습니다.web.dev↗

캐시는 성능 개선 방식 중 성격이 다릅니다. gzip은 같은 데이터를 더 작게 보내고, HTTP/3는 데이터를 전달하는 연결 특성을 바꾸며, 캐시는 조건이 맞는 재방문에서 데이터를 다시 보내지 않게 합니다. 재방문 비중이 높은 서비스에서는 적절한 캐시 정책이 압축 알고리즘을 바꾸는 것보다 더 큰 체감 차이를 만들 수 있습니다. 다만 HTML처럼 자주 바뀌거나 사용자별로 다른 응답은 캐시 전략을 더 신중히 설계해야 합니다.www.rfc-editor.org↗developer.chrome.com↗

그렇다면 성능 개선의 실질 체감 순위는 무엇인가요?

모든 사이트에 적용되는 고정 순위는 없습니다. 페이지 구성, 신규·재방문 비율, 사용자 네트워크, 서버 위치, 기존 설정에 따라 결과가 달라지기 때문입니다. 다만 일반적인 콘텐츠·커머스·서비스 페이지에서, 아직 큰 병목이 남아 있다는 전제라면 다음 순서로 점검하는 것이 현실적입니다.

1. 첫 화면 핵심 콘텐츠를 늦추는 문제를 찾습니다. LCP 이미지의 크기·발견 시점·우선순위, 렌더 차단 CSS, 동기 JavaScript, 불필요한 클라이언트 렌더링을 먼저 봅니다.web.dev↗
2. 서버 응답 시간과 캐시를 점검합니다. TTFB, 리디렉션, CDN 배치, 정적 자산 캐시, 백엔드 처리 지연을 확인합니다.web.dev↗www.rfc-editor.org↗
3. HTML·CSS·JavaScript·JSON의 텍스트 압축을 확인합니다. 무압축 상태라면 gzip 또는 Brotli 적용은 높은 우선순위입니다. 이미 적절히 압축됐다면 같은 영역에서의 추가 이득은 제한적일 수 있습니다.developer.mozilla.org↗developer.chrome.com↗
4. 전체 전송량과 요청 구성을 줄입니다. 크기가 큰 이미지·스크립트·서드파티 리소스를 정리하고, 꼭 필요한 시점까지 요청을 미룹니다. 큰 네트워크 페이로드는 긴 로드 시간과 연관됩니다.developer.chrome.com↗developer.chrome.com↗
5. HTTP/3를 제공하고 HTTP/2 폴백을 유지한 채 실제 트래픽에서 검증합니다. 특히 모바일, 고지연, 패킷 손실 환경 및 동시 요청이 많은 페이지에서 전후 차이를 봅니다.datatracker.ietf.org↗www.rfc-editor.org↗

다만 이 순위에는 중요한 예외가 있습니다. 텍스트 응답이 1MB 이상인데 무압축인 애플리케이션이라면 3번의 gzip·Brotli 적용이 가장 큰 단기 개선이 될 수 있습니다. 반대로 대표 이미지가 수 MB이고 텍스트는 이미 Brotli로 압축돼 있다면 이미지 최적화가 우선입니다. 서버가 수 초 동안 HTML 생성을 못 하는 상황이라면 HTTP/3보다 백엔드·캐시가 먼저입니다.developer.mozilla.org↗web.dev↗developer.chrome.com↗

gzip과 HTTP/3만 놓고 비교하면

두 기술만 고른다면 판단은 비교적 단순합니다.

• 텍스트가 무압축인 경우: gzip 또는 Brotli가 보통 먼저입니다. 전송할 데이터량 자체를 줄이므로 모든 지원 연결에서 이득을 기대할 수 있습니다.
• 압축이 이미 정상인 경우: HTTP/3의 상대적 가치가 올라갑니다. 다만 실제 개선은 네트워크 품질과 요청 구조에 따라 달라집니다.
• 이미지·동영상 중심 페이지: gzip과 HTTP/3 중 하나만으로는 큰 문제를 해결하기 어렵습니다. 미디어 최적화가 앞섭니다.
• 대형 JavaScript 애플리케이션: gzip은 시작점일 뿐입니다. 전송 후 실행 비용까지 점검해야 체감 개선이 이어집니다.
• 재방문이 많은 서비스: 캐시 적중 여부가 압축 방식 변경보다 더 큰 변수일 수 있습니다.

따라서 “gzip이 HTTP/3보다 항상 위” 또는 “HTTP/3가 최신이므로 항상 위”라는 결론은 둘 다 정확하지 않습니다. 정확한 표현은 무압축 텍스트에는 콘텐츠 압축이 기본 우선순위이고, HTTP/3는 전송 환경과 요청 패턴에 따라 추가 효과를 내는 기반 최적화라는 것입니다.

HTTP/3 도입 시에는 어떤 제약을 살펴야 하나요?

HTTP/3를 제공하려면 서버·CDN·로드 밸런서·방화벽·관측 도구가 QUIC과 UDP 기반 트래픽을 적절히 다룰 수 있어야 합니다. 클라이언트나 경로가 HTTP/3를 쓰지 못하는 경우도 고려해야 하므로, 일반적으로 HTTP/2 또는 HTTP/1.1을 함께 제공하는 점진적 배포가 적합합니다. HTTP/3 표준은 QUIC을 기반으로 하고, 클라이언트가 HTTP/3 서버를 발견한 뒤 QUIC 연결을 수립하는 과정을 정의합니다.datatracker.ietf.org↗

운영 관점에서는 프로토콜 전환만으로 성공을 판단하지 않는 것이 중요합니다. HTTP/3 연결 비율, 실패·재시도 비율, TTFB, LCP, 오류율, CPU 사용량을 함께 관찰해야 합니다. 특히 CDN이나 프록시가 앞단에 있다면 원본 서버에서 보이는 프로토콜과 최종 사용자 브라우저가 실제로 사용한 프로토콜이 다를 수 있으므로, 사용자 측 관측을 병행해야 합니다.developer.chrome.com↗developer.chrome.com↗

압축에는 보안상 주의할 점도 있나요?

있습니다. HTTPS를 쓰더라도 공격자가 제어할 수 있는 입력값과 비밀값이 같은 압축 문맥에서 함께 압축되면, 암호문 길이 차이를 관찰해 비밀값을 추정하려는 공격이 가능할 수 있습니다. HTTP 의미 규격과 HTTP/3 규격은 민감한 데이터와 공격자 제어 데이터를 함께 압축하는 상황에 주의를 요구하며, 가장 확실한 완화책으로 민감한 데이터의 압축을 끄거나 압축 문맥을 분리하는 방식을 제시합니다.www.rfc-editor.org↗www.rfc-editor.org↗

이 문제는 모든 gzip 응답이 위험하다는 뜻은 아닙니다. 핵심은 반사된 사용자 입력, 인증 관련 비밀값, 공격자가 반복 요청과 응답 크기 관찰을 할 수 있는 조건이 동시에 성립하는지입니다. 로그인·결제·계정 복구처럼 민감한 흐름은 일반 정적 자산과 같은 압축 정책을 기계적으로 적용하지 말고, 보안 설계와 함께 검토해야 합니다.www.rfc-editor.org↗datatracker.ietf.org↗

내 사이트에서는 무엇을 측정해야 하나요?

성능 개선의 결과는 실험실 환경의 점수 하나보다 실제 사용자 경험에서 확인하는 편이 안전합니다. Lighthouse는 문제 후보를 빠르게 찾는 데 유용하지만, 네트워크·기기·캐시·지역이 다양한 실제 사용자 전체를 대신하지는 않습니다. 개발자 도구와 실제 사용자 모니터링을 함께 사용하면 가설과 결과를 분리하기 좋습니다.developer.chrome.com↗developer.chrome.com↗

다음 순서로 점검할 수 있습니다.

1. 현재 전송 상태를 확인합니다. Network 패널에서 주요 HTML·CSS·JS·JSON 응답의 Content-Encoding, 전송 크기, 원본 크기를 봅니다.developer.chrome.com↗
2. 프로토콜을 확인합니다. Protocol 열에서 실제 요청이 h3, h2, http/1.1 중 무엇을 사용했는지 확인합니다.
3. 주요 사용자 지표를 나눕니다. 신규 방문과 재방문, 모바일과 데스크톱, 지역, 네트워크 유형별로 TTFB·LCP·상호작용 지표를 비교합니다.web.dev↗web.dev↗
4. 한 번에 하나씩 변경합니다. gzip 활성화, Brotli 추가, 이미지 교체, JavaScript 분할, HTTP/3 활성화를 동시에 배포하면 어느 변화가 효과를 냈는지 알기 어렵습니다.
5. 부작용도 기록합니다. 서버 CPU, 오류율, 캐시 적중률, HTTP/3 연결 실패 또는 폴백 비율을 함께 봅니다.

예를 들어 무압축 JavaScript 번들을 gzip으로 전환한 뒤 전송 크기는 줄었지만 LCP가 거의 변하지 않았다면, 다음 병목은 압축이 아니라 큰 이미지·CSS·JavaScript 실행일 가능성이 있습니다. 반대로 모바일 네트워크 사용자에서 HTTP/3 도입 뒤 LCP의 긴 꼬리 구간이 줄었다면, 평균값뿐 아니라 손실과 지연이 큰 환경에서의 이득을 확인할 수 있습니다. 이런 결론은 기술의 이름이 아니라 측정된 병목에서 출발합니다.web.dev↗www.rfc-editor.org↗

정리: gzip과 HTTP/3는 순위 경쟁보다 역할 분담으로 봐야 합니다

gzip과 HTTP/3는 모두 웹 성능에 유용하지만, 비교의 기준이 다릅니다. gzip은 텍스트 응답의 전송 바이트를 줄이고, HTTP/3는 QUIC 기반 다중 스트림으로 네트워크 손실이 여러 요청에 미치는 영향을 줄일 수 있습니다. HTTP/3의 QPACK은 헤더 압축이며, gzip·Brotli가 담당하는 본문 압축을 대체하지 않습니다.www.rfc-editor.org↗datatracker.ietf.org↗datatracker.ietf.org↗

가장 실용적인 우선순위는 먼저 LCP·TTFB·렌더 차단·JavaScript·이미지·캐시 중 실제 병목을 찾고, 텍스트 압축이 빠져 있다면 이를 기본값으로 보완한 뒤, HTTP/3을 실제 사용자 조건에서 검증하는 것입니다. 성능은 최신 기술 하나를 추가하는 문제가 아니라, 사용자가 기다리는 가장 긴 경로를 짧게 만드는 문제입니다.web.dev↗developer.chrome.com↗

참고 자료

• HTTP Semantics 및 콘텐츠 인코딩 규격www.rfc-editor.org↗
• HTTP/3 표준datatracker.ietf.org↗
• QPACK 헤더 압축 표준datatracker.ietf.org↗
• QUIC 전송 규격www.rfc-editor.org↗
• 웹 성능과 LCP 최적화 안내web.dev↗
• HTTP 압축 개요developer.mozilla.org↗