CPU strain from animated GIFs question

Hi. I am making a website that has a number of animated GIFs on it, and I suspect they will cauase some CPU strain (…or would it be GPU strain?..).

  1. What I am wondering, is if they DO strain the CPU/GPU, is it only when they are visible on screen, or does it happen even if they are offscreen (but on the current HTML page).

  2. If that’s the case, I may break the website up into a few pages, rather than one, so that the animated GIFs will be distributed between them, rather that all on one page (…if they do strain the computer, even when offscreen).

Bonus question: I’m sure many of you reading this are screaming, 'Animated GIFs?!! That’s so old-school!! Use HTML5’s video tag, or canvas… or some ‘modern’ method… I’d love to, but from what I have seen so far, those methods all have some issue/limitation… and meanwhile animated GIFs seem to work great, are easy to make, and even ‘brake’ elegantly, showing just the first frame if not supported.

The HTML video tag initially seems (and boasts) being very simple and ‘minimal code’… until you have to suppliment it with the many lines of code to address the video format incompatibilities of the browsers… plus, you have to make 3 different format copies of each clip (which, in my case, would be brutal). As for Canvas, I’m not sure what the compatibility currently is. Granted, this is all based on books I read which are a few years old, so I’m not sure if things improved since then.

My site requires a gallery of animated thumbnails (…meaning they are playing 2-3 second loops of animations/videos)… plus, I was wanting some animated graphic elements (which would also require alpha for them to sit on top of the website background).

So, if there’s a better solution to animated GIFs (that’s as easy, as compatible, as lite in file size, and breaks elegantly when it isn’t compatible), I’d be open to it. I just haven’t found one yet, and the GIFs seem to work great. I’m not even clear on whether the computer strain would be better or worse using some other format besides animated GIFs.

UPDATE: I viewed the page while running system explorer, to watch if/how the CPU strain changes, and even though there was definitely a spike when the page first loads, it quickly dropped down again, and even when viewing a full page of animated GIFs (worst case scenario) the CPU usage seemed to be around 5-10%… so, that doesn’t seem too bad, right? Really, it’s more about the download speed, I think, if it’s viewed using WIFI or a slow connection. I’m still wanting to experiment with some optimization, like reducing the GIF fps (currently at 15… when I drop it to 8, it halves the file size)… or even reducing the palette size (since most of the clips are animations, which don’t require high fidelity).

Hi @ladlon,
To start with you can optimize the gif’s by using a Gif optimizer (there are several online) and you could implement Lazy Loading to make the gif’s only load when they are visual on screen by scroll.

Thanks for the response. I’m creating my animated GIFs with Photoshop, and the Save For Web feature. I was planning on trying to reduce the palette (currently 256, I think), and had already experimented with further lowering the frame rate (currently 15fps), resulting in a 50% reduction using 8fps.

I was under the impression that GIFs use a delta-based compression/storage system, where only the changed pixels for each frame are stored in each frame, relative to the first frame. Is that something that has to be activated in the settings, or is that not the default storage method?

Are these third party GIF optimizers just for people who are either using premade GIFs or are making their GIFs without adjusting any settings? Are these optimizers pretty much redundant if I am using the settings in the Photoshop Save For Web feature?

My main question still, is whether animated GIFs on an HTML page create computer strain (to whatever degree) even if they are offscreen. This will be a key factor in deciding if I will break my (currently single page) website into separate category pages, to distribute the animated GIFs onto a few pages, rather than having them all exist on a single one… again, assuming that offscreen GIFs still cause strain, otherwise, the amount that is seen is limited by the spacing of the GIF groups (only a certain number are visible on the screen, due to them being spread out over the page.

Also, is there an ideal website I should post on, to ask general HTML related questions?

You could implement Lazy Loading to make the gif’s only load when they are visual on screen by scroll.



For video acting as an animated GIF replacement:

For video acting as an animated GIF replacement

While animated GIFs enjoy wide use, they’re subpar to video equivalents in a number of ways, particularly in output file size. Animated GIFs can stretch into the range of several megabytes of data. Videos of similar visual quality tend to be far smaller.

Using the <video> element as a replacement for animated GIF is not as straightforward as the <img> element. Inherent in animated GIFs are these three behaviors:

  1. They play automatically when loaded.
  2. They loop continuously (though that’s not always the case).
  3. They don’t have an audio track.

Achieving this with the <video> element looks something like this:

<video autoplay muted loop playsinline>  <source src="one-does-not-simply.webm" type="video/webm">  <source src="one-does-not-simply.mp4" type="video/mp4"></video>

The autoplay , muted , and loop attributes are self-explanatory. playsinline is necessary for autoplaying to occur in iOS. Now we have a serviceable video-as-GIF replacement that works across platforms. But how to go about lazy loading it? Chrome will lazy load video for you, but you can’t count on all browsers to provide this optimized behavior. Depending on your audience and application requirements, you may need to take matters into your own hands. To start, modify your <video> markup accordingly:

<video autoplay muted loop playsinline width="610" height="254" poster="one-does-not-simply.jpg">  <source data-src="one-does-not-simply.webm" type="video/webm">  <source data-src="one-does-not-simply.mp4" type="video/mp4"></video>

You’ll notice the addition of the poster attribute, which lets you specify a placeholder to occupy the <video> element’s space until the video is lazy loaded. As with our <img> lazy loading examples from before, we stash the video URL in the data-src attribute on each <source> element. From there, we’ll use some JavaScript similar to the earlier intersection observer-based image lazy loading examples:

document.addEventListener("DOMContentLoaded", function() {  var lazyVideos = [].slice.call(document.querySelectorAll("video.lazy"));  if ("IntersectionObserver" in window) {    var lazyVideoObserver = new IntersectionObserver(function(entries, observer) {      entries.forEach(function(video) {        if (video.isIntersecting) {          for (var source in video.target.children) {            var videoSource = video.target.children[source];            if (typeof videoSource.tagName === "string" && videoSource.tagName === "SOURCE") {              videoSource.src = videoSource.dataset.src;            }          }          video.target.load();          video.target.classList.remove("lazy");          lazyVideoObserver.unobserve(video.target);        }      });    });    lazyVideos.forEach(function(lazyVideo) {      lazyVideoObserver.observe(lazyVideo);    });  }});

When we lazy load a <video> element, we need to iterate through all of the child <source> elements and flip their data-src attributes to src attributes. Once we’ve done that, we need to trigger loading of the video by calling the element’s load method, after which the media will begin playing automatically per the autoplay attribute.

Using this method, we have a video solution that emulates animated GIF behavior, but doesn’t incur the same intensive data usage as animated GIFs do, and we get to lazy load that content.

1 Like

Thanks for the info. So, I guess that GIFs DO strain the computer, even when offscreen, then?

I had previously looked into the whole HTML5 video tag route, as it’s obviously more current… yet was immediately turned off by all the required support coding, plus the fact that (at least at the time I looked into it) there was no combo of format+container which was supported by all browsers/platforms, so you had to make 3 different versions of each clip, which is a serious pain, when you are dealing with 20-30 clips, and know that you will be adding/replacing clips over time.

I’m surprised that video formats are more efficient than GIFs (even when the GIFs are done efficiently).

Where are we currently at, as far as compatibility of the video tag, and more importantly, the format+container compatiblity of all the browsers/platforms? Do we still need to make 3 different formats of each clip?

Video can be much more compressed and further optimized. The code is explained on the Google page.
It’s one line of code. https://www.w3schools.com/html/html5_video.asp
If you want something you have to do something for it! :wink:

Ya, the lazy load coding is a bit over my head, especially with all the workarounds/fallbacks, etc.

If I’m reading things right on w3schools, there is finally unified support for video formats (specifically the mp4 format)… so, why the need for the ogg format? (…It was so annoying, back when I was previously looking into this, how Internet Explorer almost always was the troublemaker, either having a bug in the feature I was looking into, or just flat out didn’t support it…).

When I was looking into the video format, there was 11 lines of code required, mostly to address a Flash fallback.

So, if iPad and iPhone don’t support the autoplay feature, how would the animated thumbnails work? Would they require you to tap them with your finger to play them? Are you, through tag attributes, able in that case to still hide any controls, but have them play on tap… or would the controls be forced to be made visible (which would throw off the alignment of the grid/array of thumbnails)?

Are there any existing Boostrap modules that have this functionality built in? I’m basically trying to find an alterate to my existing animated GIF array of thumbnails (animated GIF gallery).

I was even previously considering having the GIFs in a sliding carosel thing, where only 3-5 of them are visible at once, and you swipe through each set… but, it seems that would be pointless if unseen GIFs still strain the system.


Good luck have to go now!

Thanks for your help.

I have used animated gif on many sites without any noticeable performance hit…

http://ajewelinthelotus.com/ (reflections on the water)
http://aqmai.com/ (water in the wave)
http://eliteliny.com/ (older site, reflection on the logo)

Hi, Printninja. Ya, so far I’ve seen no issues with using GIFs. Seems to work well all on platforms so far, and I love how I can just put them in without need for workarounds or coding. I figure, if it fails, then it shows just the first frame, which is a very nice ‘fail’ state (compared to a broken link or error code!). The only disadvantage I can see, is the obvious limited colour palette and (I assume) clip length, but neither are an issue at all for my purposes… so the benefits far outweigh the claimed limits.

The other good thing about them is that they’re responsive, like any other image.

Ya, I’m a big fan of them, depite how ‘old’ the tech is, and the stigma they have from their ‘randomly cover your website with tons of tacky animated GIFs you found on the internet’ days.

I like the delta based compression, too… and how you can add specific amounts of hold after each frame. For my purposes, this is a really ideal format that hasn’t let me down yet.


If you want to use gif’s you can use a library (or code your own player). Take for instance gifsee.js (one example of many), its vanilla JS and allows you to set a poster image like you would with video then play/stop the gif on demand. Heck you could even make a CSS only setup if you want. But simple to use JS players abound if you want to go that route of using many gif animations for people to view.

Hey, that’s kind of neat. Thanks!