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.
Ire Aderinokun describes a frustrating problem that we’ve probably all noticed at one point or another:
Recently, I’ve found that some of my articles that are GIF-heavy tend to get incredibly slow. The reason for this is that each frame in a GIF is stored as a GIF image, which uses a lossless compression algorithm. This means that, during compression, no information is lost in the image at all, which of course results in a larger file size.
To solve the performance problem of GIFs on the web, there are a couple of things we can do.
Switching to the
<video> element seems to have the biggest impact on file size but there are other optimization tools if you have to stick with the GIF format.
This is pretty big news: earlier today the WebKit team announced that iOS 10 will now support silent
<video> elements with the
autoplay attribute, which is a big deal for performance. Jer Noble describes the update in much more detail:
It turns out that people these days really like GIFs. But the GIF format turns out to be a very expensive way to encode animated images when compared to a modern video codec like H.264. We’ve found that GIFs can be up to twelve times as expensive in bandwidth and twice as expensive in energy use. It’s so expensive that many of the largest GIF providers have been moving away from GIFs and toward the
<video>element. Since most of these GIFs started out their lives as video clips, were converted into animated GIFs, and were again converted back to video clips, you might say that the circle is complete.