HTTP/2 is starting to achieve significant adoption from all angles. This year, with the release of iOS 9 and IE Edge, we've seen all the latest browser versions include support. NGINX has released their support on both their Plus product and the open-source version, so one can only assume Apache will follow suit (in the meantime there is mod_h2).
The wonderful thing is despite the fact your mileage may vary depending upon your visitor's appetite for keeping their browser up-to-date, HTTP/2 operates on a connection upgrade basis, so it retains full backwards-compatibility.
Improvement
On average, websites will see a 30% decrease in load time, without even making changes – this is primarily driven by the inclusion of multiplexing.
If you'd like to see even more improvement, then you'll need to optimise your site for HTTP/2. Unfortunately, many techniques that were applicable to HTTP 1 are counter to HTTP/2, so you may actually have a negative impact on those visitors with older browsers – which is why it's so important to understand your traffic profiles and only make these tweaks when it makes sense to do so.
Techniques that no longer apply
Domain Sharding
HTTP 1 had significant constraints around requests: only 1 request can be made per connection and there are variable limits on how many parallel connections a browser could make to a single hostname, so for asset-heavy websites (such as ecommerce product lists) using multiple hostnames to increase the available connections alleviated the issue.
With HTTP/2 this becomes an anti-pattern, not only due to multiplexing allowing multiple requests over single connections, reducing overhead in creating new connections, but also due to header compression across requests saving us from wasted bandwidth.
Concatenation
To reduce the need for so many connections, or the impact of headers on multiple requests in HTTP 1, the best-practice was to concatenate assets together, whether it be stylesheets, JavaScript files or even images (using spriting) to minimise the total number of requests made.
With HTTP/2 because the overhead has been removed, you can gain caching benefits by keeping assets separate for two reasons:
1) We return to leveraging the browser to only load the needed assets rather than loading in extra data we may not use and may only be used on one small area of your site or application.
2) We gain improved caching. With concatenation, if one asset in a group changes, then the whole group is invalidated, without it, if one asset changes then only that one small component needs reloading.
Changes in implementation
Inlining
Embedding core styles and scripts in HTML is a great means of getting around any delays in the browser parsing responses and creating new connections to download the require assets to render the page, it can also alleviate issues with SPOFs caused by any synchronous external dependencies.
HTTP/2 introduces a new feature called "Server Push" which will greatly simplify this process. When a request is made for your HTML page (or any request, come to think of it), the server can respond with not just the relevant HTML, but any further CSS, JavaScript, images, fonts or whatever else is expected to be required for the page, pre-warming the browser's cache so those assets are local ready for parsing and rendering.
Still important
The above updates are assuming you have a well-optimised site, should be starting from scratch, the following are still important:
- GZIP of text-based content (HTML, JSON, CSS)
- Prevention of FOIT when loading webfonts
- Far-future expiry of static assets, with fingerprinting in-place
- Image optimisation
- Lazy-loading of images below the fold
- Utilising a CDN for low latency
- Load external dependancies asynchronously to prevent SPOFs
