Iframe lazy loading – srcdoc to the rescue?
About a 6 minute read
Written by Kyle Hawk on Aug 27, 2019
#iframe #lazy-loading
I heard about this the other day when I was browsing css-tricks. They linked over to an article written by Arthur Corenzan. The article was about lazy loading embedded YouTube videos, which struck my fancy.
Just a heads up; there’s also a cool, new way to lazy load an iframe that’s super easy. Check out the loading attribute.
If you aren’t familiar with my website randomanime.org, the anime page’s all have iframes for YouTube videos. These YouTube videos are for trailers or previews of the anime. On my list page, where there are multiple pages loading at once, iframes became an issue.
Srcdoc to the rescue? Maybe, let’s look at two ways.
Toggle DOM Method
The current way I have my site set up to stop all the junk that YouTube videos bring with them is simple: fake it.
<div class="iframe-container">
<div tabindex="0" title="Click me to play the video!" data-ng-click="showTrailer = true" data-ng-if="!showTrailer">
<!-- stuff to make it look like a preview -->
<!-- This is an example, you'd also want to make this keyboard clickable too -->
<div>
<iframe src="some-youtube-video-url" data-ng-if="showTrailer"><iframe>
<div>
My website uses AngularJS, so the ng-if attribute is my friend here. I have some divs styled up to be the same size as the iframe will be, and then I use the YouTube video id to pull in the preview for the video. Add in a play button that looks like YouTube’s and bingo, we have our fake click to play.
Whenever a user clicks on the play, or now a load, button, the preview is swapped out and the iframe is added into the dom. It does all of its YouTube embed stuff, and we are on our way.
Srcdoc Method
Let’s say we don’t want to mess with adding and removing the iframe from the dom, cause that’s just feels icky.
Srcdoc is an attribute for an iframe that allows you to specify the HTML content of the page to show inside of the frame. It will replace the src of the iframe with whatever we specify. We could literally just put “<p>Hello World</p>” in there and that would display…but it wouldn’t be very helpful.
<iframe src="some-youtube-video-url" srcdoc="<p>Hello World!</p>"><iframe>
The key is to use srcdoc to create a preview, kinda like how I previously described. Except instead of toggle the dom or anything like that, we just have to create an anchor tag that links to the actual YouTube video embed. Or, in other words, create a link that is identical to the src attribute.
Whenever the link is clicked, the user will navigate to that url within the iframe, and bingo we have our YouTube video embed.
<iframe src="some-youtube-video-url" srcdoc="<a href=some-youtube-video-url>Click me to load the video!</a>"><iframe>
Kind of cool, right? It’s still technically “faking it”, but it’s a lot more elegant…unless you look inside the srcdoc attribute, then it looks crazy. Do notice that inside of srcdoc you don’t use quotes for the attribute values.
Downsides
The glaring downsides to both of these methods is that the autoplay feature for the video will not work. YouTube doesn’t like to autoplay videos anymore unless they are muted. If a video is muted, it will respect the autoplay (only on desktop, mobile you are just out of autoplay luck). However, in many cases, this is not the desired result.
For example, my trailer videos shouldn’t be muted. If the video starts playing muted, the user is going to be very confused and maybe even frustrated.
The second downside refers only to using srcdoc, and that is that it is not supported in Internet Explorer, or Edge. Bummer. We expect these things from Internet Explorer, and it’s getting easier to just cut the cord, but Edge is the real killer here. Edge support is needed.
In certain cases, just including the iframe src is enough of a backup for Edge. If srcdoc is not supported, it falls back to src. In my case, it’s a no go, because that means my Edge users would be taking a huge performance hit.
Conclusion
As cool as this method is, no Edge support is a killer for me. I could deal with it if it was just Internet Explorer, but not Edge. On the bright side, it is in development for Edge, so we’ll see.
Hopefully this was helpful to someone out there! Be sure to check out Arthur’s article as well as he also goes into some fun accessibility stuff.
Thanks for reading.