Keeping a tab awake

Can you keep a hidden tab awake?

Browsers put hidden tabs to sleep, which is sensible until your game is about hidden tabs. So before building this one, we measured how reliably a server could reach a tab nobody was looking at.

What browsers do

Chrome slows a hidden page's timers in stages. Once a page has been hidden for over five minutes and has been silent for at least 30 seconds, chained timers can be checked as little as once a minute. A silent audio track doesn't count as sound. Beyond throttling, browsers can also freeze or discard a page entirely, at which point nothing in it runs.

So a timer in the page can't be trusted to ring on time. We keep the schedule on the server instead, and send each call two ways: over a WebSocket, and as a Web Push notification, which is delivered to a service worker even if the page can't respond.

What we tested

We sent real calls to real Chrome and Edge, in hidden tabs, on one Windows laptop that was plugged in with the screen on.

• Delivery: four setups, 1,000 calls each. Every call raised an alert within 30 seconds, and the slowest 5% took over 0.3 seconds.
• A full working day: one eight-hour hold each in Chrome and Edge, 312 calls in total. A script answered 311, with the last apparently still ringing when the script hung up. 95% of alerts arrived within 0.5 seconds.
• Silence: a 50-minute run with hidden tabs sending a check-in every 30 seconds. The longest gap we measured was 30 seconds.

What went wrong

The results above leave out the most interesting part.

• Power saving won. During one stretch of the delivery test, Windows Modern Standby cut the network and 419 calls went missing. We excluded that outage from the figures above, and you should know we did. Nothing in a web page can stop this, so we ask players to stay plugged in with the screen on.
• Sockets die for no visible reason. WebSockets closed roughly every 20 minutes, in hundreds of cases, and we still can't explain why. In the delivery test, the socket missed three calls that push delivered instead, and in the eight-hour run a notification got through for a call the page never heard about. Without the second route, those would have been lost.
• A dead network looks alive. When we turned Wi-Fi off, the server didn't notice: the socket simply went quiet. Only the page's regular check-ins reveal the silence, so we treat 90 seconds without one as a lost line.
• iPhones don't play along. Safari on an iPhone won't send notifications from an ordinary web page, so there the page has to stay open in front of you.

What this doesn't prove

This was one laptop, on mains power, with scripted browsers rather than people. Zero misses in 1,000 calls still fits a true reliability as low as about 99.7%. We didn't test battery power, Energy Saver or Macs, and browsers change this behaviour over time.

If you need a hidden tab to stay useful

• Keep anything that has to happen on time on a server. The page should be told, not trusted to remember.
• Send anything important by two routes. WebSocket and push failed at different times for us.
• Send a heartbeat from the page and measure the gaps, since a socket that looks open tells you very little.
• If your page makes real sound, it's treated more gently. Don't rely on that alone.
• Tell people about power saving. It's the one failure you can't engineer around.

You can try the result, which is a game about exactly this: Don't Close the Tab.