Every time you visit a web page, your browser fetches it by requesting all the assets of the page from a web server. Since the birth of the web, this has mostly been done via HTTP/1.1.
As time has passed, and technology has evolved, and websites have become ever more complex and asset-heavy, the HTTP/1.1 protocol has increasingly come under strain, with a lot of workarounds needed for dealing with performance issues.
Web pages, as we know them today, are often stuffed with resources—such as images, text, fonts, etc.—which make them much heavier than those of the 1990s or even 2000s. Accordingly, it takes more time for them to load, so web designers and developers have come up with nifty workarounds to duck the issue. Still, it has become obvious that there's a need for an update to the HTTP protocol itself.
HTTP/2 will bring some changes to the way pages are delivered to the browser. While ordinary Internet users might not see a big difference, designers and web developers will notice quite some. This article will look at what those changes are, and how they will affect you as a proficient tech user.
How HTTP/1 Works
To fetch the web page you'd like to visit, your browser communicates with the server. They interchange messages—the browser requesting the images, fonts and other resources needed with separate requests, and the server, in its turn, sending them as responses.
As a result, the flood of data through many connections causes congestion, and the page load speed slows down. To overcome the problem of too many requests being sent, and to make the best use of HTTP/1, inventive developers have used inlining, concatenation and image spriting. Fortunately for them, puzzling over the speed of performance will largely be a thing of the past when HTTP/2 comes.
How HTTP/2 Will Work
Your browser will still send requests to a server and get responses with the assets needed for the web page to look as it should, but some nuances in between will change. HTTP/2 brings new features such as multiplexed streams, server push, header compression and binary format—each of which I'll examine in turn.
Multiplexed Streams
Remember the congestions caused by many connections passing the resources such as text, fonts and pictures from the server to your browser? Multiplexing eliminates this problem by making those assets into smaller parts, passing them all via one connection, and then reassembling the resources after they've reached the final destination, the browser.
Server Push
Server push represents a more efficient way to deliver assets to a browser. In an HTTP/1 environment, the HTML page is sent to the browser, the browser has to parse it and decide what assets it might need, then request those assets from the server.
HTTP/2 is more proactive in this regard, sending assets that the browser is likely to need without it having to ask. These assets go to the browser's cache, and are available immediately if and when they're needed, which is a plus for performance.
Header Compression
In HTTP/1, every request sent has a small piece of additional data attached—HTTP headers—that describe how a browser or a server behaves. On average, browsers are able to make about six connections at once, but given that the number of connections needed to load a typical web page can be up around 100, this leaves a lot of data to be retrieved, which takes time and bandwidth.
When an HTTP/2 connection is established, all the headers are packed into one compressed block to be sent as a unity. It gets across faster, and when the transmission is finished, the header block is decoded.
Binary Instead of Textual Format
The textual format has some extra overhead and needs to be refined, while the binary one does not need any parsing. It's also a lot more compact. Additional work of a server means additional time to wait for the web page to be loaded. That is why the binary format, with its being easier to process, is a justified enhancement.
Continue reading %HTTP/2: the Pros, the Cons, and What You Need to Know%
Source: SitePoint