> You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgr

> You shouldn't be expecting to queue up thousands of messages from potentially hours of the tab being backgrounded and handle them all when the tab is unbackgrounded. In this specific case, the games only lasted 3-4 minutes each and players were also timed-out after periods of inactivity. > Nor should you process all the state changes as they come in even though the tab is backgrounded - no user wants to spend data/power/cpu/battery/heat on something like that. In the case of games, players do expect multiplayer games to keep running (unless it is paused, and you can't usually pause multiplayer games). Yes, I agree that the game could optimize this AFK period, for example by disabling rendering, but game events should still be triggered in real-time and notify players (with sound at least) of what's happening. My point is, there are cases when a browser background tab should still run at 100%. Other examples: uploading a video to YouTube in a background tab, running a chess engine to get best move in a position, converting a video, etc.