How to reduce fIle size of published folder (especially CPM.js)? (Captivate 9, repsonsive project / HTML5, Win 8.1, 64bit, V. 9.0.0.230)

[christiand58840139]

Hi there,

I recently published my first responsive project (for devices, 60 Slides) and was surprised by the enormous size of its output folder: 55 MB ! After a bit of digging I found that the file "CPM.js" located in "assets/js" with nearly 38 MB is the main cause of the problem ...   I'm pretty new to Captivate - but a js-file of that size surely can't be right (and definitely not fit for the web)?

Apart from that the contents of the "dr"-folder confuse me a bit: I used SVGs throughout the project whenever possible - but the folder contains heaps of duplicates / identical images in PNG-format ... images which are identical in dimension and used on multiple slides throughout the project. I suspect this happened when I simply copy-pasted image-objects or whole slides in Captivate - apparently Captivate created a separate copy for each usage of an image and saved it under a different name instead of referencing the same image again and again - even if the dimensions of the copied image didn't change at all? That's major bullcrap of course (unless those png's were created as fallback images in case a browser doesn't support svg-rendering? ), since it requires an unnecessary extra request from the user's client for each occurrence of the duplicate images and prevents the effective usage of the client's browser cache ....   

Any suggestions on how to reduce the file size of the generated output (especially the size of CPM.js) & prevent captivate from creating unnecessary image-dublicates?

[dowbright]

I worry about this all the time. I too am trying to make everything as quickly loadable as possible, though have nowhere near your depth of understanding of the various files.

Any responses will be gratefully incorporated into my workflow!

[RodWard]

CPM.js is the file that stores information about where everything lives in your Captivate module.  The bigger your Captivate module, the bigger CPM.js will grow accordingly.  If you want to reduce the size of CPM.js, make your module smaller and use less objects.  End of Story.

Captivate's responsive output does have extra duplicates of images to cover situations where certain devices or browsers would not work.  These only get requested for download if the JS code "sniffs" out that the device being used to consume the content would require it.  So you're not necessarily being penalized.

If you're creating content for mobile devices, ESPECIALLY when talking about Responsive projects, you have to STOP thinking as if you're still dealing with a desktop environment where the browser can plug requested content into a virtually limitless cache folder.  That's NOT how things work in the mobile device world.  If their browsers have a cache, it's woefully small.  So most mobile devices will request the same files again and again rather than clog up the cache and crash the browser.

And since most devices have very little RAM memory to spare, they do not allow web browsers to use up much of it at all.  So the larger you make your e-learning modules, the more likely you are to overload that small allocation of available RAM and once you DO, the browser will likely just crash.  In a typical multimedia e-learning course this can happen within just a few slides. 

So make EVERYTHING you build in HTML5 VERY short, VERY light, and VERY uncomplicated if you want to avoid issues. 

For best results, you have to start seeing HTML5 mobile learning as working within a VERY limited environment, like trying to build a house on shifting sand.  If you do not build accordingly, you're heading for disaster and will be VERY disappointed with the results.

(Did you notice how I'm trying to emphasize VERY...)

[dowbright]

So build my concepts bit by bit, rather than in a longer format. Makes sense and will do. Thanks!

[dowbright]

Love your info on reducing quiz size.

My LMS, though, uses TinCan, not SCORM. I went through the settings, and wondered, RodWard‌, if you've got any advice on this.

You're a gem.

[RodWard]

I've never used TinCan so far for any project.  I build courses for clients and none of them have so far been remotely interested in using TinCan.  In fact I don't think any, except for one that uses SCORM Cloud, would even have an LMS capable of using it.

So I cannot really give advice about TinCan.  Sorry.

[christiand58840139]

Thank you for your response & the time that you've invested to clarify the specifics of development for mobile devices! (And yeah - I DID notice how you emphasized VERY 😉 - and ESPECIALLY and NOT and DO and STOP .... )

The first thing I did was decoupling my project into multiple small modules, which I intended anyway to make those available as "chapters" via a navigation provided by a starter- / main-project... Since this alone didn't result in an overall significant smaller publishing output, I investigated every used object as well in order to find out what's the main cause for the size of CPM.js etc. I simply couldn't imagine that a file this size is the result of the usage of a couple of objects - my project simply isn't that complex and has a manageable set of objects, which are mostly just repeated on every slide (same dimensions & positions)  ....

So I played around a bit - those are my "findings": Especially the usage of SVGs seem to bloat the CPM.js (& the dr-folder) - I found that out by swapping SVGs with PNGs - et voilá: the size of CPM.js decreased significantly - on an example mini-mini-project of 3 slides this resulted in a decrease of nearly 19 % by simply swapping 3 SVGs with PNGs - and as I swapped all SVGs with PNGs it decreased even further...

And what's more: Effects, that I had applied to various smart shapes, suddenly run smooth & as expected - which they didn't before at all (In the last couple of weeks I spend frackin HOURS to figure out how to get the desired behavior out of Captivate-effects by playing with timing, size, position etc.and could't find a solid solution - the behavior in Captivate differed COMPLETELY from the behavior in previews or when published - the effects simply behaved randomly / unpredictable - in my "desperation" I was on the verge of enrolling for a creative cloud membership just to get hands on Adobe Edge Animate in hope this way I could produce the simple "animations" that I needed for my course intro and import them into Captivate...)

A little surprised by my "success" & to rule out, that my findings weren't just project-specific, I investigated the matter further... I was curious to see how big the impact of SVG-usage on the published output of an "bigger" project is - in comparison to the usage of PNGs.

First I created a new responsive project with 48 identical slides, each containing just the same 2 PNGs, ca. 250 KB & 350 KB in size, no effects or backgrounds etc. applied, identical dimensions and position on each slide...

Result after publishing: 

- Size of published folder in total: 2,13 MB

- dr-Folder:  444 KB

- CPM.js: 816 KB

For comparison: A new responsive project with 1 empty slide:

> Size of published folder in total: ca. 1,87 MB

> dr-Folder: 359 KB

> CPM.js: 654 KB

Not that much of a difference...

Then I did the same with the SVG-versions of the same images -  i.e. 48 identical slides, each containing just the same 2 SVGs, ca. 6 KB & 61 KB in size etc....

Result after publishing: 

- Size of published folder in total: 8,45 MB

- dr-Folder:  3,62 MB

- CPM.js: 3,92 MB

Holy cow!

It seems that each usage of an SVG effects the size of our lovely CPM.js a lot more than the usage of PNGs - so the usage of less objects isn't the only way to reduce the size of CPM.js - it obviously matters as well which objects are used - and SVGs don't seem to be a good choice at the moment for responsive Captivate-projects, no matter what are their supposed benefits ....

Plus: SVG-usage bloats the dr-folder like hell: Instead of just 2 PNGs for all occurrences of the PNG-image-objects in the project (like in "Example A")  - with SVGs you get 48 identical copies of the same image. i.e. 98 copies in total for just 2 images - and this adds up quickly to 3,62 MB - yay.

I can't imagine that this is the intended behavior for a web environment where every KB counts. And even when I'm not being penalized because the images are downloaded over and over again anyway due to small caches (at least in an handheld-environment) I assume this could become a problem once I decide too publish my stuff as an App - i.e. when the whole output is packaged to be downloaded and installed on the user's device, no matter if he needs all contents of the dr-folder or not ? (the Question mark is due to the fact that I got indeed no clue at all when it comes to Apps for devices  - yet 😉  )

I let you guys know which results I get once I've swapped all SVGs with PNGs in my complete project  ...  

Cheers!

[mattt4664448]

I am having a very similar issue. I'm using Captivate 8 to create branching scenarios to deploy on a custom LMS designed to have gaming elements (leader boards, achievements, etc.). The newest scenario that i created has 42 slides, extensive user variables, and advanced actions. There is no narration in this file. The Adobe Captivate Project file is 10 MB. However when I publish as SWF/HTML5 the file balloons to 58 MB. We've isolated the files growth to the dr file (41.8 MB). This week I've spent a lot of time reading on strategies to optimize files (Thanks Rod for this:  How to set up Adobe Captivate e-learning to mimimize load on Learning Management Systems | Infoseman...).

We create the slide graphics in Illustrator to keep the number of items on the slide to a minimum. Those Illustrator files are saved as .jpg and imported to the Captivate library. From the library we put the image on the slide. Then we overlay navigation and text onto the slide. When published, they are converted from jpg to .png. This is the primary growth in the dr file size. From my understanding it seems that most people do not use .jpg for compression reasons. The  project is 1280 by 720.

Is there anyway to avoid the huge climb in size? Should I start with .png images? Should we create the whole slide, including text, in Illustrator to decrease the number of items on the slide?

Any help or suggestions on reducing the published files size would be much appreciated.

[Sankaram]

Hi Christian Daum,

       Thanks for reporting it. SVGs usage creating pngs in the published folder is a bug and we are fixing it.

Thanks,

Sankaram.

[dowbright]

Will we be told when it's solved, and we can begin to use SVGs?

Thanks.

[Sankaram]

HI Paula,

        Sure we will fix in the next update.

Thanks,

Sankaram.