We love animated GIFs. Really love animated GIFs. The only problem with our love of animated GIFs is how unnecessarily wastefully large the files are. For example, if you load up Sploid, at the moment of writing this post 15 of the 20 displayed posts contain a GIF, each weighing at least 2 MB: a full pageload is 32 MB. That takes a lot of time to download and render on desktop machines, but it hurts especially on mobile devices, with their slower CPUs and metered bandwidth limits.
We’ve already been doing some tricks to remedy this somewhat: we only load animated GIFs when they scroll into the viewport; or on phones, if the reader explicitly clicks on it, but once requested, 2 MB is 2 MB.
For some time now, our image hosting provider Cloudinary has supported automatically converting animated GIFs into MP4 or WebM videos. We’ve been brooding over implementing this for so long that today every browser we support, both desktop and mobile, can play at least one of these formats, so as a hackday project, I recently experimented with serving up video files in place of wherever GIFs were uploaded, as the lowest of low hanging performance optimizations: keeping everything the same, except loading videos instead of GIFs. Initial results seemed more than promising: a full load on Sploid with all videos playing was about the same size (~6 MB) as the initial pageload size with the first GIF loaded, the rest being frozen stills. Render time also decreased slightly. Everything was awesome.
Looking at it deeper, however, major issues emerged. As a start, on all mobile devices, even though the videos are a fraction of the sizes of the GIFs we could load and play automatically if we wished, autoplaying is completely disabled and must be started by a user action.
Fine, I guess, uncomfortable as it may be: it matched our current behavior, except for the completely arbitrary limit with iPhones: every video, once started in iPhone Safari, will play in a full screen overlay. Also, you will always have a giant triangle-in-a-circle play button overlaid, and you can’t customize the play button to even match what we had before. Other devices, including the iPad, could play videos inline, and would let us use our current overlay. A quick glance into our browser stats revealed that about a quarter of visits come from iPhone Safari, so this was a problem.
And then we ran into the weirdest Chrome bug, that completely shattered any hope of turning this feature on: if you have a video with no audio track, the last frame is displayed only for a fraction of a second. Posts with few-frame animations like this one became unwatchable. There has been a ticket for this in Chrome’s tracker since October, with only some clumsy workarounds. Since forty-some percent of our readers use Chrome, this also represented a major problem.
Based on these limitations, in the end, we decided to pull the plug and stay with GIFs.
(This GIF is 3.8 MB. As a video, it would have been 190 kB, or about 5% the size. Sigh.)