Skip to content

[Performance] Convert oversized GIFs to video to cut ~56 MB of first-load image payload across product pages #8144

Description

@ayushgade06

Summary

This PR replaces large animated GIFs across the Layer5 website with optimized MP4/WebM videos to significantly reduce page weight, unnecessary downloads, and rendering overhead.

There are currently 31 referenced GIFs totaling 61.15 MB across the repository. These GIFs are served as raw <img> elements and are not processed by gatsby-plugin-image. Gatsby therefore copies the .gif files into /public as-is, without compression, resizing, or conversion to a modern format.

None of the current GIF implementations use loading="lazy".

Problem

Several product pages load multiple large GIFs at the same time. This results in a significant amount of media being downloaded during the initial page load.

Measured GIF payload by page:

Page GIFs Payload
/cloud-native-management/kanvas/design 4 11.55 MB
/blog/kanvas/what-is-the-kanvas-catalog 2 10.57 MB
/cloud-native-management/generate-aws-architecture-diagram 4 9.11 MB
/cloud-native-management/meshery/ 5 7.77 MB
/cloud-native-management/generate-gcp-architecture-diagram 2 7.20 MB
/solutions/architecture-diagram/ 4 5.65 MB
/cloud-native-management/generate-kubernetes-architecture-diagram 4 4.74 MB
/solutions/orchestration-management/ 4 2.47 MB
/projects/cloud-native-performance 1 1.05 MB
/solutions/platform-engineering/ 1 1.04 MB

Sizes above are measured directly from the source assets in decimal MB, matching the way browser DevTools and PageSpeed report transfer sizes.

Kanvas Design carousel

The Kanvas Design page is a particularly noticeable case.

All four carousel GIFs, totaling 11.55 MB, are statically imported and rendered when the component mounts. Inactive slides are only hidden using CSS visibility: hidden.

Hiding an element with CSS does not prevent the browser from downloading its image, so a first-time visitor can download all 11.55 MB even though only one carousel item is visible.

The same four GIFs are also imported separately by the mobile swiper, resulting in duplicated asset references.

Root Cause

GIF is inefficient for UI and screen-recording content.

Animated GIFs are limited to 256 colors and do not provide the kind of inter-frame compression available in modern video codecs. As a result, short UI recordings can become several megabytes in size.

The same content encoded as H.264 MP4 or VP9 WebM can typically be substantially smaller, with the exact reduction depending on the source content and encoding settings.

The current implementation also has no consistent lazy-loading or media preloading strategy.

The Kanvas carousel also has its width and height attributes commented out, which makes it important for the replacement video component to provide explicit dimensions.

Changes

GIF to MP4/WebM

Large animated GIF assets are replaced with optimized MP4/WebM video equivalents.

Lazy media loading

Using preload="none" prevents the browser from eagerly downloading video content that the visitor has not interacted with or reached yet.

This is especially important for carousels where multiple videos exist but only one slide is initially visible.

Kanvas carousel

The duplicate GIF imports between the desktop carousel and mobile swiper are removed so both implementations reference the same optimized sources.

Layout stability

The replacement videos use explicit width and height or an appropriate aspect-ratio so that replacing the GIFs does not introduce layout shifts.

Performance Impact

The total referenced GIF payload is approximately:

61.15 MB → ~5 MB

This represents a substantial reduction in the amount of animated media that needs to be transferred.

Beyond transfer size, this also reduces unnecessary work from continuously decoding and repainting multiple animated GIFs. Video playback can be handled more efficiently by the browser's media/compositing pipeline.

Expected Behavior

After this change:

  • Animated UI recordings are displayed as looping videos instead of GIFs.
  • Videos remain muted, autoplaying, looping, and inline where the original GIF behavior required it.
  • Video content is not eagerly preloaded unnecessarily.
  • Explicit dimensions prevent layout instability.
  • Kanvas desktop and mobile implementations share the same optimized assets.
  • Users on slower or metered connections avoid downloading several megabytes of unnecessary GIF data on initial page load.
  • prefers-reduced-motion can be respected by the shared video component.

Result

This change targets one of the largest sources of static media weight across the Layer5 website.

By replacing the existing GIFs with modern video formats, preventing unnecessary preloading, and de-duplicating the Kanvas assets, the site can reduce referenced animated media from 61.15 MB to roughly 5 MB while preserving the existing visual experience.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions