By Nilson Jacques

File Bundling and HTTP/2: Rethinking Best Practices

By Nilson Jacques

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!

  • Dirk Federmann

    “when to switch to HTTP/2?”
    As soon as possible and reasonable.
    If there is an old browser that doesnt support it then the server will fallback to HTTP/1.1

    Unfortunately a lot of hoster dont want to make the switch to HTTP/2

    • Nilson Jacques

      Yes, you’re right – what I should have said was that when you decide to optimize your code for HTTP/2 will depend on your audience.

    • Rasmus Schultz

      I don’t understand why anyone still cares what hosting companies support. Anyone can afford a cloud VM these days, even the most humble clients – I don’t know why hosting companies still dictate these things? Go nuts, install PHP 7, run PostgreSQL, heck, build and run C code on your VM if it suits you! We’re living in the future! :-)

    • Iolo

      Yes but sometimes these fallbacks and polyfills in technology also come at a cost to older users rather than maintaining business as usual. If the majority of your customers are on HTTP/1.1 clients then they may have a very noticeable dip in the speed of service if you start serving lots of files vs. fewer bundled resources.

      It’s about progressive enhancement vs graceful degradation. It’s too soon for many to start degrading the HTTP/1.1 client experience as it won’t be that graceful in certain circumstances.

  • Stephen Cunliffe

    Bundling JS files has always been an issue and I’d argue against the statement that this is the current trend. While bundling a few core files together that every page of your app needs is worthwhile bundling everything on a page has horrible cache-ability as every page needs a new unique bundle.

  • brgrz

    The article says IIS supports HTTP/2 which is not yet true. IIS will only start to support HTTP/2 in Windows Server 2016 which due Sept 2016.

    • Nilson Jacques

      IIS on Windows 10 has had support for HTTP/2 since the technical preview:

      • brgrz

        That’s true but no one is running Windows 10 webservers.

        • Rashaun Stovall

          That’s FALSE. Get out of your bubble.

Get the latest in JavaScript, once a week, for free.