In the first article, we did a quick overview of some of the performance improvements in HTTP/2 and the implications this will have on the way we deploy assets to production. This post will delve a little deeper and attempt to establish some initial guidelines and workflow that could be used when deploying front-end components to HTTP/2 sites.
To try out these techniques you may want to Install NGINX and HTTP/2 in your local dev environment.
Request and Response Multiplexing
HTTP/2 supports multiplexing — Multiple requests and responses can simultaneously use the same connections. There is no longer a big performance benefit to be gained from compiling all of your individual CSS and JS files into two large application.css and application.js files.
By avoiding concatenation we can potentially make the browser cache work more efficiently, one small change no longer needs to invalidate the whole cache.
HTTP requests are much cheaper in the world of HTTP/2 — Although requests may be cheap they are not completely free. In practice, this means that you can probably forget about image spriting and make about ten times more requests per page. However, it's not wise to make hundreds more requests as there will be a memory overhead.
With this in mind, how might we structure a typical template?
This approach should work for small to medium sites. HTTP/2 multiplexing can handle the requests for each component efficiently and by avoiding file concatenation local browser caching will be more effective.
Once we get to around 50 requests we'll need to look into a new concatenation and bundling strategy. We can start to concatenate files into groups of related assets. This way when we make a change, only the localized group of assets is affected while other non-related assets can remain cached locally by the browser.
For example we could create one bundle per NPM module or bundle all CSS common layout components together. For those of you using webpack there is a plugin (http2-aggressive-splitting) that can help with this task.
Another thing to bear in mind is that compression is usually more efficient in a few larger files than many small files.