Summary: <br> Podcast media (whether audio or video) must live somewhere on the Internet so it can be downloaded via RSS feeds. This hosting needs to be powerful enough to deliver the media files quickly and handle the load of hundreds or thousands of simultaneous downloads when new episodes are released. Here are the performance results from the most popular podcast hosting companies.<br> <br> <br> <br> Does podcast hosting speed even matter?<br> <br> <br> <br> The short answer is yes, but only to a point.<br> <br> <br> <br> I started this project curious about feed-hosting performance between separate web hosting providers (shared, managed, and VPS), different caching options, and mirroring tools (<a href="http://feedburner.com">FeedBurner</a> and <a href="http://podcastmirror.com">Podcast Mirror</a>). Aside from two specific exceptions (more on that below), feed performance from numerous providers was acceptably fast. While one host might be faster than another, it was faster by less than a second on feeds that were already loading in under 1 second.<br> <br> <br> <br> So as long as a feed loads within 1 or 2 seconds, exact speeds become a moot point. If, however, a feed takes several seconds or longer to load, that increases the possibility of timeouts, which can result in a podcast app's failure to refresh podcast RSS feeds to even see what new episodes are available to download. I've seen this happen before where one podcast app could download all the episode, but another app wouldn't refresh the feed.<br> <br> <br> <br> And then, I realized my test could be easily adapted to measure and compare file-hosting speeds. So I turned my attention to media files, which were easier to compare and possibly more important to measure.<br> <br> <br> <br> But as with feeds, media hosting across most of the providers was fast enough that it wouldn't cause any noticeable difference.<br> <br> <br> <br> A feed and media host is fast enough when someone can press a button and start listening with little to no delay.<br> <br> <br> <br> (Podcasters can make the mistake of attaching large images to ID3 tags, which can cause playback delays because the ID3 information must download before audio data.)<br> <br> <br> <br> It's also important to remember most podcast apps will check feeds and download new episodes automatically in the background. So even if it took five minutes for an episode to download, most of the audience might not be affected because the episode will be there waiting for them when they open their podcast app.<br> <br> <br> <br> This audience-helping benefit is a big reason we need to keep downloading possible in podcasting, instead of catering to money-focused advertisers who want to kill the download and switch to streaming. But that's a different discussion.<br> <br> <br> <br> Testing methodology<br> <br> <br> <br> You're free to skip this part if you don't want the technical details.<br> <br> <br> <br> I wrote a program in Node to measure the time it takes to download a feed or media file from a given URL. I included options to test feeds with Gzip compression or HTTP/2. <a href="https://github.com/theDanielJLewis/podcast-speed-test">You can view my Podcast Speed Test source code and try it on your own computer or server</a>.<br> <br> <br> <br> Each feed or media URL was tested 10 consecutive times and then combined into average and median results. If there was a significantly different average from median, I would re-run the test, except in the case of Podiant. Every first one or two tests of Podiant resulted in very slow download times. I suspect Podiant doesn't propagate a media file to local servers until it is first requested from that location, and thus the first download is slow. Because this was predictable and repeatable, I left the data in (reflected on averages) and I think it's concerning for that poor ...
