Set up Adobe Captivate e-learning to mimimize load on Learning Management Systems

If you're an Adobe Captivate e-learning developer, there's more than a 50% chance you're also delivering your e-learning courses via some kind of Learning Management System (LMS for short).  If so, sooner or later you'll encounter an issue where course participants complain about the content "freezing up" or pausing repeatedly during playback.

This issue is usually caused by LMS server latency. In mild cases it can just be annoying. In serious cases it can completely cripple your e-learning project.

If you haven't already done so, I recommend you read this other blog post first to understand what server latency is all about and how it can impact e-learning. Once you understand the issue better, come back and finish this post to learn about the countermeasures you can use to address it in Adobe Captivate.

Minimize the number of file requests

As mentioned in the post explaining LMS server latency, the greater the number of separate files there are in your course, the more requests will be sent to your LMS server to download them.  

Choose HTM/SWF if at all possible

Since SWF output packages any number of content objects inside a single wrapper file, opting to use HTM/SWF as your default e-learning delivery format can greatly reduce load on your LMS because it only usually involves a handful of file requests including a single SWF file per course module, regardless of how many hundreds or thousands of objects that SWF may contain.

So if your target audience has the option of using their desktop PC or laptop to consume your course content, choosing to deliver HTM/SWF instead of HTML5 could be a wise move (even aside from all the other issues you would thereby avoid).

However, if you are forced to go with HTML5 output for at least some users (because they can only access your content via non-Flash enabled mobile devices) then you could use the option in Captivate to output BOTH SWF as well as HTML5.   Captivate creates both outputs with a multiscreen.html file that will redirect users to one output or the other depending on what kind of device they are using to access the content.

Since HTML5 output is still showing quite a lot of limitations compared to HTM/SWF, it makes little sense to me to force all course participants to use it, especially when it will also place a greater overall burden on your LMS server.

Use HTML5 as a last resort

If for some reason you MUST go with HTML5, then at least reduce the number of file requests by minimizing the number of images, and other small objects in the course content.  For example, rather than having a large number of separate images on a slide, can you just assemble these images in a graphics editor, save as a single graphic, and use that as a slide background instead?

Minimize data requests by modifying Quiz Settings

If you're suffering with serious LMS server latency issues, the number of files in your ourse is not likely to be the biggest culprit.  You should probably be looking at reducing the number of data requests.  Server latency issues often turn out to be related to the number of times your Captivate content is pinging the LMS server to tell it about the course participant's interaction with the content.

So what can you do about that?  Fortunately quite a bit!

For the purpose of this tutorial we're assuming you're using a SCORM-compliant LMS because this gives you the largest number of options for reducing server load. (Choosing any of the non-SCORM reporting solutions in Captivate cuts out most of the options we discuss below.)

All of the options that allow you to reduce LMS server load are found on the Quiz > Reporting dialog.  We'll start at the top of the dialog and work our way down, discussing each option you can use.

Use the SendTrackingDataAtEnd Template

When you choose SCORM as your LMS standard, Captivate assigns a default template full of code designed to communicate with the LMS.  However, the default template uses Captivate's normal 'verbose' communication method, which deluges the LMS with tons of information.

However, you can opt to use a different Template by selecting one from the dropdown list. The best one for reducing LMS load is called SendTrackingDataAtEnd. (The screenshot below is from Cp 7x, but all versions from Cp5 onward have a similar drop-down to select the SCORM code template.)  

How is this template better? Well, instead of sending tracking data to the LMS all the time while the participant is interacting with your course, this template stores the information and only sends it to the LMS when the user exits the course module.  That means one request to the server instead of dozens.

This single change is likely to have the biggest positive impact on server latency issues. If you want to test whether or not changes to your content will fix your server latency issue, perform this one change and test the output on your server.  If this has little noticeable impact, I doubt whether any of the other changes below will make a difference either.  Your server is probably toast.

(By the way, if you have experienced SCORM programmers on your staff, you also have the option of creating a custom template and adding this to the relevant sub folder in the Templates folder of the Captivate install directory under Program Files.  But don't attempt this unless you REALLY know what you're doing.)

Report quiz results only, not slide views

Let's be honest.  How often do you REALLY need to track what percentage of the slides were viewed by the course participant?  In most courses the key result that everyone is interested in is whether or not the participant passed or failed the quiz.  

So, unless you have a compelling requirement to track slide views, I recommend you turn off this option by deselecting the relevant Slide Views boxes on the Quiz Preferences screen as shown in the example screenshot below.

Since the number of content slides in a module usually far outnumber the quiz slides, not tracking slide visits will further reduce the data sent to the LMS server.

Don't report Interaction Data

Further down on the Quiz Reporting dialog you will find the section that determines Data to Report to the LMS.  This option is selected by default.  Deselect it, as shown below, to further reduce load on the server.

In Cp5x versions the option to turn off reporting of interaction data looks a little different on the Quiz Preferences dialog.  You select the option to Report Score instead of Interactions and Score (as shown below).

LMS Advanced Settings (a.k.a LMS Customization Settings)

This dialog is reached via buttons near the bottom of the Quiz > Reporting dialog.  In Captivate 6 and 7 the button is just called Advanced (as shown in the screenshot above) and when clicked it opens a dialog like the one shown below from Cp 7.0.1.

The two important options here for reducing server load are:

  • Send Data On Every Slide - This option is selected by default. Deselect it if you want to prevent Captivate from pinging the LMS every time the user advances from one slide to another. (Please note that only Cp7 or later versions have this option.)
  • Never Send Resume Data - This option is deselected by default. Select this option to prevent Captivate from sending data to the LMS about which slide the participant is currently on. (Please note that Resume Data allows the LMS to 'bookmark' the specific slide the course participant was viewing at the time they exited the module. So selecting this option will disable LMS bookmarking.  You would only do this if bookmarking was deemed far less important than reducing server latency.)

In earlier Cp 5 and Cp 5.5 the button on the Quiz > Settings dialog is called LMS Customization Settings (as shown in the other screenshot above) and the smaller dialog it opens looks like that shown below.  You will notice that you only have half as many options as found in the Cp 7.0.1 version dialog shown above.  The only one that will help your latency issue is the one indicated by the arrow; Never Send Resume Data. (But please note again that this will disable LMS bookmarking.)

How many of these these countermeasures should you use?

Well that depends entirely on how bad your server latency issue happens to be. Only you and your IT department are really able to answer that question.  If you're not currently suffering with noticeable server latency issues (as indicated by course participants complaining about the content freezing up for no apparent reason), you probably won't need to enact any of the countermeasures outlined above.

Another factor to weigh up is that all configuration options in Captivate have advantages and disadvantages. Each thing you turn on or off will have an impact somewhere else in your content.  For example, if your e-learning modules are quite long and most users do not complete them in a single session, having Resume Data bookmarking might be deemed more essential than the small amount of extra server load it imposes.

So, you need to weigh the pros and cons before making a final decision. And the only way to evaluate the pros and cons is by making changes and then testing to verify the resulting differences in server load.

Last resort: Upgrade your server technology!

At the end of the day, if your server technology is outdated or inadequate, none of the measures suggested above may ever be enough to fix "the issue".  You could end up just chasing your tail spending hours, days or weeks modifying your courses when the best solution might simply be to lobby your management for budget to buy the level of hardware infrastructure your organization really needs to cope with the amount of learning you need to deliver over the next 5-10 years.

What worked for you?

If the suggestions outlined above prove useful to you, please add a comment below indicating which ones you found to be most effective.  

Conversely, if you've found yet another way to reduce server latency in your organization, I'm all ears.  Drop me a line using the Contact form on this site.


I just started using Moodle LMS and would have struggled through a long frustrating learning curve with out your tips on Quiz settings. I would also like to plug your Infosemantics_Troubleshooting_Captivate_6x_7x Guide. This is a must have resource if you are using Captivate.

Thanks for sharing so much of your knowledge freely in the education community.
Greetings from Marquete, MI


Rod Ward's picture

Thanks for the compliments Joe.  Glad to see that all the work I put into this site and my e-books is helping someone out.  Gives me the incentive to keep going.

Rod... you hit the nail on the head with this post! One of the most overlooked aspects to deploying an eLearning solution is whether or not the existing LMS server(s) can handle the anticipated load.

A "Distributed" Denial Of Service attack (DDOS attack) pretty much does the same thing... flood your server with requests until it becomes unresponsive and crashes. As chatty as Captivate can be, if you have enough users trying to take a course, they can effectively take down the server in the same exact fashion as a DDOS attack. I really wish the Adobe Captivate development team would consider issues like this. Not every company can afford top-of-the-line server hardware.

Jim Leichliter

Rod Ward's picture

 Jim..I hadn't excactly thought of Captivate's verbose communications as amounting to a DDOS attack on the LMS, but I guess from the LMS's point of view, that's what it feels like.  Well said!

Hi Jim,

Is server latency the problem when my video project on the LMS needs to buffer? I have a project containing 5 mp4 videos (2-3 minutes long) and it seems to play ok if the user doesnt do anything. But as soon as he misses something, and wants to go back either using the slider or the "rewind 5 seconds button" I created, the project starts buffering pretty badly. Do you have any tips? The videos have already been created so lowering the bit rate or resolution is out of the question...
The next option I will try is inserting the videos as "streaming" videos rather than the "progressive download" default. I think the LMS would need a plug-in for that to work, and I am not sure what that entails, but that might work...
I have also tried inserting the videos as event videos as well as distribuing the videos over several slides. I havent tested these thoroughly, but at first glance, they didnt solve the problem. Thanks for any help!!

Rod Ward's picture

You may be talking about two totally different issues here.
Server latency is most commonly associated wtih courses that have lots of little files, each of which needs to be individually requested and downloaded from the server.  
Conversely, if your course basically consists of several large videos, and you are experiencing BUFFERING issues, that's a very different animal. Your most likely culprit is simply the end-user's bandwidth not being big enough to cope with the size or setup of the video file.
You mention that you're NOT using STREAMING servers, which adjust the download according to your end-user's bandwidth so as to minimise delay in playback and buffering. With the PROGRESSIVE DOWNLOAD method the server basically assumes you did the math and set up the video encoding so that playback can begin after a short buffer.  If that doesn't prove to be so, and your end-user's bandwidth is insufficient, repetitive buffering will occur.
After your end user has downloaded and cached the entire video file, the next time they launch it playback could start quite quickly and proceed without buffering...provided there are no settings that prevent caching of the video file.  However, if your end user interrupts the initial progressive download (by scrubbing the playback bar) you could find that the server simply restarts the video download again...with more buffering.
My suggestion is, tell the users NOT to scrub that bar.

Hi Rod (Sorry for calling you Jim),

Thanks for the tips. It sounds like streaming then, if possible would be a good thing to try. I thought what you described, though, is called "dynamic streaming", and very few servers have the capability to do that? Anyway I will try it...

Actually, I just realized with Adobe Media Encoder, I can change the bitrate,etc. The bit rate on the videos is already fairly low -- about 1.5 Mbps, so I dont think that is the issue...

Regarding the bandwidth problem, is the OVERALL size of the video a problem, or simply the resolution and bitrate?

---> the "reply" button on your blog in the bottom right hand corner of the posts isnt not working correctly, at least for me.

Sorry -- Another question just occured to me. Like I said, I am thinking about reinserting the videos into Captivate as "streaming" and then somehow making that work with my customer's LMS. In order for that to work, however, does the server the LMS is hosted on need to be a "streaming server" or do all servers have this ability?

Rod Ward's picture

The physical dimensions of the video have a lot to do with how many bits are required to encode it and therefore how much bandwidth is required to transmit it. I would be suggesting that you try to reduce the physical dimension (height and width in pixels) of your video as much as possible.  The other part of the consideration is the encoding quality. You should be encoding at the lowest bitrate that still shows acceptable clarity.  1.5 megabits is still quite high.  Probably too high unless ALL of your end users are on very high bandwidth.  Are you certain of that?
Your end user's ACTUAL bandwidth might still be a lot less than you (or they) think because they're usually sharing the available bandwidth with lots of other users and this significantly reduces their pipe size.  (There are websites where you can go to test your current bandwidth at the user end.  Can be quite revealing.)  Remember that anytime your encoded bandwidth exceeds the end user's ACTUAL available bandwidth you will end up with at least some buffering.
Yes.  If you specify Streaming as the video type in Captivate, then it's expecting that the server where your video is coming from will be a streaming server.  It's unlikely that the server on which your LMS is sitting will be a streaming server.  Ask your LMS admin to check, but I've not seen this happen at all in practice.

Thanks Rod.

I will assume the server is a standard web server and the settings within Captivate (progressive download, streaming, Adobe...) are just a way for you to optimize the eLearning for that particular type of training.

I'll try lowering the bit-rate of each of the videos with Adobe Media Encoder.

Two questions:

  • We know that using the slider disrupts the download process (if the browser is not finished downloading). Does any navigation whatsoever also disrupt the download process? eg - use of the TOC to jump to the next chapter, or "my button" to allow the user to jump back five seconds if he didnt understand something?
  • Is there a way to prevent the user from starting the eLearning before it has completed downloading? If so, the entire eLearning would be cached when he/she starts and we wouldn't have this problem...
  • Thanks again.

Rod Ward's picture

 I haven't actually run any experiments to find out what results from navigating away from a slide on which you have embedded a slide video, but my suspicion is that it would indeed interrupt the download.  Your button jumping back 5 seconds would also probably throw a spanner in the download.  The server would not be expecting such an action.
Captivate doesn't offer a lot of options for controlling a video download.  You can try setting the project preloader to 100%, but my gut feeling is that this preloader is more applicable to the SWF content rather than any MP4 videos linked to it.
I'm afraid you'll just need to experiment.  Let us know if you get it sorted. 

Hi Rod,

Is the overall file size relavant? For example, if I have an hour eLearning made of 10 videos, and all of the videos have a 1Mbps bitrate and the overall all dimensions of each video are small, does it matter how big the overall all file size of the SCORM packet is? Let's say this makes the eLearning 400MB in size...

Rod Ward's picture

 Overall file size of the entire project just affects how long the entire project would take to download and be viewed by the participant.  It doesn't necessarily affect how long it would take for the user to at least start seeing SOME content after they click to launch the course.  
With web content (which SCORM courses are) coming from a web server (which is what an LMS is) each individual file that makes up the course gets requested separately from the server.  It doesn't try to download all files at once, or only play content once every single file has been downloaded.
So if you have a project with 10 videos, they will be downloaded one by one from the server.  Hopefully your user will still be viewing the first one by the time the next one they need has finished downloading in the background and they will only be delayed while waiting for the first one.  (This is the way it' works for SWF output. But there is some evidence that HTML5 output on some devices doesn't follow this rule and videos are ONLY downloaded when the user explicitly initiates play on them.)
You as the designer of the course need to plan your initial slides, and the content on them, very carefully so as to minimise the amount of time before a learner will start viewing the content.  So it's usually a bad idea to put videos on these early slides...even small videos.

Thanks Rod. This has all been very enlightening. I think a pretest in the beginning before the user gets to the video could be a way around this problem. The idea being that while he spends time mulling over the questtions, the videos in the course will be downloading in the background. On the other hand, he will probably have problems if he does not complete the video portion of the course and returns to it later picking up where he left off. In tnis case he would begin immediately with the videos again.

Also, I assume beginning with the videos would not be a problem for the user at all if his bandwidth is higher than the bitrate of the videos.

Thanks for your insane amount of help!!! (By the way, I have your troubleshooting guide, which has also saved me in the past.)

Theo1974's picture

Has anyone ever compiled all of the various fixes to this problem? After months of being lucky with videos (I guess) now it seems no matter what I do, CP8.1 published videos HTM/SWF give that Connection Error/Loading error in a small black cross in the center of the screen. I know I have not tried everything, in part because I do not know what everything is. I am working on a very video capture intense course on how to use a software tool via a company website. This should be easy but I have been stalled for over a week. Please HELP. The forums are depressing because all to often when I find a kindred post it is tagged Not Answered (this is something I hate about the forums - far too many dead ends that just waste time) Any help will be greatly appreciated. I have even tried bringing them into CP9, and starting from scratch in CP9 and I still get this error. Previews fine, in browser previews fine. Play the videos outside of a Captivate course = fine. Folks, please HELP I am getting creamed by this issue.


Join more than 2500 other Adobe Captivate users just like yourself and receive regular troubleshooting tips, illustrated tutorials, technical information, and creative solutions to real-world e-learning development issues. (See an example here.) Click the button below to join our community.  It's completely FREE!