2026-07-31

GIF vs. WebM for website animations: why page speed tools flag GIFs (and what to export instead)

Run a page with an animated GIF on it — a product demo loop, an animated logo, a screen recording someone turned into a GIF — through PageSpeed Insights or Chrome DevTools' Lighthouse panel, and there's a good chance you'll see a flag recommending a video format instead. That's not an overzealous audit being picky. It's the same thing Google's own web.dev team says, with a real before/after size comparison behind it. Here's what that comparison actually shows, what the audit is checking for, the markup that makes a <video> behave like a GIF, and where a tool like NearVid does and doesn't help with turning a source clip into something page-ready.

The size gap, from Google's own worked example

web.dev's own article on this gives one specific, real example rather than a general rule of thumb: the same short clip comes in at 3.7MB as an animated GIF, 551KB re-encoded as MP4, and 341KB re-encoded as WebM — the WebM version alone is roughly a tenth the size of the GIF, for visually the same content. That's not a claim this post is inventing a multiplier for; it's the exact numbers from Google's own writeup.

The gap exists because of what each format is built to compress, not because GIF encoders are badly tuned. Video codecs like H.264 and VP9 spend most of their bits predicting each frame from the ones next to it — only the pixels that actually changed get re-encoded. GIF has no equivalent: it's a per-frame, limited-palette format with no motion prediction, built for a completely different era of the web. A GIF has to re-spend bits on every frame regardless of how little changed between them, and that adds up fast over any real duration.

What the page-speed check is actually looking for

The specific warning — "Use video formats for animated content" — is a documented Lighthouse audit, per Chrome for Developers' own docs: it lists every animated GIF on the page along with an estimated time savings from converting it, in seconds. As of Lighthouse 13, that standalone audit has been folded into the broader "Improve image delivery" insight rather than appearing as its own line item — but the underlying check, and the recommendation, are the same: "consider using MPEG4/WebM videos for animations... instead of GIF to save network bytes." If your last Lighthouse run doesn't show the audit by its old name, that's a UI reorganization, not the guidance going away.

Making a video actually behave like a GIF

An animated GIF has three behaviors baked in by default: it autoplays, it loops, and it's silent. Per web.dev's companion codelab, a <video> element needs four attributes together to match that — autoplay loop muted playsinline — and if you're offering both a WebM and an MP4 source, <source> order matters: browsers don't evaluate which listed source is smaller or better, they just pick the first one they can play, so list the smaller WebM file first if you want it preferred. One nuance worth knowing before you assume video is a strict upgrade on every metric: an <img> can be a page's Largest Contentful Paint element, but a <video> without a poster attribute typically isn't counted as an LCP candidate the same way — which can shift which element your page's LCP score is actually measuring, for better or worse, depending on what that GIF was doing on the page.

Where NearVid fits — and where it doesn't

NearVid's WebM export is exactly the "generate a WebM instead" half of this: it re-encodes to VP8 + Vorbis with High/Medium/Low quality presets (2M/1M/500k bitrate) entirely in the browser tab, so the source clip — a screen recording, an exported animation render, whatever you were about to turn into a GIF — never leaves your device to get converted. Trim first if the clip runs longer than the loop actually needs; NearVid's trim is a lossless stream copy, so cutting it down costs nothing extra before the WebM re-encode. And since the LCP nuance above turns on whether you supply a poster image, NearVid's frame-extraction tool can pull a single JPG or PNG from any timestamp in the same source clip to use as that poster, without a second tool or a second upload. On Chrome or another Chromium-based browser with WebCodecs support, the same clip can also export as a real MP4 as a second <source>, for browsers that don't play WebM.

To be specific about what it doesn't do: NearVid's file picker only accepts video files — video/* plus a fixed list of video extensions — not an existing .gif. If the only thing you have left is a GIF someone already exported and the original clip is gone, NearVid can't take that GIF back to WebM for you; this whole workflow assumes you still have, or can still make, the source video. NearVid also doesn't generate the <video> markup or wire up the attributes above for you — it produces the WebM/MP4/poster files; the HTML that embeds them on your page is still something you write yourself.

The honest summary

Google's own numbers, not a general rule invented for this post: the same clip ran 3.7MB as a GIF, 551KB as MP4, and 341KB as WebM. The Lighthouse audit that flags this is real, documented, and still active under a reorganized name as of Lighthouse 13. Getting the benefit means exporting from the original video, not the GIF you already made — trim it to length, convert to WebM (and MP4 as a fallback source, where the browser supports it), pull a poster frame if you want one, and wire the autoplay loop muted playsinline markup around it yourself. All of the conversion work happens on-device; none of the HTML wiring does.