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 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
<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.
Fallbacks for Videos-as-Images is a post from CSS-Tricks