Audit: Serve `<video>` instead of animated GIFs

Suggested audit Serve <video> instead of animated GIFs

Background

Animated GIFs are suboptimal for quality and performance. While they are a popular option for creative expression, they are awful for web performance - they’re large in size, impact cellular data bills, require additional CPU and memory, cause repaints and kill battery. Often, GIFs can be up to 10-12x larger than H.264 videos and take more energy to load and be displayed in mobile browsers. Those resources are being spent on something that has severe color limitations.

Using the <video> tag is significantly better for performance than animated GIFs. GIF sites have been shipped videos down instead of GIFs for years and back in 2014, Twitter even added animated GIF support using MP4s. They transcoded GIFs to MP4 on the fly, delivering them in <video> tags. This is a trend we’re seeing, but are still running into plenty of examples of sites accidentally shipping megs of animated GIFs down. The AMP team recently published a blog post that included 52MB of animated GIFs without realizing this.

Explanation of how it’s different from other audits

Current audits will capture unoptimized images and resources with large payloads but do not specifically call out animated GIFs that could be served down as <video> instead. This is a more targeted recommendation than current audits expose.

GIFs alone would not be flagged by this audit (we probably don’t want to flag 1x1 pixel tracking pixels…) so detecting if an image is an animated GIF using animated-gif-detector, is-animated or detectanimation might be worthwhile.

We’ve been considering implementing a feature policy for this idea so having something related in Lighthouse could be useful.

What % of developers/pages will this impact (estimates OK, data points preferred)

According to Android stable, GIFs account for approximately 4-5% of images loaded by Chrome. Although we do not have statistics on animated GIFs as a subset of this population, shifting animated GIFs over to video has the potential to impact a large number of requests on the web.

According to HTTP Archive, GIFs account for 23% of the total image formats being served on sites tracked by HA.

Advanced

If we wanted to do something really clever here, we could use FFMPEG.js (or similar) to try encoding animated GIFs as videos to demonstrate the byte savings, however, this is probably going to be too expensive for most pages.

What is the resourcing situation (who will create the audits, maintain the audits, and write/maintain the documentation)

This is an audit that could be authored by our Lighthouse contractor @wardpeet with input from myself and the image compression team (and Bonsai team). We have staffing to assist with documentation if needed and are planning to write up a best practice doc on using <video> vs animated GIFs for /web.

Do you envision this audit in the Lighthouse report or the full config in the CLI? If in the report, which section?

The default Lighthouse report. I would place this in the Opportunities section alongside other image optimization opportunities.

How much support is needed from the Lighthouse team?

Evaluation of the technical approach for the audit will be needed. Although there are OSS modules available to assist with detecting whether an image is an animated GIF, these may be 1) too large/unsuitable, 2) require additional thought on the performance of the solution for a page with a number of animated GIFs present.

Note: I noticed this audit was also filed in #2586. I am refiling here using the “new audits criteria” doc that the team published in the docs repo.

[malchata]

@abdonrd IIRC, autoplaying of videos may be blocked if you have data saver turned on. Try turning that off if you have it enabled.

[midzer]

@abdonrd I’ve experienced letting browser load preview image via (now Chromium default) preload="metadata" to be less kbyte heavy in most cases than loading a custom poster.