Paths.js file is huge

Feb 13, 2018

Hi,

I've been investigating very long (sometimes fatal) load times in my HTML5 only published version of a course and think I've tracked the culprit down to the paths.js file - it's over 5MB for me. While the browser is downloading the file it holds up other parts of the preload. In one test it took over 40s which was apparently enough to cause a timeout which blocked anything else from loading, apart from the player frame.

Anyone got any bright ideas?

Thanks,

Matt

24 Replies
Matt Stafford-Clack

Hi Matthew,

Thanks for your reply - you sent me off down a little rabbit hole of testing and I'm not sure it's actually the animation element that's at the root of my issues - please bear with me on the below, it's far more for my benefit (laying out my logic) than it is for yours!

I extracted just a single, not particularly busy, slide from my course and started playing around with it - removing any animation and the like - and found some very interesting results. The original slide generated a paths.js of 40KB on it's own, so multiply that up by the 100-odd slides in my course and bingo there's your massive file.

However, removing the entrance and exit animations still generated a 40KB paths file. As did removing all "motion" (i.e. everything is on the slide from the start and stays there).

What did significantly change that paths file size was applying a blank layout - that knocked it down to 21KB!

When I replaced the majority of the objects (text, images, shapes etc.) on my existing layout with a single image the paths file stayed at 21KB.

When I added a layer to the template (as I do in the real course) it popped it back up to 32KB.

So the size of that paths file appears to be related to the number of discrete objects in the course and not their behaviour. I need to do a bit more testing on the impact of the template on multiple slides though.

Remains to be seen what size I need to get that file down to not break browsers but at least there's light at the end of the tunnel that definitely isn't a train.

Cheers for the inspiration!

Matt

Matt Stafford-Clack

Right, testing complete. I was right it wasn't a train at the end of the tunnel: it was a massive line of trucks and I've just been squished by a never-ending succession of 16-wheelers.

Paths.js file grows by ~10KB per layer used in the course. I have 540-odd layers, hence the size, and hence my course is utterly unusable in HTML5 without a complete redesign and rebuild.

I have a broad and wide-ranging education and I've still run out of expletives.

Matt

Matt Stafford-Clack

Update from the pit of despair: perhaps it's not layers, as such (though no doubt it contributes a bit). 

I can change the paths.js file size by a couple of KB just by changing how many lines the same volume of text goes across! Seems each line of text generates a new entry in the paths.js file, the increase in filesize for that new line being proportionate to the amount of characters in that line  (e.g. 5 lines of 10 words each increases the filesize by 1KB over 5 lines of one word each).

I've got a lot of long lines of text in my course so still up the creek without a paddle, but someone else might be able to learn from my mistake.

What a fun learning experience this is proving to be.

 

Matt Stafford-Clack

Might be a combo of things I guess - lots and lots of text, spread amongst lots of layers, increases the relative increase due to each line of text?

If the increase is related to the amount of text then I've made a rod for my own back - each slide is narrated and has a transcript layer with the full text of the audio file(s) for that slide. Would effectively double the size of my paths.js based on what I'm seeing.

Will try uninstalling and reinstalling, though I'm on SL3 rather than SL360.

Matt Stafford-Clack

Me too!

Just out of interest/desperation I took a relatively text heavy slide with a transcript layer. Published in its original build it had a 54KB paths file. When I replaced all the text objects with images of the same text (copy the text object, rather than the text, to powerpoint and back again) it dropped the paths file to 31KB! Text was still readable so I've got me a very ugly brute force option if necessary.

I also went through and removed every transcript layer in the original course and reduced the paths.js file from 5.5Mb to 3.2MB. So I can always make my course ugly and less user-friendly as a fix.

I really, really, really hope there's a technical solution for this!

Matt

Matt Stafford-Clack

Hi Matthew. I don't suppose you could help me out with a quick test could you? Create a brand new project, slap 20 or so lines of text on a slide, publish as above and send me the paths.js file?

I want to compare how your Storyline install is handling the creation of the contents of the file, just in case the bibbytest story file was already knackered by having been created in my environment.

If you don't have time I completely understand though.

Cheers

Matt

Matt Stafford-Clack

That's really helpful Matthew, thanks for doing all that testing. Some really interesting results there!

A bit of playing myself and it looks like it's anything that's unique needs a separate bit of code? So when a slide is an exact duplicate of another it adds nothing (or a relatively trivial amount) to that file, but when there is any characteristic that makes something different (font colour or font type) it gets a new entry in full. This seems to extend to shapes as well - 5 boxes of the same colour added nothing, changed the fill colours of 3 of them and the file went up considerably.

I guess that makes sense: anything completely reusable gets one reference in full, and then presumably shortcuts to it elsewhere; anything unique needs the full entry. Since there are going to be almost no exact matches amongst the text contents in my course it's stuffed to the gills with unique references - and all the additional characters in the code that comes with them being text.

So I'm actually lucky that I'm using pretty much the same font type and size throughout the course otherwise who knows how big that paths file might have got to!

Matt Stafford-Clack

Ditto, I love a good technical mystery. Though I'd rather it wasn't happening in the context of my course not working. :)

I'm now working on the assumption that the hugeness of the paths file isn't something I can materially affect with my current build so now I'm going sneaky: seeing if I can chop the file into chunks to greatly increase the download speed but still have it execute properly.

Will update this thread if I get anywhere

Matt Stafford-Clack

Well this is annoying - I think I've found where all the fiddles need to be made but no idea how to implement them.

There's a bit in app.min.js which seems to initiate the call for paths.js.

v=i.extend({url:n.resolveDataUrl("paths")

When I amend the "paths" value to e.g. "paths1" it did successfully retrieve paths1.js instead of paths.js so yay: progress! Unfortunately for me it's surrounded by a dense forest of code that I lack the knowledge to unpick. So I don't know if it's as simple as e.g. finding the appropriate points above and below that fragment and then copy & pasting that chunk 15 times for "paths2", "paths3" etc.; or could you chuck a couple of wildcards in there; or if there's some clever "for each" code you could drop in.

I also lack the knowledge to know if that's even possible starting from here, which might be an issue of course.

Matt

Matt Stafford-Clack

Hi Laurie,

Nothing so far I'm afraid, still under investigation. In the end I had to "optimise" the course myself, switching blocks of text (anything that ran over to two or more lines basically) out for high-res images of the same text.

Effectively (as far as the paths.js file is concerned) any one picture is the equivalent of any one line of text. Sounds mad but it worked to drop the paths.js file to a size (<3MB) that can be downloaded and processed reasonably quickly, even though it ballooned the total file size.

Matt

Matt Stafford-Clack

Hi Matthew,

Oh it's a sub-optimal fix all right, no argument there! Only one available to me in the time I had unfortunately. Future edits will be a bit harder than they should be but I've made sure to keep text files of the original blocks wherever retyping would be a significant burden, and it's actually not too onerous going that way.

Fortunately (re the accessibility point) the majority of my text was already transcripts for audio narration (the build predates the handy stuff like captioning in SL3) otherwise I wouldn't have entertained it as a possible fix. Good point though for any readers:

Laurie I definitely wouldn't recommend this approach if you don't have a high degree of fondness for right-clicking and sub-menus!

Matt

This discussion is closed. You can start a new discussion or contact Articulate Support.