Automatic compression
At HTTP 1.1 we enable GZIP to compress the information we send in our responses. A good practice that needs to be explicitly enabled. In HTTP 2 GZIP is standard and required.
Only changing headers are re-sent
In HTTP 1.1 headers are sent to Plain text, on each request (the famous User-Agent
for example). In HTTP 2 headers are binary and compressed, decreasing the volume of data. In addition, it is possible to reuse headers for the following requests. That way, we only have to send the headers that change. This reduces requests and makes them less bulky.
Parallelization of requests
For every feature a page has, a request then made to load them faster we need to parallelize those requests. The problem is that HTTP 1.1 is a sequential protocol, we can only do 1 request at a time. The solution is to open more than one connection at the same time, parallelizing requests in 4 to 8 requests (that’s the limit we have). A common way to handle this is to use multiple hostnames on the page (pag.com and img.pag.com), thus gaining more parallel connections.
In HTTP 2 requests and replies are automatically parallel on a single connection. It’s called multiplexing.
Prioritization of requests
An interesting optimization is to facilitate initial rendering, prioritizing the resources needed for the user to see the page first (CSS) and interact (JS) after.
In HTTP 2 we can indicate which requests are most important through numerical prioritization. So the browser can give high priority to a CSS file in the head that blocks rendering, and lower priority to an asynchronous JS at the bottom of the page.
Server Push
A common gambit in HTTP 1.1 is to inline resources for faster initial rendering. The big problem here is that we cancel the browser cache. CSS next to HTML cannot be cached independently.
Here comes Server Push in HTML 2. The idea is to have the server send some resources to the browser without it having requested it yet. The server "pushes" into the browser resources that it knows will be requested soon. So when the browser needs the resource, it will already be cached and will not make a request.
Security
A while ago there was a discussion whether HTTP 2 would allow use without SSL (I stopped following for some time), but in practice only secure HTTPS connections will be supported. Thus we have security and privacy more established with the protocol.
Finally, I recommend the episode of Hipsters.Tech. about HTTP2, will give you even more information on the subject
I liked the answer. You can explain this part a little better: "By the way, only the changing headers are re-sent, we no longer have that excess of information sending all the headers again."?
– Jéf Bueno
Sure, I’ll edit that part of the answer to make it more complete :)
– Juliano Alves