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:

*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:

These podcast hosts counted some downloads:

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.


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

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


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.

About the Author
As an award-winning podcaster, Daniel J. Lewis gives you the guts and teaches you the tools to launch and improve your own podcasts for sharing your passions and finding success. Daniel creates resources for podcasters, such as the SEO for Podcasters and Zoom H6 for Podcasters courses, the Social Subscribe & Follow Icons plugin for WordPress, the My Podcast Reviews global-review aggregator, and the Podcasters' Society membership for podcasters. As a recognized authority and influencer in the podcasting industry, Daniel speaks on podcasting and hosts his own podcast about how to podcast. Daniel's other podcasts, a clean-comedy podcast, and the #1 unofficial podcast for ABC's hit drama Once Upon a Time, have also been nominated for multiple awards. Daniel and his son live near Cincinnati.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
Super Joe Pardo
4 years ago

Great work Daniel!!

Chad Boyd Chalmers
4 years ago

A fantastic article. I use Fireside and their analytics do annoy me as I knew they weren’t real. However, they do provide very cheap hosting and a website for peanuts, so I shouldn’t complain. It’s a trade off.

Royce Davis
Royce Davis
4 years ago

Any update on fireside?

4 years ago

Nice episode, only i’ve got a bit of a crazy setup my self. I’m using S3 for serving my files. But got the WordPress Podlove podcast ( podlove.org ) plugin that i’m using. This also provides the statistics and the feed. Caching is a thing i’m doing my self. Podlove is looking in supporting IAB 2.0. But they already save the info: https://community.podlove.org/t/iab-guidelines-2-0/1537/2

4 years ago

Hey Daniel, this is an overwhelming amount of info. It looks like you did alot of work and thanks for doing it. This data will be great to come back to. And thank you for not giving up on all those beginners out there like me.

I am a new podcaster and just found your channel (came to the game late it seems)– I wanted to suggest a few topics that you haven’t really covered.

1- I find myself recording and then rerecording the same episodes over and over because I keep feeling like I could present it better. I don’t know why but i say lots of ums or so (which can be edited out) but then I will talk too fast or slow. It is so much harder to record than to just have a conversation. I never realized how many incomplete sentences I used or how much I depended on other people’s reactions. Do you have any good tips or guides? I am hoping this will get better over time but I find it hard to publish these episodes when I know I could do better.

2- Do you script your podcasts or vidcasts? Do you recommend it? How do you keep your voice in a certain cadence?

3- I am very interested in having certain episodes be vidcasts rather than just audio (Its why I decided to go with Libsyn) but you don’t have a whole lot of info on recommendations, tips or how tos on this.

Thank you again. I hope you have some good help for me.

Royce Davis
Royce Davis
4 years ago

Great information and I commend your research efforts brother????????????????

4 years ago

Thanks a lot for the article!.
Would be nice to see the same test but not from bots but from real people and devices. There is a need of benchmarking analytics feature across all podcast hosting platforms.

John Fang
4 years ago

Thank you for the thorough test Daniel. Definitely a lot of value, especially that I received feedback for the slow embedded web player on my blog (I am hosting my podcast on Podbean).

I am currently hosting on Podbean and am using their RSS feed. I saw that you advised to use the mcdn.podbean.com URL, if it’s not too much trouble, would you elaborate on how do I can go about doing that? Or possibly speed up the feed?

Thanks again for such an insightful blog!

Paul Munger
Paul Munger
4 years ago

Wow, this is incredible. Very well done research. I love data!


[…] podcasts es importante, pero hasta cierto punto. Desde The Audacity to Podcast cuentan sobre los servicios de hosting más eficientes y otros detalles a tener en cuenta. Su conclusión sobre los más rápidos: Bluberry y Libsyn. Los […]

Would love your thoughts, please comment.x

Enter your name and email address below to learn “7 Ways to Get More Podcast Reviews” FREE!

Almost there!


See what Apple Podcasts and other popular podcast apps search with the Podcast SEO Cheat Sheet!

This form collects information we will use to send you podcasting-related updates with tips, offers, and news. We will not share or sell your personal information. You can unsubscribe at any time.

Almost there!


Before you go! Don’t miss this FREE checklist, “20 things you should do before recording every podcast episode”!

This form collects information we will use to send you podcasting-related updates with tips, offers, and news. We will not share or sell your personal information. You can unsubscribe at any time.

Almost there!