You can never rely on the timers firing exactly as you request, so you always have to take the delta since the last timer and use that in your calculations.

This is a very basic issues with doing stuff on a timer, and not that hard to do properly. It shouldn't make a difference if your timer is called once per second, once per minute or once in 10 hours in the background, you always calculate based on the delta to the last time your timer fired.

It can be an issue if the game can do complex actions at any time: if you then need to do all of it in one gigantic update after e.g. 24 hours of being in the background, it may take too long to compute that one long tick. Depending on what type of game it is. If it just has to compute "so many resources per second produced" it's easy of course and you can use the delta between last tick (if Date.now() works correctly), but if the game can auto-build various things with complex interactions, it can become computationally complex if it has to do all at once.

(Chromium dev here.)

Doing the work in one giant update is actually better from a power consumption / battery point-of-view, because the CPU cost is fixed but there are fewer wakeups overall.

Note that the new throttling logic means you get woken-up once per minute; we're not talking about preventing your page from doing work for a 24 hour period.

For full details of how the throttling works, see here:

https://www.chromestatus.com/feature/4718288976216064

It sounds like the tab throttling is working as intended then. If I've moved from your game and haven't looked at it then why shouldn't all of that extra computation happen until the next time I'm interested?

For idle games, much of the point is investing in auto-building, then coming back to the game when your investment has borne fruit. For this to work, it has to be able to run in the background.

There is a big difference between throttling and not running. Still, it is probably much better to sync with the server than run something at full blast to increment some counters.

Sounds like it's time for the game authors to provide some servers with the compute resources to do this background processing.

But if it lies about Date.now() this isn't possible..

That would be broken and isn't what is being talked about here. There is no reason scheduling as a low priority would mean you need to lie about the current time.

That is a very good advice, thank you.

What do the background tabs do with server side events or websockets? You should be able to just open a connection and send a message over WS or have the server drop the connection on every tick. You can probably do it without a server by hitting an address that will blackhole the connection instead of refusing it and use an AbortController [1] to timeout the request.

[1] https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

The question is mainly about a client-side game, no multiplayer or servers.

Here is some context (just a random thread about the issue, threads like this pop up regularly):

https://www.reddit.com/r/incremental_games/comments/j86u5m/g...

5 years ago such games worked in background tabs. Then browsers started throttling background tabs (for understandable reasons) and everyone learned to keep it in a foreground tab in a window you don't use. Now the latter will also stop working.

I'm tired of too-smart browsers, I want a dumb one.

Do service workers continue running?

(Chromium dev here.)

Yes, for now all workers continue to run unthrottled (shared, dedicated and service). They may also be throttled at some point, but we have no firm plans around this yet.

Didn't test (yet), but if they do, then what's the point of throttling background tabs?

(Chromium dev here.)

We don't throttle workers (that could change, but we don't have firm plans here yet).

All things being equal, if you move complex work to workers we're happy because it frees up the main thread to handle input events, compositing, etc. Just because your tab is in the background doesn't mean your renderer process isn't sharing a main thread with a tab that is in the foreground, so in this case it can improve foreground tab performance.

Also, spreading a fixed amount of work across more cores and fewer wake-ups is actually more efficient from a power point of view (assuming the wake-ups are synchronized).

Service workers have restrictions on what they can do. They can't interact with thr dom and a few other things to keep them from causing rendering or other changes.