Safari 11.1 shipped a strange-but-very-useful feature: the ability to use a video source in the <img>
tag. The idea is it does the same job as a GIF (silent, autoplaying, repeating), but with big performance gains. How big? “20x faster and decode 7x faster than the GIF equivalent,” says Colin Bendell.
Not all browsers support this so, to do a fallback, the <picture>
element is ready. Bruce Lawson shows how easy it can be:
<picture>
<source type="video/mp4" srcset="adorable-cat.mp4">
<!-- perhaps even an animated WebP fallback here as well -->
<img src="adorable-cat.gif" alt="adorable cat tears throat out of owner and eats his eyeballs">
</picture>
Šime Vidas notes you get wider browser support by using the <video>
tag:
<video src="https://media.giphy.com/media/klIaoXlnH9TMY/giphy.mp4" muted autoplay loop playsinline></video>
But as Bendell noted, the performance benefits aren’t there with video, notably the fact that video isn’t helped out by the preloader. Sadly, <video>
it is for now, as:
there is this nasty WebKit bug in Safari that causes the preloader to download the first
<source>
regardless of the mimetype declaration. The main DOM loader realizes the error and selects the correct one. However, the damage will be done. The preloader squanders its opportunity to download the image early and on top of that, downloads the wrong version wasting bytes. The good news is that I’ve patched this bug and it should land in Safari TP 45.In short, using the
<picture>
and<source type>
for mime-type selection is not advisable until the next version of Safari reaches the 90%+ of the user base.
Still, eventually, it’ll be quite useful.
What does this do that can’t already be done with the video tag?
Functionally nothing, but has perf benefits. Check out the article above ;)
Okay the article referenced says that unlike images, browsers do not preload the video tag. Isn’t there an attribute to the video tag that tells the browser to do exactly that? I seem to remember it being called preload…
The
preload
attribute is not needed in this case, because the page already indicates via theautoplay
attribute that the video should load immediately.I’d like to reiterate that it’s the browsers’ responsibility to ensure that muted video autoplay is just as fast as an animated image. If it currently isn’t for whatever reason, than the browser needs to fix this. Using
<img>
with an MP4 source is nicer (shorter) syntax, but websites shouldn’t be forced to use it for performance reasons.I think this is a great idea…way to go Safari…What I would really like as well is a native browser way to set a video as a background-image in CSS…that would be great…but I will take what I can get for now (or the near future anyway…).
I think the problem is not the “performance” but the semantics.
Does a video in a picture tag ignore audio? (It should, an image is not multimedia content).
Perhaps a larger problem with this is the notion of animated and static media (which is clearly not the same) is being bungled into any one tag or the other.
In-fact video is a terrible name too. I’m just not sure I have an alternative name that isn’t complete jank.
“20x faster and decode 7x faster than the GIF equivalent,” That right there is amazing.
Can we expect support from all major browsers soon?
What’s a nifty case scenario where one might want to use a video as an image?
Anywhere you might otherwise choose an animated GIF.
What about a fallback that uses the video tag mentioned above?
Maybe old days developers could remember that old IE (4, 5 or 6) don’t remember exactly played AVI and MPEG video files in . So this feature isn’t so new :)