Which should I implement first: gzip or HTTP/3?

If text responses are uncompressed, it is usually more sensible to first check content compression such as gzip or Brotli. If compression is already working properly, HTTP/3 may offer additional improvements on networks with packet loss or latency and for many concurrent requests. However, the real priority depends on whether the LCP image, render-blocking CSS or JavaScript, or TTFB is the larger bottleneck.

Do I still need gzip if I use HTTP/3?

Yes. HTTP/3's QPACK is a compression method for HTTP headers, while gzip is a content encoding that compresses response bodies such as HTML, CSS, JavaScript, and JSON. They operate at different layers and can be used together.

Will applying gzip to images make them load faster?

Generally, no. Files that are already compressed, such as JPEG, WebP, AVIF, video, and audio, typically gain little from being compressed again with gzip and may only add processing overhead. For image performance, using the appropriate dimensions and format and prioritizing the images that are needed matters more.

Does HTTP/3 always reduce loading time for every user?

Not always. Through QUIC's independent streams, HTTP/3 can reduce the extent to which packet loss affects other streams, but it does not directly solve slow server processing, large images, render-blocking resources, or JavaScript execution time. HTTP/2 and HTTP/3 should be measured separately in real-user environments.

Can I provide only Brotli instead of gzip?

Brotli support is widespread in modern browsers, but servers must inspect the request's Accept-Encoding header and choose an encoding the client can accept. In practice, it is common to provide Brotli while retaining gzip as a compatibility fallback.

What Are gzip and HTTP/3, and What Should You Improve First for Web Page Loading Performance?

By 쉬었음.comPublished September 12, 2026

gzip is a way to reduce the amount of data that must be transmitted by compressing a web page's text files, while HTTP/3 is a protocol that changes how multiple requests are handled and packet loss is addressed by delivering HTTP over QUIC. Both can help page loading, but they do not solve the same problem. Rather than asking, “Which is faster, gzip or HTTP/3?” it is more accurate to first ask where the current page's bottleneck is: transfer bytes, network loss, server response, images, rendering, or JavaScript.www.rfc-editor.org datatracker.ietf.org

One of the most common misconceptions in practice is that enabling HTTP/3 automatically makes an entire website faster. HTTP/3 can be an important foundational improvement, but it does not replace solutions for an excessively large above-the-fold image, render-blocking CSS or JavaScript, or a slow server response. Conversely, if a site does not compress text responses at all, enabling gzip or Brotli can noticeably reduce transfer volume with a relatively small configuration change.web.dev developer.mozilla.org

What exactly is gzip?

gzip is a widely used content encoding (Content-Encoding) for HTTP. A server compresses original HTML, CSS, JavaScript, JSON, SVG, and similar content in gzip format before sending it, and the browser decompresses it and uses the original content. The HTTP Semantics specification defines gzip as a content coding that uses LZ77-family compression and a 32-bit CRC.www.rfc-editor.org www.rfc-editor.org

The key point is that the file's logical type does not change. For example, even when a server delivers app.js with gzip, the browser ultimately executes the same JavaScript. What changes is the number of bytes that travel over the network. When a file is smaller, it takes less time to download over limited bandwidth, and it can also reduce a user's mobile data usage.www.rfc-editor.org developer.chrome.com

How do browsers and servers choose a compression method?

Browsers use the Accept-Encoding request header to indicate which compression formats they can decode. Based on that list and its priorities, the server selects an appropriate representation and adds a header such as Content-Encoding: gzip or Content-Encoding: br to the response. br means Brotli.www.rfc-editor.org developer.mozilla.org

If a server or CDN provides different responses for the same URL depending on the compression method, it is common to send Vary: Accept-Encoding so caches distinguish them. Otherwise, a compressed representation stored for one client could be inappropriately reused for a request with different conditions.www.rfc-editor.org

The following is a conceptual flow:

The browser declares supported formats, such as Accept-Encoding: br, gzip.
The server or CDN chooses one of the file's Brotli, gzip, or uncompressed versions.
It identifies the selected format in Content-Encoding alongside the response body.
The browser decompresses the response during or after receipt, then continues HTML parsing, CSS application, and JavaScript execution.

gzip can reduce transfer time in this process, but it does not eliminate the time the browser spends parsing and executing JavaScript. Compression is one piece of performance, not a solution to every source of delay.developer.chrome.com web.dev

Which files benefit from gzip?

gzip is especially well suited to text with many repeated strings and structures. Data with substantial repetition, such as HTML tags, CSS selectors, JavaScript identifiers and syntax, and JSON field names, can become much smaller for transfer after compression. General web performance guidance also recommends applying compression to text resources and excluding assets that are already compressed.developer.mozilla.org web.dev

Asset type	General assessment for gzip	Higher-priority areas to examine
HTML	Usually suitable	Server response time, caching, document size
CSS	Usually suitable	Remove unused CSS, manage critical CSS
JavaScript	Usually suitable	Code splitting, remove unused code, execution time
JSON and API responses	Usually suitable	Response design, caching, remove unnecessary fields
SVG	Usually suitable	Clean up and simplify SVGs
JPEG, WebP, AVIF	Usually unsuitable	Image dimensions, format, responsive delivery
MP4 and audio	Usually unsuitable	Bitrate, streaming, lazy loading

For formats that already perform compression themselves, such as JPEG, WebP, AVIF, video, audio, and compressed archives, applying gzip again may provide little benefit. The same is true for small files. web.dev explains that resources smaller than roughly 1 KiB may compress inefficiently or provide no meaningful savings.developer.mozilla.org web.dev

An important distinction here is between transfer size and original size. In the Network panel of developer tools, you can compare the compressed download size with the uncompressed size, and you can check the Content-Encoding response header to verify whether compression was actually applied.developer.chrome.com

How do gzip and Brotli differ?

Brotli is not a successor to gzip; it is another algorithm that can be selected alongside gzip for HTTP content compression. On the modern web, it is common to prioritize Brotli for text assets while also providing gzip for clients that cannot use Brotli. Because browsers send Accept-Encoding and servers negotiate the result, different compressed representations can be sent for the same URL depending on the client.developer.mozilla.org developer.mozilla.org

In general, Brotli can produce smaller results than gzip for web text. However, that does not always mean a proportional improvement in overall perceived page speed. If the bytes saved are small, or the bottleneck is images, server processing, or JavaScript execution, switching from gzip to Brotli may have a limited effect. On servers that compress dynamically, settings that increase the compression ratio can also increase CPU usage and response latency. Static assets should therefore be precompressed during the build or CDN stage, while dynamic responses should be tuned based on actual load.web.dev web.dev

In other words, the selection criteria are closer to the following than to “Brotli is always better”:

If text assets are large and there are many first-time visitors, consider serving both Brotli and gzip.
If a CDN already provides suitable compression, do not compress the same content again in the application.
For a dynamic service with constrained server CPU, measure the balance between compression level and TTFB.
If images and video account for a large share of the page, media optimization may come before text compression.

What does HTTP/3 change?

HTTP/3 is a standard that retains HTTP's request-response semantics while replacing TCP with QUIC as its transport foundation. QUIC operates over UDP, but it is not simply a way to send HTTP over UDP. It provides features such as connection establishment, encryption, reliability, congestion control, and multiplexed streams, and HTTP/3 uses these features to deliver HTTP messages.datatracker.ietf.org developer.mozilla.org

HTTP/1.1 had substantial limitations in handling requests over a single connection, so using multiple TCP connections in parallel became widespread. HTTP/2 improved this by multiplexing multiple requests over one TCP connection. However, because TCP guarantees in-order delivery of received data, when a packet is lost on a connection, data that arrives afterward cannot be handed to the application in order until that loss is recovered. In HTTP/2, this TCP-level delay can affect multiple HTTP streams.datatracker.ietf.org www.rfc-editor.org

HTTP/3's QUIC manages reliable, in-order delivery per stream. As a result, loss of data on one stream does not necessarily require unrelated streams to stop as well. RFC 9000 explains that when a packet is lost, only the streams containing data from that packet are blocked pending retransmission, while other streams can continue.www.rfc-editor.org

How accurate is the phrase “eliminates head-of-line blocking”?

What HTTP/3 primarily addresses is transport-layer head-of-line blocking across the entire connection. It is inaccurate to interpret this as meaning that all waiting disappears.

First, order still matters within a single stream. If an earlier portion is lost in the same stream, such as the body of an HTML document or one large image, later data in that stream cannot be fully used until the required order is restored. Second, if data from multiple streams was included in one QUIC packet, loss of that packet can delay several of those streams simultaneously.www.rfc-editor.org

HTTP/3's benefits can therefore be especially apparent on networks where packet loss or reordering occurs. By contrast, when viewing a small page on a wired, low-latency, low-loss connection, the difference compared with HTTP/2 may be small or may vary according to measurement conditions. This is because HTTP/3 is not a technology that magically reduces bytes; it is an architecture that reduces the extent to which waiting during transport spreads.datatracker.ietf.org www.rfc-editor.org

How is HTTP/3's QPACK different from gzip?

HTTP/3 includes a header compression mechanism called QPACK. This can make it easy to mistakenly believe that HTTP/3 includes gzip, but they apply to different targets. QPACK is designed to efficiently represent header fields in HTTP requests and responses, such as Cookie, Content-Type, and Cache-Control. gzip and Brotli are content encodings that compress response bodies such as HTML, CSS, and JavaScript.datatracker.ietf.org www.rfc-editor.org

HTTP/2's HPACK relies on the assumption that header compression state is delivered in sequence, but that assumption is difficult to apply unchanged to QUIC's independent stream architecture. QPACK uses separate unidirectional streams to manage dynamic table state, allowing implementations to balance compression efficiency against the risk of header blocking.datatracker.ietf.org datatracker.ietf.org

From the perspective of actual page performance, it is useful to think of their roles as follows:

gzip and Brotli: Reduce the transfer volume of text bodies.
QPACK: Improves transmission efficiency for request and response headers.
HTTP/3 and QUIC: Reduce the extent to which transport delays from multiple requests and loss conditions spread to other requests.
Caching: Prevents resources that have already been received from being transferred again.
Image and code optimization: Reduces the amount of work that must be downloaded and processed in the first place.

These are not competing single-choice options; they are complementary approaches to different bottlenecks.

What are the bigger bottlenecks in perceived web page speed?

The loading speed users perceive is not a single number. The time until the server sends the first byte, the time until the main above-the-fold content becomes visible, and the time until buttons and inputs respond can each be delayed by different causes. In particular, LCP (Largest Contentful Paint) represents the point when the largest image, text block, or video in the viewport is rendered, making it useful for assessing the initial-page experience.web.dev

Slow LCP does not always mean network compression is the cause. web.dev recommends separating TTFB, resource load delay, resource load time, and element render delay when diagnosing LCP. For example, even if an image downloads quickly, large CSS can block rendering, or the main thread can be too busy with long JavaScript tasks to display the image.web.dev

When the above-the-fold image is the bottleneck

The largest above-the-fold element is often an image, such as a large product photo on a product detail page, a lead image on a news homepage, or a banner on a travel page. In this situation, enabling gzip does not provide much help for JPEG, WebP, or AVIF files themselves. A more effective approach is to serve images sized for their display dimensions, use appropriate modern formats, and avoid delaying the LCP image with loading="lazy". When necessary, you can provide a priority hint using fetchpriority="high", but indiscriminately giving high priority to many images can instead create competition.web.dev web.dev

When CSS and JavaScript are the bottleneck

CSS has render-blocking characteristics because it prevents content from appearing unstyled. However, overly large CSS, CSS not needed for the initial view, and synchronously loaded scripts can delay display of the main content. Even after transfer finishes, large JavaScript bundles use the browser's main thread for parsing, compilation, and execution, so reducing only download size with gzip may not be enough.developer.chrome.com web.dev

JavaScript performance should therefore be examined separately from compression. Candidates include removing unused code, lazy-loading features not needed for the initial view, breaking up long tasks, and, where possible, using server rendering or prerendering so that the initial HTML exposes core content and resources for discovery. However, server rendering can also increase server processing time and affect TTFB, so architectural changes should be evaluated with measurement.web.dev

When server response and caching are the bottleneck

When TTFB is long, the browser has difficulty discovering subsequent resources before it receives the HTML. Common causes include a server located far away, lengthy database processing and personalization, unnecessary redirects, and unused caching opportunities. HTTP/3 can improve part of the transfer stage in this situation, but it does not directly reduce the time the server needs to generate the first response.web.dev

Caching is different in character from other performance improvements. gzip sends the same data in a smaller form, HTTP/3 changes the connection characteristics used to deliver data, and caching prevents data from being sent again on qualifying repeat visits. For a service with a high share of repeat visitors, an appropriate caching policy can produce a larger perceived difference than changing compression algorithms. However, caching strategies for responses that change frequently or vary by user, such as HTML, must be designed more carefully.www.rfc-editor.org developer.chrome.com

What is the practical ranking of performance improvements by perceived impact?

There is no fixed ranking that applies to every site. Results differ based on page composition, the ratio of first-time to repeat visitors, user networks, server locations, and existing configuration. Still, for typical content, commerce, and service pages where major bottlenecks remain, the following order is practical for investigation.

Find what delays the core above-the-fold content. First examine the LCP image's size, discovery time, and priority; render-blocking CSS; synchronous JavaScript; and unnecessary client-side rendering.web.dev
Review server response time and caching. Check TTFB, redirects, CDN placement, static asset caching, and backend processing delays.web.dev www.rfc-editor.org
Check text compression for HTML, CSS, JavaScript, and JSON. If they are uncompressed, applying gzip or Brotli is a high priority. If they are already properly compressed, additional gains in the same area may be limited.developer.mozilla.org developer.chrome.com
Reduce total transfer volume and optimize the request composition. Clean up large images, scripts, and third-party resources, and defer requests until they are actually needed. Large network payloads are associated with long load times.developer.chrome.com developer.chrome.com
Provide HTTP/3, retain an HTTP/2 fallback, and validate it with real traffic. Compare before and after results, especially on mobile, high-latency, packet-loss environments and on pages with many concurrent requests.datatracker.ietf.org www.rfc-editor.org

This ranking has important exceptions. If an application has uncompressed text responses larger than 1 MB, applying gzip or Brotli in step 3 may be the biggest short-term improvement. Conversely, if a lead image is several MB and text is already compressed with Brotli, image optimization takes priority. If the server cannot generate HTML for several seconds, backend and caching work comes before HTTP/3.developer.mozilla.org web.dev developer.chrome.com

If you compare only gzip and HTTP/3

If choosing between only these two technologies, the decision is relatively straightforward.

When text is uncompressed: gzip or Brotli usually comes first. It reduces the amount of data to transmit, so benefits can be expected on every supported connection.
When compression is already working correctly: the relative value of HTTP/3 increases. However, the actual improvement depends on network quality and request structure.
For image- and video-heavy pages: neither gzip nor HTTP/3 alone is likely to solve the larger issue. Media optimization comes first.
For large JavaScript applications: gzip is only a starting point. You must also examine post-transfer execution costs to achieve a continued perceived improvement.
For services with many repeat visits: cache hit rates may be a bigger variable than changing compression methods.

Therefore, neither conclusion—“gzip is always ahead of HTTP/3” or “HTTP/3 is newer, so it is always ahead”—is accurate. A more precise statement is: content compression is the baseline priority for uncompressed text, while HTTP/3 is a foundational optimization that can provide additional benefits depending on transport conditions and request patterns.

What constraints should you consider when adopting HTTP/3?

To provide HTTP/3, servers, CDNs, load balancers, firewalls, and observability tools must be able to handle QUIC and UDP-based traffic appropriately. Since some clients or paths may not be able to use HTTP/3, a gradual deployment that also provides HTTP/2 or HTTP/1.1 is generally appropriate. The HTTP/3 standard is based on QUIC and defines the process by which a client discovers an HTTP/3 server and then establishes a QUIC connection.datatracker.ietf.org

From an operational perspective, it is important not to judge success based on a protocol switch alone. Monitor HTTP/3 connection share, failure and retry rates, TTFB, LCP, error rates, and CPU usage together. In particular, when a CDN or proxy sits in front of the origin, the protocol visible at the origin server may differ from the protocol the end user's browser actually used, so client-side observation should also be included.developer.chrome.com developer.chrome.com

Are there security considerations for compression?

Yes. Even with HTTPS, if attacker-controlled input and secret values are compressed together in the same compression context, an attacker may be able to infer the secret by observing differences in ciphertext length. The HTTP Semantics and HTTP/3 specifications caution against situations where sensitive data and attacker-controlled data are compressed together, and identify disabling compression for sensitive data or separating compression contexts as the most reliable mitigations.www.rfc-editor.org www.rfc-editor.org

This does not mean that every gzip response is dangerous. The key question is whether reflected user input, authentication-related secrets, and conditions allowing an attacker to repeatedly make requests and observe response sizes all exist at the same time. Sensitive flows such as login, payment, and account recovery should not have the same compression policies mechanically applied as general static assets; they should be reviewed alongside the security design.www.rfc-editor.org datatracker.ietf.org

What should I measure on my site?

It is safer to validate performance improvements through real user experience than through a single laboratory score. Lighthouse is useful for quickly identifying potential issues, but it does not represent all real users across diverse networks, devices, cache states, and regions. Using developer tools alongside real user monitoring makes it easier to separate hypotheses from results.developer.chrome.com developer.chrome.com

You can review performance in the following order:

Check the current transfer state. In the Network panel, review Content-Encoding, transfer size, and original size for key HTML, CSS, JS, and JSON responses.developer.chrome.com
Check the protocol. In the Protocol column, confirm whether actual requests use h3, h2, or http/1.1.
Segment key user metrics. Compare TTFB, LCP, and interaction metrics by first-time versus repeat visit, mobile versus desktop, region, and network type.web.dev web.dev
Change one thing at a time. If you deploy gzip enablement, Brotli support, image replacements, JavaScript splitting, and HTTP/3 enablement simultaneously, it is difficult to identify which change produced an effect.
Record side effects as well. Also monitor server CPU, error rates, cache hit rates, and HTTP/3 connection failure or fallback rates.

For example, if switching an uncompressed JavaScript bundle to gzip reduces transfer size but barely changes LCP, the next bottleneck is likely a large image, CSS, or JavaScript execution rather than compression. Conversely, if the long tail of LCP improves for mobile network users after adopting HTTP/3, you can identify benefits in high-loss and high-latency environments in addition to looking at averages. Such conclusions begin with measured bottlenecks, not the name of a technology.web.dev www.rfc-editor.org

Summary: Treat gzip and HTTP/3 as complementary roles, not a ranking contest

gzip and HTTP/3 are both useful for web performance, but the basis for comparing them differs. gzip reduces transfer bytes for text responses, while HTTP/3 can reduce the impact network loss has on multiple requests through QUIC-based multiplexed streams. HTTP/3's QPACK is header compression; it does not replace the body compression handled by gzip and Brotli.www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

The most practical priority is to first identify the actual bottleneck among LCP, TTFB, render blocking, JavaScript, images, and caching; fill in text compression as a baseline if it is missing; and then validate HTTP/3 under real-user conditions. Performance is not a matter of adding one latest technology—it is a matter of shortening the longest path the user must wait for.web.dev developer.chrome.com