Skip to main content

The strange case of the super-slow podcast page

Headphones on a yellow background

While in the final stages of creating the new website for The Property Finders, we ran into an unexpected problem that took a bit of solving. I'm leaving this here in case anybody else hits similar problem with multiple <audio> elements in the Safari browser (or any other browser, for that matter).

The original site (built with WordPress/Divi) had a list of podcast episodes, each of which loaded a JavaScript audio player into the page. While this worked well, when redeveloping the site we wanted to move to the HTML5 <audio> element, for futureproofing, standards compliance, and a lower maintenance overhead. Essentially, the browser understands that you want to play audio and provides a player for it (as opposed to you needing a separate piece of JavaScript to do the job, as the old site did).

We develop on PCs and use a variety of browsers among the team. Generally, there are so few differences between browsers these days, and the frameworks we build on so robust, that we don't check Macs/iPads until the very end, as a kind of sanity check. As a result, we didn't spot this issue until we were about to go live.

The problem was that, on iPads using Safari, the podcast page took ages to load. Well over 10 seconds, even on the latest iPad Pro, and sometimes more. Whereas every other page of the site was lightning fast.

My first thought was to wonder if the number of podcast files in the page was an issue. I wasn't convinced that this was the cause, because most browsers were fine, but it seemed to be an easy thing to rule out.

I created a page with just a single podcase episode on it, and loaded it on the iPad. It loaded as quickly as all the other pages, so my suspicions deepened.

A quick Google didn't bring up any specific results for 'Safari problem with multiple audio elements' so I took a closer look at our code. Here is the appropriate section as we originally developed it, which would be repeated for every podcast on the page:

<audio controls>
<source src="[link to MP3 file]" type="audio/mpeg" />
Your browser does not support the audio element.

So far, so standard. We only allow a single MP3 file to be uploaded for each podcast, so I figured that I could simplify the code to avoid the <source> element, in case that was upsetting Safari. I changed it to this.

<audio controls src="[link to MP3 file]" type="audio/mpeg">
Your browser does not support the audio element.

Still no joy.

My next port of call was MDN's article on the <audio> HTML element, which showed me that <audio> has a property called preload, which can be used to tell the browser whether or not to load the media files before 'play' was pressed. And it had two interesting nuggets of information; first, that this is just considered a hint; the browser doesn't have to pay attention to it. And second, the each browser has its own default value.

So it got me thinking. Maybe Safari was trying to load all of the audio files during the page load. Or at least starting the process of downloading each one, even if they hadn't fully completed before the rest of the page had rendered.

Safari currently allows up to six simultaneous connections to the same domain name; this is known as the parallel requests limit.

If Safari was trying to preload all the audio files, a single podcast would be fine, because it would only tie up one of the six possible connections, so the rest of the site would load quickly on the other five. With fifteen or so podcasts on that page, however, Safari would hit its six connection limit, and have to wait while at least eleven large audio files files finished downloading before the rest of the page could carry on loading.

That certainly matched the behaviour we were seeing. So, I tried supplying a value for preload, as per the code below:

<audio controls src="[link to MP3 file]" type="audio/mpeg" preload="none">
Your browser does not support the audio element.

I knew that Safari wasn't required to pay attention to the preload value, so I held my breath as I refreshed the iPad. And guess what? Suddenly the page was lightning-fast again.

Feel free to take a look at it here!

Header image by C D-X on Unsplash

Iain Row

About the author

Iain Row

Iain founded Prominent Media in 1999, from a bedroom in Newport Pagnell. 20 years later, it has grown to be one of the best-known and friendliest software development companies in the Milton Keynes area, as the internet has woven itself into the fabric of our lives.

"We make sure we fully understand the brief before we do anything. It means we can get the project up and running for you more quickly and we know what outcome you want from it.

We have a good reputation and we want you to recommend us or use us again yourself. If our work doesn’t bring you the results you want, you won’t come back! That’s why we have a growing team in-house to build your website, install your WebShop, set up a high-end content management system or create bespoke software applications – and to make sure it’s exactly what you want."

Iain Row

Managing Director

Cookie Notice

This website uses cookies for traffic monitoring only.

Back to top