With HTTP/2 soon on the horizon, it's worth taking some time to think about how this will impact your front-end development practices, especially when it comes to deploying assets to production.
According to the IETF HTTP Working Group who maintain the project, HTTP/2 is a replacement for how HTTP is expressed “on the wire". It focusses on the protocol for improving performance - specifically: end-user perceived latency, network and server resource usage.
HTTP/2 is backward compatible with HTTP/1, and while HTTP/2 promises to improve performance significantly, it will require revising parts of how we tend to do things today. For example, many of the HTTP/1 performance techniques such as spriting and file concatenation may make your site slower if you continue to use them after upgrading.
Reducing the number of requests
Lets review some of the common HTTP/1 performance optimisation techniques that are usually rolled into our deployment scripts:
Concatenation and minification — JavaScript and CSS files are normally concatenated together and minified during the build process. Unnecessary characters are removed and smaller files are combined together into one large css and js file.
Spriting — The process of combining all your images into one large file and using the CSS background-position property to only show the relevant part of that image depending on the use case.
Sharding — Creating domains or sub-domains specifically to serve static assets to increase the total number of connections allowed by the browser.
In-lining Assets — Moving critical CSS/JS or images into the HTML file.
The amount of processing required to power all the connections needed to receive and download this information, has only added further performance degradation issues. The good news is that in the new world of HTTP/2 protocols, much of these practices are rendered moot.
Front-end performance with HTTP/2
HTTP/2 drastically reduces the overhead of multiple requests by using multiplexing. It's now possible to send and receive multiple files at the same time over a single connection. This connection can also be left open for re-use over very extended periods of time.
Taking this in to account, file concatenation is therefore no longer a best practice. You may be loading assets that are not required for the page. It forces expensive cache invalidations if only a single line of code has been changed, as browsers are forced to reload the whole file.
Setting up HTTP/2
HTTP/2 requires assets to be delivered over SSL/TLS and for a long time, this hasn't been easy to setup. At Cloud 66 we're hoping to ease this process by introducing a series of useful features. The first stage of this has already happened with the recent integration of LetsEncrypt with Cloud 66.
Another requirement you'll have is to transition to the new protocol by updating your server software. HTTP/2 is available as part of NGINX 1.9.5, and you can find out more details about how to enable it here.
In short, to enable HTTP/2 support, you'll need to add the http2 parameter to all listen directives. Also include the ssl parameter, required because browsers will not support HTTP/2 without encryption:
server {
listen 443 ssl http2 default_server;
ssl_certificate server.crt;
ssl_certificate_key server.key;
...
}
It's worth noting that the “HTTP/2 and SPDY indicator” plug-in's for Chrome and Firefox are useful for testing purposes.
We're actively working to help our customers make this transition as easy as possible with Cloud 66.