# HTTP/2 vs HTTP/1.1: multiplexing, header compression and what changes for your site

> HTTP/2 vs HTTP/1.1: HTTP/2 sends every file of a page over one connection at once and compresses headers, where HTTP/1.1 queues files six at a time. What changes, what does not, and what happened to server push.

Updated 2026-10-04 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/http2-vs-http1

HTTP/2 and HTTP/1.1 carry the same requests, headers and status codes; what differs is how they travel. HTTP/1.1 sends one request at a time per connection, so browsers open up to six connections per host and queue the rest. HTTP/2 splits every request and response into frames that share a single connection, so all the files of a page can be in flight at once, and it compresses the repeated headers. For a page with many files, that removes most of the waiting in line; for a page with a few large files, the difference is small.

This guide is for site owners and developers comparing HTTP/2 vs HTTP/1.1 before switching, or trying to understand why a waterfall looks the way it does. It covers multiplexing, header compression, priorities and server push, the old HTTP/1.1 habits that now hurt, and how to check your site. For both protocol versions and HTTP/3 in one place, read the [guide to HTTP/2 and HTTP/3](https://getreport.app/guides/http2-and-http3).

## Quick answer

- **Same meaning, new transport format.** URLs, methods, headers, status codes and caching work as before; nothing in your pages has to change.
- **Multiplexing:** many requests and responses at once over one connection, instead of one at a time over up to six.
- **Header compression (HPACK):** repeated headers such as cookies are sent once and referenced afterwards.
- **One connection per host:** one TCP and TLS handshake instead of several.
- **Server push is gone in practice:** Chrome and Firefox removed it. Use preload links or 103 Early Hints.
- **Browsers only use HTTP/2 over HTTPS.**
- **Still on TCP:** one lost packet stalls every file on the connection; HTTP/3 fixes that. Check what your site uses with the [HTTP/2 and HTTP/3 test](https://getreport.app/tools/http2-test).

## HTTP/1.1 vs HTTP/2 at a glance

| | HTTP/1.1 | HTTP/2 |
| --- | --- | --- |
| Standard | RFC 2616 (1999), now RFC 9112 | RFC 7540 (2015), now RFC 9113 |
| Format on the wire | Text | Binary frames |
| Requests per connection at once | One (pipelining exists but browsers do not use it) | Many, as separate streams |
| Connections per host in browsers | Up to 6 | 1 |
| Header compression | None | HPACK |
| Prioritisation | None; the browser decides what to request when | The browser signals priorities; servers vary in following them |
| Server push | No | In the spec; removed from Chrome and Firefox |
| Encryption | Optional | Required by browsers (TLS) |
| Protocol chosen by | Default | ALPN during the TLS handshake (`h2`) |

## What is HTTP/1.1?

HTTP/1.1 is version 1.1 of the Hypertext Transfer Protocol, the rules a browser and a server use to ask for and send web pages. It was first published in 1997 (RFC 2068), revised in 1999 (RFC 2616), and in 2022 split into RFC 9110 for the meaning of requests and responses, RFC 9111 for caching and RFC 9112 for the HTTP/1.1 message format. RFC 9110 and 9111 also apply to HTTP/2 and HTTP/3, which is why headers, status codes and caching work the same in all three.

Messages in HTTP/1.1 are plain text you can read. A request is a line such as `GET /about HTTP/1.1`, followed by headers, one per line:

```text
GET /about HTTP/1.1
Host: example.com
Accept-Encoding: br, gzip
```

Compared with HTTP/1.0, it made connections persistent by default (keep-alive), required the `Host` header, so one server and one IP address can host many sites, and added chunked transfer and `Cache-Control`. Those are still the basis of the web. What it lacks, compared with HTTP/2, is a way to send more than one request at a time on a connection, which is the main difference between HTTP/1.1 and HTTP/2 and the subject of the rest of this guide.

## How HTTP/1.1 loads a page

A browser loading a page over HTTP/1.1 sends a request on a connection and waits for the whole response before it can send the next request on that connection. HTTP/1.1 did add keep-alive, so one connection can be reused for many requests, and it defined pipelining, which lets a client send several requests without waiting. But pipelined responses must come back in order, one slow response blocks the ones behind it, and many proxies handled it badly, so browsers never switched it on.

To get parallelism anyway, browsers open several connections per host, usually six. A page with 60 files from one host therefore downloads in about ten rounds: six files, then the next six as connections free up. In a waterfall chart this looks like a staircase, with long light "queued" or "stalled" bars before many requests. Each extra connection also needs its own TCP and TLS handshake.

This is **head-of-line blocking at the HTTP level**: a slow response occupies its connection, and everything waiting for that connection waits too.

## How HTTP/2 multiplexing works

HTTP/2 keeps a single connection per host and cuts every request and response into small binary **frames**. Each request-response pair gets a **stream** ID, and frames from different streams are interleaved on the connection. The browser sends all its requests as soon as it discovers them; the server answers them in whatever order they are ready, and frames from a slow response no longer block the others.

For the page with 60 files, the waterfall now shows the requests starting together, limited by bandwidth and the server rather than by a queue. One handshake replaces six. Congestion control also works better on one busy connection than on six competing ones.

HTTP/2 multiplexing does not remove every kind of blocking. It still runs over TCP, which delivers bytes strictly in order. If one packet is lost, TCP holds back everything after it, from every stream, until the packet is resent. On a good connection that is rare; on a weak mobile signal it is common, and it is the reason HTTP/3 moved to QUIC, where each stream is delivered independently. [What is QUIC?](https://getreport.app/guides/what-is-quic-http3) explains the difference.

## Header compression with HPACK

Every request carries headers: the host, the path, the user agent, accepted formats, and cookies, which can be several kilobytes on their own. Over HTTP/1.1, those headers are sent in full, as text, with every single request. A page with 80 requests repeats the same cookie 80 times.

HTTP/2's HPACK compression (RFC 7541) keeps a table of headers already sent on the connection, on both sides. After the first request, a repeated header is sent as a short reference to the table, and new values are Huffman-coded. On pages with many requests and large cookies, the savings are substantial, and they matter most on the upload side of slow mobile connections.

HPACK compresses headers only. HTML, CSS and JavaScript bodies still need Brotli or gzip, set in your server or CDN; see [text compression with gzip and Brotli](https://getreport.app/guides/text-compression-gzip-brotli).

## Priorities

With every request in flight at once, the order of delivery matters: the CSS that blocks rendering should arrive before images far down the page. HTTP/2 lets the browser tell the server what it needs first. The original scheme in RFC 7540, a tree of dependencies and weights, turned out to be complex and was implemented inconsistently, and RFC 9113 deprecated it. A simpler scheme, Extensible Priorities (RFC 9218), uses a `priority` header with an urgency level and is used by HTTP/3 as well.

In practice, how well priorities work depends on the server and CDN. You can help the browser from the page itself: `fetchpriority="high"` on the hero image and `<link rel="preload">` for files discovered late. See [preload, preconnect and prefetch](https://getreport.app/guides/preload-preconnect-prefetch-which-hint-when).

## What happened to HTTP/2 server push

HTTP/2 introduced **server push**: the server could send files the browser had not asked for yet, such as the stylesheet for the page it was returning. The idea was to save a round trip. In practice it rarely helped. Servers pushed files the browser already had in its cache, pushed too much and delayed the HTML itself, and it was hard to configure well.

Chrome disabled HTTP/2 server push by default in 2022 (Chrome 106), and Firefox removed it in 2024. It is not part of HTTP/3 in browsers either. If your server configuration still has `http2_push` or `H2Push` directives, they do nothing useful for most visitors and can be removed.

The replacements do the same job with the browser in control:

- **`<link rel="preload">`** in the HTML or a `Link` header tells the browser to fetch a file early, and it skips the download if the file is cached.
- **`103 Early Hints`** is an informational response the server sends before the real one, containing `Link: <...>; rel=preload` headers, so the browser can start fetching while the server is still building the page. Chrome supports it, and several CDNs can send it for you.

## Which HTTP/1.1 habits to drop on HTTP/2

Many front-end tricks existed only to reduce the number of requests or work around the six-connection limit. On HTTP/2 some become pointless and some harmful:

| HTTP/1.1 habit | On HTTP/2 |
| --- | --- |
| **Domain sharding** (`img1.example.com`, `img2.example.com`) to get more connections | Harmful: extra DNS lookups and handshakes, and the files lose the shared connection. Serve from one host. |
| **Image sprites** | Unnecessary: separate images cost little and cache individually. Use SVG icons or separate files. |
| **Inlining** small CSS and scripts into every page | Only for the critical CSS of the first screen; otherwise separate cached files are better. |
| **One huge bundle** for all JavaScript | Split by page or feature; a change to one part no longer invalidates the whole cache. Keep some bundling, since hundreds of tiny files still have overhead. |
| **Cookie-free domains** for static files | Less important with HPACK; a separate host also costs a connection. |

One HTTP/1.1 rule stays true: fewer bytes beat fewer requests. HTTP/2 does not make a 1.5 MB hero image smaller.

## Does HTTP/2 make a site faster?

It removes waiting, not bytes, so the gain depends on the page. HTTP/2 helps most on pages with many files from the same host (product grids, galleries, pages with dozens of scripts and fonts) and on connections with a long round trip, where saving five handshakes and the queueing is noticeable. On a page with one HTML file, one stylesheet and one image, the difference is small.

It does not help with a slow server, because the time to first byte is the same apart from the handshake, or with large files. For Largest Contentful Paint, it matters most when the hero image or critical CSS was stuck in a queue behind other files.

There is also a security point for anyone running their own server. In October 2023, a denial-of-service technique called HTTP/2 Rapid Reset (CVE-2023-44487) affected most HTTP/2 implementations; nginx, Apache, and the major CDNs released fixes. If you run HTTP/2 on your own server, keep it updated, which is good practice anyway.

## How to check whether your site uses HTTP/2

> **Free tool:** [HTTP/3 test and HTTP/2 check for any website](https://getreport.app/tools/http2-test): Free HTTP/3 test and HTTP/2 check: see which protocol your server negotiates, whether HTTP/3 is advertised, and which files still load over HTTP/1.1.

The test makes a TLS handshake with your server offering `h2` and `http/1.1` through ALPN and records the one the server picks. It then loads the page in Chromium and groups every response by the protocol it actually used, so you also see third-party files, such as fonts or widgets, that still arrive over HTTP/1.1 and bring their own connections.

> **Check: HTTP/2 server support.** Without HTTP/2 the browser opens up to six connections and queues everything else. Turning it on is a server or CDN setting and makes pages with many files load faster with no code change.
>
> 1. Enable HTTP/2 in your web server (nginx 1.25.1+: "http2 on;" in the server block, older: "listen 443 ssl http2"; Apache mod_http2) or put the site behind a CDN that speaks it.
> 2. Check the host's control panel; on Cloudflare, Netlify, Vercel and most managed WordPress hosts it is already on.

> **Check: Every request uses HTTP/2 or HTTP/3.** HTTP/2 and HTTP/3 load many files over one connection at once; HTTP/1.1 queues them six at a time. Switching usually makes a page with many images or scripts noticeably faster with no code change.
>
> 1. Turn on HTTP/2 or HTTP/3 in your hosting or CDN panel; on Cloudflare and most managed hosts it is a checkbox.
> 2. Move assets that are still served over HTTP/1.1 (see the technical detail) to a host that supports HTTP/2.

In your own browser, open developer tools → Network, right-click a column header and add **Protocol**: `h2` is HTTP/2, `http/1.1` is the old protocol and `h3` is HTTP/3. In the waterfall of a page with many files, HTTP/1.1 shows the staircase of queued requests; HTTP/2 shows them starting together.

If the server picks `http/1.1`, [how to enable HTTP/2 and HTTP/3](https://getreport.app/guides/how-to-enable-http2-and-http3) has the settings for nginx, Apache, Caddy, LiteSpeed, Cloudflare and common hosting panels. Behind a CDN, the connection to browsers is the CDN's, so it will usually already be HTTP/2 or HTTP/3 even if your origin speaks HTTP/1.1.

## Common mistakes

- **Expecting a big score jump** on a page with few, large files. Fix the bytes too.
- **Keeping domain sharding** after switching to HTTP/2.
- **Configuring server push** in 2026. Browsers ignore it; use preload or Early Hints.
- **Enabling HTTP/2 on port 80 only.** Browsers use it only over HTTPS.
- **Worrying about HTTP/1.1 behind the CDN.** A proxy or load balancer speaking HTTP/1.1 to your origin is fine, as long as the edge that talks to browsers speaks HTTP/2.

## Questions people ask

### HTTP2 vs HTTP1: which is faster?

HTTP/2, for almost every current website. HTTP/1.1 handles one request per connection at a time, so a page with dozens of scripts, stylesheets and images queues them across up to six connections. HTTP/2 sends them all over one connection at once and compresses repeated headers. The gain is largest for pages with many files and on slow mobile networks; a page with one large image and one script gains little, because the bytes still have to travel.

### What does HTTP/2 multiplexing mean?

Multiplexing means sending many requests and responses over one connection at the same time. HTTP/2 splits each one into small frames tagged with a stream number and interleaves them, so the browser can ask for every file of a page at once and the server can answer in any order. Over HTTP/1.1, each connection handles one request at a time, and browsers queue the rest across up to six connections.

### Is HTTP/2 backwards compatible with HTTP/1.1?

Yes, at the level that matters for a website. HTTP/2 keeps the same methods, URLs, headers, status codes and caching rules, so pages and applications work unchanged. Browsers and servers agree on the version during the TLS handshake, and fall back to HTTP/1.1 when either side does not support HTTP/2. Only the way the messages are encoded and sent on the connection is different.

### Why did browsers remove HTTP/2 server push?

Because it rarely made pages faster and often made them slower. Servers pushed files the browser already had cached, sent too much before the HTML, and were hard to tune. Chrome disabled it in 2022 and Firefox removed it in 2024. Preload links and 103 Early Hints now do the same job, and they let the browser skip files it already has.

### Should I still combine CSS and JavaScript files on HTTP/2?

Only in moderation. On HTTP/2, extra requests are cheap, and smaller files cache better, because changing one part does not force visitors to download everything again. Split large bundles by page or feature, but do not go to hundreds of tiny files, which still add overhead. Keep inlining for the small amount of CSS the first screen needs.

### Is HTTP/1.1 still used?

Yes. Many servers, internal APIs and third-party hosts still use it, and browsers fall back to it whenever HTTP/2 is not available. It is also common between a CDN or load balancer and the origin server, where it works well. For the connection between browsers and your site, though, HTTP/2 or HTTP/3 should be the norm.