[currysausage]

> HTTP2 also uses compression, unlike HTTP1, and so the size of the request is significantly smaller - and thus faster.

Also, an HTTP/1.1 server, when configured properly, will use compression as well.

[jomohke]

It does support compression of the message body, but not of the headers.

They designed a new compression algorithm called HPACK specifically to compress headers in HTTP2: https://http2.github.io/http2-spec/compression.html

In small HTTP/1.1 requests the headers can be much larger than the content, which is part of the motivation for combining files into one request.

[Illniyar]

Considering the best practice for HTTP/1.1 is to create few very large files - why would compressing headers really make a difference?

[rakoo]

HTTP/2.0 does not only compress headers, it also keeps a context of headers that were already sent. So if you want to include a specific header with the same value in multiple requests (like, say, a cookie), it won't actually be re-sent on the wire. The other side will know that the value hasn't changed.

[sp332]

"Best practice" can take a lot of work and often doesn't happen in real life. HTTP/2 gets you this advantage for free.

[MichaelGG]

If the headers are big enough, then you may need multiple packets to transmit the request.

Also, some TCP stacks (or an extension option?) will allow data in the first packet, so you don't have to wait for the handshake. Perhaps this doesn't work if the data doesn't fit in a single packet?

[michaelmior]

Aside from the other responses to this comments, this goes towards making HTTP2 requests cheap which enables a lot of other optimizations that were antipatterns under HTTP/1.1

[fideloper]

The body, but not the headers, right?

Does http2 also compress headers?

[treve]

It does