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.

Does podcast hosting speed even matter?

The short answer is yes, but only to a point.

I started this project curious about feed-hosting performance between separate web hosting providers (shared, managed, and VPS), different caching options, and mirroring tools (FeedBurner and Podcast Mirror). 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.

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.

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.

But as with feeds, media hosting across most of the providers was fast enough that it wouldn't cause any noticeable difference.

A feed and media host is fast enough when someone can press a button and start listening with little to no delay.

(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.)

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.

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.

Testing methodology

You're free to skip this part if you don't want the technical details.

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. You can view my Podcast Speed Test source code and try it on your own computer or server.

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 first soul who must download from their local server more slowly than the next person.

Using Vultr as my VPS provider, I tested from sixteen regions:

• Atlanta, Georgia, USA
• New York/New Jersey, USA
• Chicago, Illinois, USA
• Dallas, Texas, USA
• Los Angeles, California, USA
• Miami, Florida, USA
• Seattle, Washington, USA
• Silicon Valley, California, USA
• Toronto, Ontario, Canada
• Amsterdam, the Netherlands
• Paris, Italy, France
• Frankfurt, Germany
• London, England, United Kingdom
• Tokyo, Japan
• Singapore
• Sydney, New South Wales, Australia

Each region has a high-speed network connection of multiple gigabits per second.

Feed testing specifics

Podcast RSS feeds can be difficult to test and compare because each feed-generator (WordPress with PowerPress, Libsyn, Buzzsprout, Spreaker, etc.) may do things differently. And it wasn't reasonable to try replicating a complete RSS feed across every tool. Some tools may include extra tags for every episode, while other tools omit such tags. Some tools may truncate the show notes, while other tools publish full show notes.

Instead, my method was to find a small feed (100–250 KB) and a large feed (2 MB or more) from each generator, mirror those feeds to a benchmark host, and then compare the performance against that consistent benchmark. I chose FeedBurner and Podcast Mirror, but FeedBurner can't handle feeds larger than 1 MB, so I used it for only small and medium feeds. A third option I could have used would have been to copy the RSS feed code to my own server, but I stuck with Podcast Mirror because it's something anyone can use. This kind of mirroring resulted in only a 1–2 KB difference in feed size, but gave me a relative standard. After 10 consecutive tests, a sample feed's median result would be ranked based on its performance factor compared to the feed on Podcast Mirror as the benchmark. Thus, each feed would be above or below 1.0 compared to the Podcast Mirror benchmark.

Media testing specifics

Media hosting was much easier to test than feed hosted. I used the 1-hour MP3 from episode 229 of The Audacity to Podcast. That file was 44.1 KHz, mono, 16-bit, 64 kbps, giving me a 27.5 MB file. I uploaded that to every media host I reasonably could, and ran the same download tests.

Unfortunately, some media hosts re-encoded my file, changing the file size, and thus making the measurements a little unfair, but I included them nonetheless and indicate the file sizes in the charts.

Try your own tests!

If you're comfortable installing and running Node from a command line, you can download my Podcast Speed Test source code to run on your own computer or server. Use at your own risk, and some of my sample tests may be removed or broken by the time you test.

Feed performance results

Because of the complicated nature of testing feeds (described above), I didn't run as many tests, because I realized it was mostly a moot point with nearly every feed provider loading feeds (which are usually smaller than 1 MB) in a fraction of a second. So for the sake of brevity, I'll omit all that data for now.

But there were two important exceptions.

SoundCloud feeds were consistently the slowest, taking seconds to load a small feed, and longer to load larger feeds. Because of this, I recommend never using a SoundCloud RSS feed. If you must use SoundCloud for podcast hosting (they're a really bad podcast-hosting provider), mirror your feed through Blubrry's free Podcast Mirror service or even use FeedBurner (but I still don't recommend FeedBurner's features, like SmartCast).

Uncached feeds were as bad as SoundCloud. Sometimes slower, sometimes faster. Such feeds were usually powered by WordPress or another content-management system. But all it took to fix that performance was simple caching. With caching, it's important to check that the podcast feed is being cached with whatever caching option you're using. For example, caching plugins like WP Rocket and WP Super Cache allow custom inclusions and exclusions, usually defaulting to include the RSS feeds. But other caching plugins might not offer such options, or might not refresh all the caches when you publish a new episode, or might exclude the RSS feeds altogether (SpinupWP's page caching excluded the feeds, but Liquid Web and Flywheel included the feeds).

So the takeaways here are:

1. Don't use Soundcloud (for hosting your feed, or if you do, then use Podcast Mirror).
2. If you generate your feed with WordPress, implement proper caching or use Podcast Mirror.
3. Any poorly performing feed could be improved by switching to Podcast Mirror.

Podcast media performance results

For hosting my sample MP3 file, I tested:

• Amazon S3*
• Anchor, which uses Cloudfront
• Archive.org*
• Audioboom (re-encoded to 55.6 MB)
• Blubrry
• Bunny CDN*
• Buzzsprout
• Captivate
• Castos
• Fireside
• iVoox
• Libsyn
• Omny Studio (thanks to Adam Jaffrey from Wavelength Creative)
• Pinecast (thanks to Dave Jackson from School of Podcasting)
• Pippa
• Podbean Unlimited Audio
• Podbean Unlimited Plus
• Podbean Business Basic
• Podcast.co
• Podiant (re-encoded to 41.2 MB)
• Podigee (re-encoded to 35.7 MB)
• Podmio, which uses Amazon S3 (thanks to Podrick Scuadrick from PodScure)
• podOmatic (re-encoded to 41.37 MB, but paid plans make re-encoding optional)
• Podserve.fm
• RedCircle (re-encoded to 55.1 MB)
• Simplecast
• SiteGround*
• SoundCloud
• Spreaker
• Transistor (thanks to Podrick Scuadrick from PodScure)
• Whooshka (re-encoded to 55.1 MB)
• ZenCast

*Not a podcast-hosting provider.

I could not get test accounts with Art19 or Megaphone.

Please note that some of these hosts re-encoded my MP3 file without my option to change it, always resulting in a bigger file than I uploaded. One exception is Buzzsprout who re-encodes only down, but never up. So my 64 kbps mono file was not re-encoded up to 96 kbps mono on Buzzsprout like it was re-encoded up to various rates with the other indicated hosts.

For disclosure, some of the paid-for hosting options were provided by the respective companies at no cost to me for the sake of my testing and review. I also invited any hosting company to preview this article before publication, which often opened a beneficial dialog, but did not affect the data.

If you represent a podcast-hosting company I didn't include and you want to see your service tested and listed here, please contact me!

Combined global averages and medians

First, let's look at the combined global timings for each hosting company. Each test was performed 10 consecutive times and those results combined to calculate regional and global averages and medians. Where the average and median greatly differ illustrates potential slowness in a host.

About Podbean and podOmatic

Whoa there, Podbean and podOmatic! Those two were the slowest hosts. Podbeans Unlimited Audio and Unlimited Plus plans are designed with lower performance to be more budget-friendly, while the Business Basic plan performs on par with competitors.

This slower performance may seem horrible, but remember this is a 60-minute MP3 that downloaded completely in a global combined median under 10 seconds. That's about 6 minutes of audio downloaded in only 1 second. Even if the MP3 was encoded at higher bitrates, it's still fast enough that most podcast consumers would not notice a difference. Nonetheless, if you have a large audience or your business depends on your podcast, it's worth investing in a faster hosting option.

podOmatic didn't appear to have a free trial for their premium plans, so I wasn't able to test for differing performance.

If you host with Podbean's Unlimited Audio and do not use their RSS feed for your podcast, I suggest updating your download URLs to the new mcdn.podbean.com URLs, which nearly double the previous performance, as shown in the following chart.

(This CDN change is automatic for customers using the Podbean RSS feed.)

Regional medians

Get ready for data overload! Here are the median results from all 16 test locations. Click on items in the legend to hide that date from the chart and make other data more visible. (I'll embed the full data table at the end of this article.) To make the charts more visible, I split the slowest hosts into their own chart.

About half of the providers offer extremely-fast hosting for North America, but slow down in other parts of the world, especially Sydney and Singapore. Buzzsprout, Fireside, Pinecast, Pippa, Podbean Business Plus, Transistor, and, surprisingly, Soundcloud were the only options with consistently fast downloads to every test region (including Sydney and Singapore).

Remember these are medians, not averages. So a single bad test out of 10 consecutive tests would barely affect the results.

Wi-Fi timings

Wi-Fi is a significant normalizer for download speeds and it's more likely how most people will download podcast episodes. Here are the results of the same download tests conducted over a Wi-Fi 5 network (formerly known as 802.11ac) with a 200 mbps (down) Internet-service provider in greater Cincinnati.

This raises the floor from milliseconds to seconds. There's still some significant difference between hosts (such as Podbean and Buzzsprout), but the Wi-Fi connection (at least at 200 mbps) makes more of the hosts perform about the same as opposed to the multi-gigabit network speeds of my Vultr servers.

Untested factors

My regional tests were performed on virtual private servers with a multi-gigabit network connection. Real-world results will vary greatly depending on Internet speed, wireless signal strength, and device hardware. That's another reason you may not need the fastest host: typical Wi-Fi connections and local bandwidth could normalize a lot of these results.

Every test was performed consecutively, with no overlap. Thus, my data doesn't reflect potential performance differences when there are hundreds or thousands of devices requesting the same thing at the same time. But I think it's likely that the best perform providers also have the backend performance to meet the high demands of simultaneous downloads. And this is why a CDN is important: if the file lives in only one place on the Internet, such as with Amazon S3 or a web host, then simultaneous downloads can easily overload the bandwidth of that single point. But with a CDN, someone in California could be downloading a file from a completely different server compared to someone in London.

I also could not test the upload performance of each podcast host. I've heard from some podcasters outside North America that uploading to some providers is extremely slow from their region because the media must first go to a server in the USA before spreading across the CDN. As frustrating as this could be for podcasters, it's something that occurs only once per episode and doesn't affect the audience. Nonetheless, if it becomes too frustrating for your situation, you might want to consider a different host.

An important discovery on stats

Only a podcast-hosting company will provide podcast stats. This is a big reason to avoid hosting your podcast media on a non-podcast host (like Amazon S3, your web host, or a private CDN) unless you can layer reputable tracking (such as Blubrry Stats) into your download URLs or, of course, you build your own IAB certified system to analyze the raw download logs.

Because my testing was done with bots that were not declaring a user agent (let alone a podcast-app user agent), I wanted to see how some of these hosts would count my test downloads. 0 would be best, 16 (1 per test region) would be acceptable, and anything more than 16 would be concerning.

These podcast hosts did not count any downloads from my bots:

• Blubrry
• Buzzsprout
• Captivate
• Castos
• Libsyn
• Omny Studio
• Pinecast
• Podbean
• podOmatic
• Transistor
• Whooshka
• ZenCast

These podcast hosts counted some downloads:

• Anchor: 16
• Podigee: 16
• Podserve.fm: 16
• RedCircle: 16
• Simplecast: 8 (I'm guessing it counted only one per continent)
• Spreaker: 16

Podcast stats were not available from Amazon S3, Archive.org, SiteGround, and Bunny CDN because they're not podcast-hosting companies.

And here are the concerning hosts I suggest avoiding because their stats counted more than 1 download per bot (for unknown reasons):

• Audioboom: 32
• iVoox: 32
• Podiant: 32
• SoundCloud: 24

And here's the current naughty list of hosts that counted every bot download (at the time of this test), resulting in 160 fake downloads.

• Fireside—working on changes in July that should better filter downloads
• Pippa—see below for how to change the default and make Pippa stats more accurate
• Podcast.co—working on changes in July that should better filter downloads
• Podmio

I hate to throw any company “under the bus,” but the tracking from these four offenders was so vulnerable that I could have a single bot download the same episode 1,000 times in 15 minutes, and it artificially inflated the stats by exactly 1,000.

In the interest of journalistic integrity, I reached out to these four hosts to alert them of the vulnerability and let them see my data before I published, so they will probably work to resolve this vulnerability as soon as possible. Fireside was already refining their tracking, and Pippa pointed me to a buried option.

Pippa's buried “analytics windowing”

Pippa offers an “analytics windowing” option buried in the advanced settings, described as follows.

Windowing affects the way that plays of your podcast are counted and presented. For example, with a 1 hour window, if the same device plays the same episode twice within 1 hour, then only 1 play will be counted in the analytics. Windowing does not affect delivery of the podcast to listeners, only presentation of the analytics. Your chosen window will be effective going forward, not backwards.

(When Pippa says “play,” they really mean “download.”)

Thus, Pippa presents three windowing options: deactivated (the default), 1 hour, and 24 hours (IAB's measurement guidelines). I conducted my tests with the default show settings, and thus with windowing deactivated. This explains why the stats were so easy to manipulate on Pippa. When I changed the windowing option and retested, Pippa counted only 1 download per region.

That's an acceptable number, but leaving this option to the user, buried in advanced settings, and having it deactivated by default is still corrupting the data. For Pippa stats, this would always require the question, “How is your analytics windowing configured?” Thus, it's possible to have three separate podcasts with identical audiences report three completely different numbers.

Conclusion

If you want the truly fastest podcast media hosting, or you want to ensure your hosting can handle the high demands of simultaneous downloads, then I recommend choosing the best performers from this list (in no particular order).

• Top recommendations: Blubrry or Captivate tied for first place—IAB certified
• Libsyn—IAB certified
• Transistor—claims to follow IAB guidelines
• Simplecast—IAB certified
• Buzzsprout—IAB certified
• Podbean Business Basic—IAB certified
• Pinecast—claims to follow IAB guidelines
• Whooshka—IAB certified (but they re-encode up)

Complete data table

Need personalized podcasting help?

I no longer offer one-on-one consulting outside of Podcasters' Society, but request a consultant here and I'll connect you with someone I trust to help you launch or improve your podcast.

Ask your questions or share your feedback

• Comment on the shownotes
• Leave a voicemail at (903) 231-2221
• Email feedback@TheAudacitytoPodcast.com (audio files welcome)

Connect with me

• Subscribe to The Audacity to Podcast on Apple Podcasts or on Android.
• Join the Facebook Page and watch live podcasting Q&A on Mondays at 2pm (ET)
• Subscribe on YouTube for video reviews, Q&A, and more
• Follow @theDanielJLewis

Disclosure

This post may contain links to products or services with which I have an affiliate relationship and may receive compensation from your actions through such links. However, I don't let that corrupt my perspective and I don't recommend only affiliates.

Related Content

Podcasters, Podcasting Equipment, and Podcasting Software that I’m Thankful For

Libsyn Now Offers Podcast-Training in Spanish, IAB-Certified Podcast Stats, and Expanded Distribution

How Proxies and iOS 14.5 Affect Your Podcast