If you do a timeout polling like this, it might be a good idea to bump up the timout to several minutes (not every 20 seconds like in the example code).
Peridically waking up an idle CPU just to check the time has a surprisingly big effect on power consumption. This might be a real issue if you have this page open in your smartphone browser but the phone is idle but not sleeping in your pocket.
Probably is actually, I'd expect there's little need to update the list if said list is not being looked at. On the other hand, it might be fairly costly while the system is being watched as it will fire (and do some check) on every single frame.
requestAnimationFrame may be too frequent in the foreground (could effect performance?), and not necessarily 0 in the background.
That repaint may occur up to 60 times per second for foreground tabs (the exact rate is up to the browser to decide), but may be reduced to a lower rate in background tabs.
I was under the impression that power mode switching took ~50 micro seconds, which means power savings modes toggle on an off between keystrokes.
The problem here isn't awaking the CPU, but rather awaking the radios. If you don't turn on the radios, polling every 20 seconds shouldn't be a problem. I'd mix this approach with something like the Page Visibility API, so you don't fetch data unless the site is the active tab.
Peridically waking up an idle CPU just to check the time has a surprisingly big effect on power consumption. This might be a real issue if you have this page open in your smartphone browser but the phone is idle but not sleeping in your pocket.