Hls.js: Reduce Library Size

[johnBartos]

The Hlsjs library is becoming quite large and continues to grow. New features are important, but library size contributes to the overall perception of player speed (larger library === longer download time === slower player setup). I believe that we should be strategic about what new features are merged so that we grow Hls.js at a sustainable rate.

We should evaluate our build process and identify areas in need of optimization. For example:

• Upgrading to Webpack3
  * Rollup Mode
  * Tree Shaking
• Reduction in Webpack boilerplate
• Code splitting

Furthermore, we should refactor and write new code to increase modularization. Modularization allows the core library to remain small while clients who need specific features are able to easily add them. Examples of modularization include:

• Codecs
• Demuxers
• Captions

A code contribution guideline would also go a long way towards slowing the player size crawl. These guidelines would help contributors avoid writing code which cannot be optimized.

• Strings (cannot be minified)
• Classes (lots of webpack boilerplate)
• Avoiding expensive polyfills

I have a lot of experience with optimization (especially on the build size); I'll write my findings here.

[mangui]

great initiative @johnBartos
interesting read on bundlers : https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/
I agree that we definitely need to investigate other options :

• WebPack (refer to @dighan work https://github.com/video-dev/hls.js/pull/1100)
• Rollup
• ...

then regarding codecs / demuxers, definitely yes : they need to move to hls config. (passing demuxer/remuxer code to the webworker makes it non trivial ... but maybe a new bundler could help us here ?)
and maybe the config should be provided as a separate bundle :

• hls.core.js
• hls.fullconfig.js

• hls.lightconfig.js

  we might also split the config in several bundles :

• demux/remux config
• subtitle config
• altaudio config
  
  
  
  • ...
  
  

we could still bundle everything in hls.js for backward compatibility ...

ideas / help welcome !

[mangui]

regexp based mangling could also help a bit
https://github.com/mishoo/UglifyJS2#cli-mangling-property-names---mangle-props
uglifyjs example.js -c -m --mangle-props regex=/_$/
we just need to ensure we have an underscore on private variable.

[michaelcunningham19]

Perhaps the new feature of Webpack 3 "Scope Hoisting" can be utilized here, I can't find any official documentation for it just yet, other than this blog post: https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b

[johnBartos]

@mangui Interesting, I haven't heard of that option. I believe there's a way to do this with Rollup (not sure about webpack), and I know the Closure compiler does this.

@michaelcunningham19 Yeah scope hoisting (aka Rollup mode) is key. Huge reduction in boilerplate.

I believe the first step here is to carry the Webpack PR over the line https://github.com/video-dev/hls.js/pull/944. Webpack will hopefully a) reduce the build size itself and b) reduce the build size with advanced features, to be enabled in the future. However, I don't think we'll get much benefit from tree shaking in the current state - we don't really use libraries or have dead code. It is very nice for wildcard imports though (and there could be refactoring around files such as events to export singular constants which, when wildcard imported, are included as-needed as opposed to wholesale).

With webpack3 I'm not sure of the benefits of Rollup but it could be an option. I'm much more experience with Webpack though.

[dighan]

Hey ! I've just opened https://github.com/video-dev/hls.js/pull/1238. It uses Webpack 2 to start. Feel free to comment :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ffxsam]

@mangui @johnBartos @dighan

Hey guys, any plans/progress on this? I was getting warnings during the build process about my bundle size, and, well.. 😅

[lhsazevedo]

@ffxsam Use the minified version hls.min.js or the light version hls.light.min.js.