I see this with the console at least when developing. You switch back to the tab and the console eats shit and locks up because of the back pressure.

the nice thing with the web is that developers respond reasonably fast (much faster than desktop apps) to changes like this in major browsers...

This a good point. The application does x amount of work per second in the background. Your browser pauses it for y seconds. According to Google you have saved "x times y times energy per operation". Chrome devs say hurray 5x energy savings. Except when you switch back to the tab you end up spending the same amount of energy to catch up.

The primary source of energy savings would be poorly written websites that constantly poll in the background. Games with complicated logic would still consume the same amount of energy.

(Chromium dev here.)

For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc).

Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage.

> The primary source of energy savings would be poorly written websites that constantly poll in the background.

This is the key insight here, and really what we're going after. There is a lot of this on the web.