File Bundling and HTTP/2: Rethinking Best Practices

This is the editorial from our latest JavaScript newsletter, subscribe here

Almost all JavaScript applications these days will utilize a build process. Even if you’re not transpiling from ES2015 or TypeScript, running some sort of concatenation and minification processes on your code has become standard practice. The reason for this is that making an HTTP request involves quite a bit of overhead. Serving fewer, larger files works out more efficient than many smaller ones. With the adoption of the next version of the web’s underlying protocol, HTTP/2, it may be time to rethink best practices.

HTTP/2 is based on Google’s SPDY protocol, which was developed to improve on page load latency and improve security over the existing HTTP 1.1 standard. Work on the new protocol began in 2012, with the first development version being a direct copy of SPDY. The finalized standard was published in May 2015, and on May of this year, Google announced that they would no longer support SPDY in Chrome.

How is HTTP/2 different from its predecessor? One major difference is that HTTP/2 is a binary protocol, not text-based. This allows it to be more compact, efficient to parse, and less prone to errors. One of the key advantages of the protocol is that it is multiplexed, meaning that multiple files can be transferred on a single connection. Another touted feature is Server Push, which allows the server to transfer resources to the client before they’re requested, pre-filling the cache.

Support for the new protocol is pretty good, including all the major browsers. Server-side, Apache2, Nginx and Microsoft IIS all support it, along with Node.js version 5.0 and above. Most of the browser vendors have stated that they will only be supporting HTTP/2 over TLS connections, although with the advent of Let’s Encrypt providing free SSL certificates, that’s an easy requirement to meet. According to figures collected by W3Techs in June of this year, around 8.4% of the top 10 million websites now support the new protocol. If you’re a Chrome user, you can use the HTTP/2 and SPDY indicator extension to tell you at a glance which of the sites you visit are served via HTTP/2.

What does the adoption of HTTP/2 mean for JavaScript developers? Our current practice of concatenating multiple files into bundles makes it difficult for the browser to effectively cache our code: changing a single line of code in one module requires the whole bundled file to be re-downloaded. As HTTP/2’s multiplexing makes requests relatively inexpensive, we can opt to split our code into smaller bundles and make better use of caching to ensure our apps are making efficient use of users’ bandwidth.

But if requests are cheap, surely we should just forego bundling altogether? This seems to make sense at first glance, but the cost of HTTP requests is not the only factor to consider. Web servers also have limits on how efficiently they can serve large numbers of files. As the JavaScript community has moved towards a proliferation of smaller, more focused modules, serving these files to the client without some sort of bundling would be less than ideal. On top of that, combining files together allows for better compression, saving bandwidth.

So, when should you think about making the switch to HTTP/2? The answer is, it depends. Although browser support is very good, if your target audience is still stuck on older versions of IE then you’re out of luck, so do check your visitor stats to see if this is something that’s likely to benefit the majority of your users. What I take away from all this is that support and adoption of the new protocol are surprisingly far along and, as developers, this is a trend we cannot afford to ignore.

What sort of bundling strategy do you employ? Are you thinking of making the switch to HTTP/2, or maybe you already have? Let me know in the comments!