Skip to main content
petrk27901450
Inspiring
June 8, 2017
Answered

Optimization and performance best practices

  • June 8, 2017
  • 3 replies
  • 1500 views

I have worked with many different types of assets over the years in the industry, so I am quite confident at optimising images, video and audio for web. However one aspect which I am not very familiar with is how to get the best performance out of Captivate. For example, when I have used 2D and 3D engines in the past there was documentation available on what particular features were performance heavy. For example certain script functions were marked as use only if absolutely necessary, there was guidance on max image file size, max poly count etc

This is only my assumption, but I am guessing that Captivate works in a similar fashion, in that it has a collection of assets and functionality on how these assets work together. It would be very helpful to have some sort of list of things to look at to try to optimize what Captivate does with the assets. For example are certain animations more performance heavier than others, are certain tracking settings heavier than others and so on. I have done some research online but I wasn't able to find this information. Would anyone be willing to help me put such a list together, I have made a start below but I am not sure how accurate it is:

Very Performance Heavy

- Advanced Actions

- Complex animations

- Slide Views reporting

Not so Performance Heavy

- Interaction Data reporting

- Send Resume Data

Not Performance Heavy

- No animations

- Standard Actions

- SendTrackingDataAtEnd Template

This topic has been closed for replies.
Correct answer RodWard

I have not found Advanced Actions to denigrate performance very much, and over the years I have built some very complex interactions. 

In my experience, the biggest performance killers are video and audio, with video being by far the worst.

Many of the other items you mention are more related to reporting interaction to an LMS, and the 'perfomance' issue in that case might simply be server latency from your LMS (as the server is overloaded with requests and takes a long time to respond) rather than being from the Captivate module itself.

Take a look at this blog post on that topic:

How LMS server latency can kill your e-learning | Infosemantics Pty Ltd

3 replies

Known Participant
July 26, 2018

Hey Rod,

Do you have recommendations on the audio file compression that would work in a low bandwidth situation?

RodWard
Community Expert
Community Expert
July 26, 2018

For voiceover audio, I usually record at 128 bit, but set the output quality for the published MP3 to 64 bit.  I never go lower than 64 because I find the audio can start to sound "whooshy" due to the compression.  At 64 bit you don't really notice any degradation.

But your mileage may vary...

Lilybiri
Legend
June 9, 2017

I have been using advanced actions quite a lot as well, but replace them by shared actions whenever possible.

Having to navigate 'far away' a lot of times in a course will slow down performance, rearranging slides or even using popups instead of jumping to a slide far away helps.  Audio clips have to load when entering a slide, avoiding very long audio clips per slide helps as well (split them up over slides). Whenever possible I will replace a bitmap image by SVG (not possible for any image of course).

petrk27901450
Inspiring
June 12, 2017

Hi Lilybiri, sorry what do you mean by "navigating away" in a course? Do you mean linking to external websites or files, or jumping from slide to slide?

Lilybiri
Legend
June 13, 2017

I meant navigation within the Captivate course, where the playhead has to jump over many slides forwards or backwards. Try to avoid that, mostly there are better ways.

RodWard
Community Expert
RodWardCommunity ExpertCorrect answer
Community Expert
June 9, 2017

I have not found Advanced Actions to denigrate performance very much, and over the years I have built some very complex interactions. 

In my experience, the biggest performance killers are video and audio, with video being by far the worst.

Many of the other items you mention are more related to reporting interaction to an LMS, and the 'perfomance' issue in that case might simply be server latency from your LMS (as the server is overloaded with requests and takes a long time to respond) rather than being from the Captivate module itself.

Take a look at this blog post on that topic:

How LMS server latency can kill your e-learning | Infosemantics Pty Ltd

petrk27901450
Inspiring
June 12, 2017

Hi Rod, for the video performance issues, are you referring to video included as an asset or video used from a website such as YouTube? I have also been trying to find the most performant solution for video and I have found tried both inserted video and an embedded YouTube video. In my mind YouTube should work faster since the video is only being referenced and not bundled with the module, but I suppose if the "container" loading the YouTube video is not optimized the loading alone could be a performance killer? Either way I am finding it quite difficult to benchmark the performance differences between the two.

Also, you mentioned that audio and video is loaded when entering the slide. Is it not possible to have assets start preloading in the background some way, for example during the slides that are before the video/audio slides?

RodWard
Community Expert
Community Expert
June 13, 2017

I'm talking about video included as an asset in the course.  When your video is coming from Youtube or some similar streaming service there is very little performance hit from your actual course itself.  The hit comes if the learner has to download the video from your own server before being able to view it.  We refer to that as Progressive Download video.  Streaming video is definitely the better way to go because the streaming server is capable of determining what the end user's available bandwidth is and can usually serve them a video better suited to their actual bandwidth to avoid buffering.

With Flash SWF content it DOES preload in the background as you are playing the slide before it.  This includes graphics, animations, and audio files.  But videos are always externalised and not encapsulated within the SWF, so they're something of a separate case.

With HTML5 content the norm seems to be that each slide's content downloads as you get to that slide.  I think this is done because of the way mobile devices and browsers do not cache content in exactly the same way desktop browsers do.  They don't have the same memory and storage space to play with.