Technical Question: How do published courses use bandwidth?

Video files are the largest footprint from a bandwidth standpoint, followed by audio. A quick look at the full file set produced as part of publishing will provide some insight as well. The LMS adds a bit of overhead, but it's quite minimal

When it comes to file size, what matters more -- overall file size of the published ZIP or individual file sizes of the media elements? 

Also, if a course has NO video elements, only images, audio and text, how big is too big for an image? Are images/media elements loaded individually or on a slide-by-slide basis?

I read that a few slides are pre-loaded at once, like a buffering situation, so that indicates it's the whole slide that's being loaded... does the course continue to buffer as you move through it, pre-loading a few slides at a time? 

Hi Ashley,

I happened across your question and pinged our amazing support team who shared this link: https://articulate.com/support/article/how-content-is-preloaded-in-storyline 

The link should help answer your questions about how the content is loaded.

That said, in my experience, there are a number of factors that can influence load times: content (such as images) size, the capability of the server that you're using to host the content, connection speed of the end user, end user's device (desktop vs. tablet), etc. All of these can have an impact. 

In my past work with clients, I've found the hosting environment (LMS and server environment) to be a pretty large factor in performance. When I run into these types of issues, I like to run a comparison by loading the course content to an environment (such as Amazon Web Services) that I know will serve the course up quickly. From there, I can test the course on a variety of devices to see if there's something course specific (such as crazy large images) that is causing hiccups. If so, I can start to adjust accordingly by switching out images, adjusting the compression settings (for audio and images) when publishing, etc. Once it's running smoothly on AWS, I'll start to test on the client environment to check for performance. It's not unusual to have to further compress the content a bit to get it to play smoothly on a client's environment, especially if the client is hosting their own LMS. 

The simplest approach in your situation right now would be to check the compression settings when you go to publish. Typically, you can save a large amount of bandwidth by turning down the audio quality. There's typically not a whole lot of noticeable difference between, say, 96kbps and 64kbps, but you'll save a lot of size. The standard setting is 56kbps, so if you're publishing above that, you've got room to move down.  I'd also test out the image quality settings. Run some trials to dial it back until you start to notice the visual quality taking a hit, and then push it back up just a tad. The standard is 80%, but maybe 70% looks okay. Every little bit will help performance. 

I hope this helps!

Mike

Mike! Thank you for this helpful, thoughtful response!! You've confirmed a lot of what I thought I already knew and your experience with clients echoes some of ours. We always test in the SCORM Cloud and in our own LMS on a number of devices - and since our employees are remote, we have multiple types of internet connections to test on. 

In the situation we're dealing with now, we haven't been able to recreate the issues. And 95% of our clients who receive this course do not have any issues. 

Thanks for the audio info -- I hadn't tested each bitrate to know the difference between them. Right now we're at 64 so glad we have room to go down some more. Also: Should we "optimize audio volume" or nah?

Follow up about the publishing quality: We have tested image quality from 100% down to 10%, and the size of the images in the output folder are the SAME regardless of how you publish them. I'm waiting to hear back from Articulate Tech Support on this issue right now, but I'm wondering if you have any additional insight into this. The client in question is saying the individual images are spiking their bandwidth (the largest is 2.1 mb, most of them falling under 1mb) so we used TinyPng.com to resize all of the images post-publish and drop them back in, so they are all under 500 kb now. And they are still claiming that images are "huge" and causing bandwidth issues. 

I'm trying to best understand what's happening under the hood and how we can help them without literally going in and manually resizing 1000 images (times 8 since they have this course in 8 languages.......*head meet desk*)

Hi Ashley,

I think I see the behind the scenes convo taking place with the support team, so I'll let them handle that piece! But yeah, my understanding is that the images should be compressing to smaller sizes, so hopefully they'll be able to provide guidance there (with your 8000 images! WHOA!).

As for the optimization of the audio, I think it really depends upon the recording dynamics. I tend to record my audio in a tool such as Adobe Audition (Audacity is a nice, free alternative) so I optimize/level it before I bring it into my project. 

I'd say a general rule of thumb is that if the audio has really low levels and/or you've recorded the audio over several different sessions, it's a good idea to level it. But frankly, if you think it currently sounds good, then I wouldn't worry about it as the optimization process will add time to publishing.

Mike

Thanks!! We record and mix all of our audio using Audacity and our audio team is usually pretty good about matching audio when we have to do custom additions. I just wasnt sure if the "optimize" option added anything of value in that case. Thanks for the clarification! 

I appreciate your help and responses!