HTTP2 support

Idle musing prompted by http://pca.st/p47h :

What would be the best webpack configuration for fast HTTP2 loading? Simply put each processed file in a separate chunk? Maybe provide loading hints for images?

It would be nice to have two builds, serving the HTTP2 build when appropriate…

Author: Fantashit

6 thoughts on “HTTP2 support

  1. I want webpack to allow turning off concatenation and being able to spit out all the files that have been referenced by a single page as simple script referenes. This is what makes sense to me in a HTTP 2.0 world.

  2. It’s on the roadmap… The plan is:

    • automatically split the bundle into many chunks (i. e. by module age)
    • emit a push manifest for module assets
  3. Ok I’ve got an experimental version of it:

    https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-splitting

    You need to do the following:

    • add new webpack.optimize.AggressiveSplittingPlugin()
    • use [chunkhash] in the filenames
    • add multiple script tags to the HTML page (see stats.entrypoints["main"] for a list)
    • use records to store chunk/module ids and the splittings
    • This is production only, don’t use it in development

    It then generates a HTTP2 optimized version.

    Advantages:

    • It allows to cache parts for the application (without 304)
    • It loads parts for the application in parallel
    • Still allow to uglify and gzip effectively

    Disadvantages:

    • It causes more requests for non HTTP2 clients
    • You need infrastructure to keep the records
    • It could make builds slower
  4. Right now the webpack default approach is “bundling” and exceptions to that use terms like “splitting”. To me this sounds philosophically reverse of a future HTTP2 approach where the default should be not bundling. In most cases I don’t want to “split my bundles” – I want no bundling as default and to optionally bundle. Can webpack support this reverse preference/philosophy?

  5. @rarkins brought a very good point here.

    For static assets, when it comes to HTTP2, we like caching and multiplexing; when it comes to bundler, we like the composition to hide the detail. I want to lay some groundwork by sharing our practice first.

    In our practice, we like both. We use webpack as an emitter to get those packed files. We use HTTP2 as a transporter to get packed file to user browser. Not only this, we also want it lives with a package manager doom(we choice bower at no bias as it does the job). The emitted packed files from webpack only contain the implementation code and the stuffs not shareable. Reference to the dependencies are preserved with webpack externals and declared in the bower.json.

    When comes to the integration application, as an organization, we want all shareable package be shared in all products via a CDN. We have a publish service to publish all bower component to CDN server. All publish files are versioned and cached by maxAge:bignumber. In browser, we use a loader to download the main files by package name and add the bootstrap/configuration code as a callback. With the help of HTTP2 and CDN, the transporter did a great job.
    As a plan B, the loader is pluggable, application developer could live with the old grunt/gulp pack workflow as well, only to generate a different index.html which contains the packed bundles(vendor.js, helper.js, app.js).

    This has been validated as a pretty smooth workflow in new app building. The shortcoming is, it can not be easily added to existing aged application. In enterprise, it is hard to promote as you have to make all peer teams agree. Most of it become to sociological problems.

    Back to webpack here, I think we could control webpack-dev-server suspend before bundling work and emit the packed sub application chunk to memfs only. Reference to the dependencies are preserved with webpack externals, and be served from node_modules/bower_components. Then in prod mode, memfs and the static files will be replaced with a CDN publish service.

    It is more enterprise workflow specific and not as general as webpack’s work here. But this solves some problem brought by bundle and the practice could be extended to production practice as well in a HTTP2 user case.

    ps: I love @sokra ‘s work a lot and I am a huge webpack fan.

Comments are closed.