What about multiplayer? Will I have to resync the whole state every time the user tabs away?
No, syncing is transparent and automatic, and there is nothing you can do to affect it anyway, it's all handled by the engine. The host will send all objects at least twice a second regardless of whether they changed. (This uses little bandwidth and is generally not a performance concern, especially compared to changing objects being sent 30 times a second.) If the user tabs away and the game freezes, then they tab back, the peer will get a full-state update from the host within 500ms. It's the same thing that happens for late-joining peers, they'll get the update very soon after joining and everything will appear in its right place. The game freezes but the browser does maintain background connections so the player is not disconnected.
For hosts it's a different matter and I didn't really want to talk about it because it breaks my own rule Since the host is basically the game server and has the authoritative state, switching tab would freeze the entire game for all connected peers. That basically ends the game; if you have 20 people connected, tough, all 20 people freeze. This is pretty bad and would mean casual gaming where people tend to flip tabs a lot would be prone to regular freezing. To avoid this I implemented a hack - for hosts only - where it keeps the tab alive in the background. Yes, this drains battery faster, but it is basically necessary if the tab is acting as a multiplayer game server, and I don't think it's worth ruining the game for everyone just to save a bit of battery in that case. Also it allows dedicated servers to run multiple hosts in different browser tabs. I think that's a special case and the only reason a tab should be kept alive in the background, so it's deliberately not supported for anything else. For all other purposes you should just compare the time that was spent suspended and play catch-up, and not waste battery.