The above highlights also suggest a reduction in the overall time cost associated with the SSL/TLS ‘handshake’ process.

I wont dive into the specifics of how this has been designed, suffice to say, if you want the gory details then I recommend you read the specification document here: /http2-spec SSL/TLS HTTP/2 supports the concept of ‘weighting’ each ‘stream’ (see “Persistent Connections” above for details of what a stream is). Prioritizationīecause all connections are multiplexed into a single connection, we need a way to prioritize certain requests over others in order to ensure the fastest possible overall response. This also means we should be less concerned about having to serve static assets from a cookie-less domain, which was a problem because the size of the static resources would all become larger due to cookie data being associated with them. It’ll now be compressed, making it smaller and the responses subsequently quicker to receive (although admittedly this is only a marginal gain). Header information will no longer be sent over the wire in plaintext format. Just to be clear: this is a very good performance boost and facilitates the ability to transfer lots of resources in a much more efficient manner than HTTP/1.x Header Compression This simply means that multiple resources can be loaded in parallel over a single connection. This also avoids the user downloading assets for a page that they will never visit. This also means that the browser is able to more precisely cache resources as there is no need to have to bundle all your static assets together. concatenating css/js: combining multiples stylesheets or javascript files into a single file to reduce multiple connections to the server.image spriting: combining multiple images into one to reduce multiple connections to the server.domain sharding: a way to side step the problem of browsers only being able to parallelize a limited number of connections to the same domain.This removes the need for previous ‘performance’ techniques such as: A stream is effectively a two way channel, so information flows up and down it and a single connection will be able to manage as many streams as necessary. With HTTP/2 the situation is improved by utilising a single connection which supports the concept of a ‘stream’. If you had three images on a page then that would be three separate connections. When using HTTP/1.x each resource your web page specified would need its own connection. If you’re unfamiliar with it, then let me spend a brief few moments discussing some of the highlights. This is a super quick post for demonstrating how to utilise the new HTTP/2 protocol.

Nginx enable http2