The strange case of the super-slow podcast page

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.
</audio>

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.
</audio>

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.
</audio>

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