Me too. They were designed in a way any modern hardware Accelerated GUI 2D/3D engine should be able to perform them entirely in hardware with CPU just pre filling command lists. When I researched the problem I found they might be much leaner on Safari which isnt surprising considering they were proposed by WebKit in 2007, and Apple (in its fight vs Flash) would want them optimized for phone battery. On Chrome they are second class citizen. There isnt even a visibility check - CSS animation will run on 100% obscured or offscreen elements.

You can edit

    .rain {top: -4800px;

to top: 4800px, CPU utilization doesnt change. It sure feels like some procedure spinning in place burning CPU doing nothing. Just a reminder, Rain is implemented in a clever way, its blitting one 800x600 bitmap 6 times per animation frame to a frame buffer. Worst case scenario its 600MB/s fillrate done entirely by hardware accelerated 2D engine, yet Chrome is using ~30% of one 4GHz CPU core doing this.

Hmm, maybe its reading buffer back from GPU and compositing in software? I did an experiment and deleted 5 of the 6 DIVs reducing load to 100MB/s fillrate and CPU utilization didnt even budge .... so Chrome is doing something stupid like reading GPU buffer back to main memory and pushing it to GPU again. This explains why my older i5 laptop was so loaded by stupid tiny text scroll.

Original dev here. I took another look at these and I found a lot of animations that we could convert to transforms to improve performance. I just created a new issue here: https://github.com/bryanbraun/after-dark-css/issues/9