Why has hls.js output bytesize grown 45% going from 0.14.x to 1.x?

[mreinstein]

Hey folks,

I'm not trying to sound aggressive in this issue, just genuinely curious if this is a known issue, or an unintended consequence.

When minifying the latest 0.14 build from npm with terser, the output is 252kb. updating to 1.02 and rebuilding, it's 366kb.

I know with gzip it will be quite a bit smaller, but this still represents a pretty big size inflation overall. Why is there so much more code in the new major? Is there a way to do a custom build at least? I'm really just trying to stream some .m3u8 files with basic .vtt support.

Again, please don't take this as antagonistic. I appreciate all the work that's gone into this project, it's great.

I'd like to fight bit rot and ensure I'm on the latest version but I can't move off of 0.14 without understanding what's going on.

[robwalch]

Conversion to TypeScript (Ex:_ runtime changes made to ensure type safety for nullables) and new features increased the build output. There is room for optimization via babel and webpack (updating minifier to strip multiline comments added by webpack), but that's only going to strip a small percentage of the current size.

[mreinstein]

Thanks for the update Rob, definitely helpful. 👍

[robwalch]

@mreinstein np. I have a few more thoughts to add.

Is there a way to do a custom build at least?

There is a 'light' build. For v1.0 that will also be larger than the previous version and excludes features you need.

From the README

NOTE: hls.light.*.js dist files do not include EME, subtitles, or alternate-audio support.
In addition, the following types are not available in the light build:

AudioStreamController
AudioTrackController
CuesInterface
EMEController
SubtitleStreamController
SubtitleTrackController
TimelineController

We could look at ways (contributions or PRs) to customize the light output, or you could use light and add subs/cues/timeline back in via the config.

For v1.0, LL-HLS and progressive loading were the headliners and were not modularized as they are core to HLS parsing and streaming.

I'd like to fight bit rot

Me too! And I could use all the help I can get 💪! Performance is still high on my list, but library size is only a small part of that. Taking a look at the size changes and minified code and ways to improve would be welcome contributions and help everyone using hls.js. I'd like to keep this issue open for a bit and invite everyone to add their feedback and suggestions as well as submit PRs against this issue to see if we can identify and address some of the bloat in the current code base and production output.

[robwalch]

I think the light version is not very usable in its current state. My preference would be for it to have captions/subs and audio track support, but not include DRM support (eme-controller), the cap-level-controller, and the fps-controller (which isn't used by default anyway).

[mreinstein]

yeah that would be pretty amazing. Might be even smaller than hls@0.14 :)

we run hls.js on a metric fuck tonne of websites (formal unit of measurement,) millions of page loads per day. Big opportunity to make things faster, cheaper and reduce video load delay with a change like this.

[mreinstein]

hate to be a pest but any love for this task? We have many millions of hls.js active users daily and we can't justify the increased network payload. I'd love to get up to the latest version though. We're stuck on 0.14.x for now :'(

[robwalch]

Hi @mreinstein,

This does not look like something actively being worked on.

The light build is an example of how you can tailor the build features and thus size to your specific needs. Open issues like #2910, related to build output, could use contributions from interested users like yourself.

The player is only going to get larger as more features are added. There are some incremental changes and improvements that could shave off bytes here and there. In general, expect the payload to increase as support for more codecs, content protection, and HLS features are added.

If you find duplicate code or issues with how the library is bundled please file a new issue pointing out where improvements can be made.

[mreinstein]

I don't know why you had to close the issue; that basically sweeps it under the rug. Just because there's no current plan for this doesn't mean it's not worth tracking.

[mreinstein]

The player is only going to get larger as more features are added.

To be honest that's kind of a disappointing and bleak way of looking at software development. To not even try to make things load efficiently on the web is tantamount to giving up.

[robwalch]

Bundle size is important and worthy of on-going effort. This issue though is a question which has been answered. My intention is only to encourage you file new issues focused on actionable changes, taking cues some of the direction and answers provided above.