HTTP 1.1 was a major move from HTTP 1.0 as it allowed persisted connections(more than one request/response on the same HTTP connection), improved caching, new status code, Enhanced compression support, OPTION method for Cross Origin Resource Sharing in web application and much more.

HTTP/1.1 has served the Web well for more than fifteen years, but its age is starting to show. Loading a Web page is more resource intensive than ever, and loading all of those assets efficiently is difficult, because HTTP practically only allows one outstanding request per TCP connection.

Because of which, many TCP connections are created to issue parallel requests. And since there isn’t any limit on this; too many connections are used most of the times which leads to TCP congestion and unfair resource usage by browsers. It also means lots of duplicate data being transferred “on the wire”.

Also read: How to access the Dark Web using Tor

If too many requests are made, it hurts performance. This has led the industry to a place where it’s considered Best Practice to do things like spriting, data: inlining, domain sharding and concatenation. These hacks are indications of underlying problems in the protocol itself, and cause a number of problems on their own when used.

HTTP/2, on the other hand, enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP’s existing semantics remains unchanged.

At a high level, HTTP/2:

• is binary, instead of textual
• is fully multiplexed, instead of ordered and blocking
• can therefore, use one connection for parallelism
• uses header compression to reduce overhead
• allows servers to “push” responses proactively into client caches

Read more about HTTP/2 here.