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.