When the tab is in view I get a 60 - 100% CPU usage on this static page. Tested On OSX with FF60 and FF58 A quick sample session shows that FF spends most of the time in -> mozilla::PresShell::Paint -> nsLayoutUtils::PaintFrame Works fine in chrome.

Thanks! I can reproduce. Here's a profile: https://perfht.ml/2Em2R2y Looks like there are some offscreen CSS Animations, or something -- these show up in the DevTools animation inspector: svg.goog-te-spinner goog-te-spinner-rotator circle.goog-te-spinner-path goog-te-spinner-dash If I pause those in devtools, things get a bit better. Hiro, perhaps you could take a look?

Yeah, this is an *extremely* offscreen animation. We have: <div class="goog-te-spinner-pos"> <div class="goog-te-spinner-animation"> <svg class="goog-te-spinner" ...> The outer div there has: .goog-te-spinner-pos { position: fixed; left: -1000px; top: -1000px; } And the inner div has: .goog-te-spinner-animation { opacity: 0; } So by virtue of both of those things (the offscreen position and the 0 opacity), we'd ideally want to be able to optimize away the animation. We have at least bug 1427033 filed on the opacity part -- not sure if there's more we can do here beyond that. It looks like the animated thing here is a "throbber" for a Google Translate button (which never actually shows up on the page, because of the styles quoted above -- perhaps they don't show it because I'm already using English so no translation is necessary). I wonder if this crops up on every page that uses this API, or if caltrain is just misusing the API somehow? Either way, perhaps worth looking into whether this is a common problem for other sites that use this same "Google Translate button" API...

> Hiro, perhaps you could take a look? (I mostly answered my own curiosity a few minutes later, but I'll leave this needinfo open in case you'd like to take a look & can find anything else here. But for now I'm betting this is waiting on bug 1427033.)

I was wondering why the animation on position:fixed element is not throttled properly since we've already optimized the case (bug 1421507). Now I understand the reason, that's because of bug 1430884. The keyframes in question is; @keyframes goog-te-spinner-dash { 0% { stroke-dashoffset:187 } 50% { stroke-dashoffset:46.75; transform:rotate(135deg) } 100% { stroke-dashoffset:187; transform:rotate(450deg) } } There is no transform value at 0% keyframe. So we can't properly handle it yet, unfortunately.