I recently watched a webinar from NGINX on ‘What’s new in HTTP/2?’. In the webinar they go over how HTTP/2 differs from version 1, and what benefits it has. One of the benefits is that it allows you to use SSL with no performance hit compared to plain HTTP/1.1. The other benefit they go into is that it simplifies your work process. However, I’m not sure this simplification benefit has much truth in it.
With HTTP/2 everything is retrieved in parallel over a single connection. So, in theory this removes the need for domain sharding, commonly used with HTTP/1 sites to maximise the number of connections and so number of parallel downloads that can be made. However, HTTP/2 does nothing to address the question of cookies / state.
So you will still need two domains, a cookie domain and a static domain. Generally this is all I work with anyway – browsers can open 6 (or more) connections per domain. So unless you have a page with lots of small resources that need downloading, then you don’t need to shard more than that on HTTP/1.
Another potential benefit of retrieving everything over a single connection with HTTP/2 is that it removes the need for concatenating files together. This is commonly done with CSS, JS, and sometimes with images (making use of an image sprite). Personally, (and I think this is the same for many other developers), I both minify and concatenate my JS & CSS files as part of a single process. So not having to concatenate files doesn’t make any difference to my workflow, since the minification is still needed.
Where it could have a benefit is if you regularly need to update a single CSS or JS file, while other files remain unchanged. In this case under HTTP/2 without using concatenation, you get all the benefits of concatenation, but only the changed files need be downloaded by the client, assuming they have the other files in the browser cache already. I don’t change my JS / CSS very often, so this is not a benefit for me, but this likely would be a benefit for larger websites that make changes more often.
Inlining CSS / JS was put forward as another HTTP/1 optimisation that is no longer needed under HTTP/2. However, my understanding is that inlining of CSS / JS is generally to ensure it takes effect quickly (before having to finish downloading and parsing a full CSS / JS file), not to minimise requests. If the same inlined CSS and JS was used on every page, then potentially this could be added to small CSS / JS files that are loaded first in the page under HTTP/2. However, it doesn’t really provide any benefit for inlined page specific CSS / JS.
Image sprites may still provide some benefit in terms of reduced file size compared to separate images. So you may want to continue using image sprites even with HTTP/2. Do bear in mind the extra cost of the CSS background offset lines needed with sprites when looking at file size though.
I do hope to implement HTTP/2 now that Let’s Encrypt is live and offering free SSL certificates. However, I think the simplification benefits are greatly overstated, with HTTP/2 making very little difference to the actual workflow needed for the majority of sites.