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.
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
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.
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
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.
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