Page MenuHomePhabricator

VideoJS needs to be lazy-loaded on click before we can release it by default
Open, HighPublic0 Story Points


mw.inspect size report


0"""818.2 KiB"8378601
1"oojs-ui-core""165.9 KiB"1698322
2"jquery""147.0 KiB"150554


0"""818.2 KiB"8378601
1"jquery""147.0 KiB"150554

Oh dear.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 17 2019, 8:48 PM
TheDJ added a subscriber: TheDJ.Jul 23 2019, 7:17 PM

so initially we chose this route, to make sure we had full HTML5 fallback.. The technology of lazy loading is somewhat incompatible with html5 fallback content as the controls are always presented.. you can add lots of logic on top to hide the native player and everything, but what if someone already started native html5 playback before your 'lazy load' logic start overlaying it ?

It also causes problems for parsoid serialization, having to know multiple forms of dom representation for the same content and additional overhead.
We should not forget that the old module was once lazy loaded, because RL modules were present on ALL pages, whether they had video or not and had to look at the DOM of a page to figure that out..

I think we should however also look at the size of video.js RL module. We are currently including the full dist version, incl webvtt parser and presentation fallback for platforms that do not support webvtt, Dash and HLS handling, Cea608 handling, mux.js, several components we don't use etc etc..

by handcrafting our own bundle using webpack and packagefiles, we could probably significantly reduce the file initial payload size. I set off doing this at the hackathon, but then got horribly stuck inside trying to lazy load ogvjs into that and got so frustrated that I think i lost the patch/branch i was working on.

TheDJ added a comment.Jul 23 2019, 7:26 PM

Found that experiment back:

Not fun. We have 4 ecosystems that need to communicate (videojs, videojs plugins, mediawiki and ogvjs ), using respectively: cjs+rollup, <whatever the plugin author wanted to use>, package modules+webpack, and umd+webpack

and then we need lazyloading working on top of that...

brion added a subscriber: brion.Jul 29 2019, 9:46 PM

We can probably reduce the size for now by using the video.js core distribution (without the http-streaming component which we don't use yet) and using more aggressive minification (rather than using our own minifier, which doesn't shorted variable names and such).

As for lazy loading, worst case we can use some kind of click handler I think to display our pretty icon and catch events and then load up the rest of bits, even with a native <video> element showing its poster image. Will experiment with this later if you don't get to it first. :)

Change 529819 had a related patch set uploaded (by Brion VIBBER; owner: Brion VIBBER):
[mediawiki/extensions/TimedMediaHandler@master] WIP Reducing size of video.js payload

brion added a comment.Aug 12 2019, 6:32 PM

Patch switches to the core distribution (no http-streaming component) and the more aggressively pre-minified version. Not quite complete, as this means we can't patch in the text track lazy-loading on top as easily.

Should either get that pushed upstream or make a work fork we build from, or both.

Quick fly-by note from talking about this with @Ladsgroup at the hackathon....

... it looks to me like the old Kaltura-based player is not lazy-loaded either. As such, if we can assert that the full videojs payload is smaller than the full Kaltura + jqueryUI payload, then this does not need to block enabling of TMH-videojs in production by default.

I noticed this when inspecting the performance of articles like which load all of jqueryUI, apparently due to the anthem audio-clip queuing the TMH-kaltura player unconditionally (not lazy-loaded).

TheDJ added a comment.EditedAug 14 2019, 8:31 AM

old Kaltura player is not lazy loaded if you use audio-only or videos over $wgMinimumVideoPlayerSize

brion added a comment.Aug 14 2019, 2:22 PM

For a video that triggers player setup but hasn't actually been played, in Chrome/Firefox where no ogv.js shim is needed, they seem to weigh in (as reported from mw.inspect, so uncompressed) at around 293 KiB for MwEmbed+jquery.ui and 288 KiB for video.js with the core.min.js variant.

Note MwEmbed also has a 13 KiB sprite PNG for icons (none of them hi-DPI), while video.js uses a scalable icon font embedded in the CSS for the widgets.

We could possibly trim it down further by lazy-loading the subtitle rendering component, but that's less of a big deal.

We still have the issue that use of very small video embeds currently doesn't load the player until popup while this will pre-load the player components, so total usage may go up (but any use of an audio player already engages it, so eh)

Yeah, I think on the whole, I'd be okay with video.js going ahead as-is (from a perf perspective). With lazy-loading being something we'll get to later (as soon as possible, but not blocking).

brion added a comment.Aug 14 2019, 2:51 PM

Great, I'll tidy up this patch in a bit (once I get the subtitle lazy-loading patched back in) and we'll worry about lazy-loading later.