libs and tutor.js are to big for slow internet connections

[fasib]

They should be minimized and maybe split up to allow better changes on the system?

• [x] gzipped
• [x] cached
• [x] minified
• [ ] dynamically load all the extra libs?
• [ ] download status for the user?

[fasib]

The markdown preprocessors could be loaded only if needed eg. tree-processor dependencies only if it is used.

[LittleHelicase]

I added a ticket for removing ACE in #28

[LittleHelicase]

The biggest markdown processor is by far the dot processor and this is partly due to the fact that it contains another lodash. I added a gulp function to discify the browserify package gulp discify. Sadly it does not work with a separate vendor package (https://github.com/hughsk/disc/issues/41) , thus I created one for all dependencies.

https://rawgit.com/Welfenlab/tutor-student/master/build/tutor.disc.html

I'm a bit confused why we have a browserify dependency in there? I think it is completely unnecessary.

[leMaik]

We could also use service workers to load the libs only once.

[LittleHelicase]

I could reduce the size by about 1.5MB. The packages js-md5 and knockout-bindings both are not made for browserify and contain requires that are not necessary. A clean npm install removed on of the two lodash instances.

I will remove brace in the next step, that is the biggest package for now. Activating the minifier should also bring additional savings.

[LittleHelicase]

I just reduced the size by another 1.3 MB by using a bower ace build (380kb against 1.3MB). I also removed the bower esprima dependency (there were a bower and npm dependency). Downloading all page assets is about 4.3MB now.

There is still potential

• I didn't minify the vendor and tutor package, that will certainly reduce the payload.
• The graphlib-dot dependency puts two separate lodash instances into the browserify package. This would reduce the size by about 300kb.
• The math processor of the markdown engine requires ascii2mathml including babel. This seems a bit much for finding some $$$ in the markdown document. This could save about 160kb.

[LittleHelicase]

We could use http://addyosmani.github.io/basket.js/ to put all the libs into the local storage (after loading the page once, this should speed up the loading time by a lot).

[leMaik]

Or we could use service workers, which are awesome. :D I think that the size of localstorage has a pretty low limit, or am I wrong?

Edit: "The HTML5 spec suggests storage quota with a limit of 5MB for localStorage but browsers can implement their own quota if they wish." (source: http://addyosmani.github.io/basket.js/)

[fasib]

gzip reduced the size by ~68% from ~4.5 MB to ~1.4 MB. Minification should reduce the size by a few more %.

[leMaik]

1.4 MB is pretty good for what we have! :+1: Just checked what difference uglifyjs makes.

	bare .js file	minified	minified + gzipped
tutor.js	418.6 KB	233.3 KB	58.4 KB
vendor.js	2.1 MB	1.1 MB	280.3 KB

Based on these numbers, I'd say that this issue may be closed, as they are no longer too big for slow internet connections.

Edit: @fasib 4.5 MB? What size are we talking about? :open_mouth:

[LittleHelicase]

I measured the whole download size as we have a few bower dependencies and we use a CDN for MathJax. I think he compared it to my measurement, but I don't know if those are comparable...

I mean it is false to say we decreased the package size by moving ace out of the vendor package. We still have to load ace, but it now loads its parts dynamically.

[fasib]

@leMaik yeah I compared it to @LittleHelicase measurement but used the total download size while doing the following:

• first time visiting the site
• login
• select exercise and wait until the tasks are completely loaded

[leMaik]

18.74 seconds before anything is displayed (used Chrome to throttle to DSL (2 Mbps, we're not even using "lifi"!). That's far from perfect, but it can be optimized by locating the script tags at the bottom. The file size (4.6 MB) is okay, but the user needs to see at least that something happens.

The biggest files are: vendor.js > tutor.js > semantic.min.css > highlight.pack.min.js (this should not block loading!) > ace.js > semantic.min.js > jquery.min.js > Mathjax stuff.

[LittleHelicase]

If highlight.pack.min.js could run after it is activated than yes, this could get an async attribute.

Should we display some kind of "Splash Screen"? It is probably better than a white page.

[leMaik]

I'm not talking about the async attribute as this would break many things (i.e. everything that doesn't work without a lib being loaded). I just want to load all libraries after the page has been loaded (and semantic-ui). This way, we could display a splash screen while the rest is loading.

I'll look into this tomorrow, already started moving things to the bottom earlier today.

The splash screen could contain a "nice message", as in Slack. :smile:

[LittleHelicase]

I do think that loading highlight.pack.min.js via async would be rather easy without breaking anything. It is only used to generate the output styling, that could be done after it is loaded. On the other hand, highlight.js is only a few kB in size it probably would not affect the loading time at all.

[leMaik]

It is actually the fourth biggest file and it is about 400 kb. So we should try to load it asynchronously.

[LittleHelicase]

Or we could simply use the JS-only highlight.js version it is only 9,4kB big. Currently we need only JS highlighting. We probably have a version that contains every single language hightlight.js supports.

[leMaik]

You are right, but we also need dot and markdown highlighting.

[LittleHelicase]

I just bundled all the jailed components into one minified file. This not only reduces the inital bandwith costs it also removes the constant downstream due to jailed fetching the iframe and worker code.