Best Practice for HTTP/2 Front-End Deployments: Part II
This post takes a look at establishing some initial guidelines and workflow that could be used when deploying front-end components to HTTP/2 sites.
Join the DZone community and get the full member experience.Join For Free
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 of more requests as there will be a memory overhead.
building your components
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.
how many requests per page?
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.
it will take some time for clear best practices to emerge around http/2 asset delivery. we hope this article provides you with some groundwork to help get you started.
Published at DZone with permission of Brent Graham. See the original article here.
Opinions expressed by DZone contributors are their own.