Animated Content

Convert animated GIFs to video

Large animated GIFs can significantly increase page weight and consume excessive CPU/memory, leading to slower page loads and poor scrolling performance.

Quick Reference

• Use <video> instead of large GIFs for animations
• GIFs are significantly larger than MP4/WebM
• Videos allow for better control and performance

Check

Check for large animated GIFs that could be replaced with more efficient video formats like MP4 or WebM.

Fix

Convert animated GIFs to MP4 or WebM and use the <video> tag with autoplay, loop, muted, and playsinline attributes.

Explain

Explain why video formats are more efficient than GIFs for animated content and how they improve performance.

Code Review

Review the routes, assets, and loading behavior that affect Convert animated GIFs to video. Flag exact files, requests, or rendering steps that add unnecessary network, CPU, or layout cost, and describe the measurement method used to confirm the issue.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/performance/animated-content

Convert animated GIFs to video

Large animated GIFs are replaced with more efficient video formats like MP4 or WebM to reduce page weight.

Priority: medium · Difficulty: intermediate · Time: 10 min

--- Large animated GIFs are often used for short animations, but they are highly inefficient compared to modern video formats. Converting these to MP4 or WebM can reduce file sizes by 80% or more.

Code Examples

#

Traditional GIF (Inefficient)

<img src="animation.gif" alt="Description of animation">

Optimized Video (Recommended)

Using the <video> tag with specific attributes to mimic GIF behavior:

<video
  autoplay
  loop
  muted
  playsinline
  poster="animation-frame.jpg"
>
  <source src="animation.webm" type="video/webm">
  <source src="animation.mp4" type="video/mp4">
  Your browser does not support the video tag.
</video>

Why It Matters

• Page Weight: GIFs are uncompressed and can easily reach several megabytes, slowing down page loads.
• CPU Usage: Browsers consume more CPU/GPU resources to decode and render large GIFs compared to optimized video.
• Battery Life: On mobile devices, the high resource usage of GIFs can significantly drain battery.
• User Experience: Large assets delay the completion of page loading and can cause stuttering during scrolling.

Best Practices

Favor browser-native video delivery guidance from web.dev when deciding whether an animation should stay a GIF at all, because the biggest wins usually come from eliminating heavy animated assets rather than just caching them better.

✅ Use Modern Formats: Provide WebM for modern browsers and MP4 as a fallback. ✅ Add Poster Images: Use the poster attribute to show a static frame while the video loads. ✅ Mute by Default: Always use muted for autoplaying videos to ensure they work across all browsers. ✅ Lazy Loading: Use loading="lazy" or Intersection Observer for videos below the fold.

❌ Avoid GIF for Large Animations: Never use GIF for animations larger than a few hundred pixels or longer than a second. ❌ Don't Forget Accessibility: Always provide alternative text or a description for the animation.

Tools & Validation

• FFmpeg: Command-line tool for converting GIFs to video.
• Cloudinary/Imgix: Automated media optimization services.
• Lighthouse: Checks for large GIFs and suggests video alternatives.

Standards

• Use web.dev: Learn Performance as the standard for measuring the final production behavior, not just local synthetic output.
• Use Chrome Developers: Lighthouse overview as the standard for measuring the final production behavior, not just local synthetic output.

Verification

Automated Checks

• Measure the affected page or flow in Lighthouse, PageSpeed Insights, or DevTools and confirm the targeted metric improves.
• Inspect the network waterfall or performance timeline to confirm the intended resource or execution change actually took effect.

Manual Checks

• Verify the change on a throttled mobile profile, not just local desktop.
• If this rule maps to a budget or Web Vital, confirm the page now stays within that threshold.