Beware if you load this on a mobile device with metered data!

This animation is implemented by loading a large number of ~200KB PNG files, each 800x800px, such as this one [1] and then drawing them into a <canvas> as you scroll.

Having scrolled through the entirety of the animations, Firefox reports that it transferred about 220MB of PNGs on top of the 3.4MB of JS and an inexplicable 202KB of CSS.

Maybe I do not understand some key requirement. Shouldn't it be possible to encode a high quality video file, embed it with <video>, and control it from JS, and still come out with a much smaller file size? Perhaps there's just a requirement I'm missing but that's an eye watering amount of data being served by Cloudfront to every visitor, and Cloudfront isn't exactly the cheapest.

[1] https://d11poao410tx6l.cloudfront.net/616f05008e9fa70027fff3...

edit: I got nerd sniped and downloaded all the frames. Considering only the largest animation (da2783d9-383d-43ec-8778-9b52f984c35a):

  - 230 PNG frames: 51MB
  - WebM (VP9, alpha, lossless): 6.7MB (-86.7%)
  - WebM (VP9, alpha, crf15): 2.3MB (-95.5%)

Instead if I use all the frames in one big video:

  - 1087 PNG frames: 271MB
  - WebM (VP9, alpha, lossless): 39.0MB (-85.6%)
  - WebM (VP9, alpha, crf15): 12.0MB (-95.6%)

I used ffmpeg 4.4.1 with the following commands:

  ffmpeg -i 'frames/%6d.png' -c:v libvpx-vp9 -lossless 1 lossless.webm
  ffmpeg -i 'frames/%6d.png' -c:v libvpx-vp9 -b:v 0 -crf 15 crf15.webm

To my eye, crf15 is very very good quality, but I included lossless encoding so there can be no quibble about quality differences :)

And yes I know Safari can't do VP9 but there's no reason you couldn't also encode a HEVC and AV1 version and list multiple <source> elements and let the browser decide which format it prefers

edit to the edit: It seems that smoothly scrubbing through a <video> element is more tricky than I originally knew. Still, a lot of mileage could be gained by encoding the individual frames as AVIF or WebP and using them in supported browsers