如何检测并处理浏览器标签失焦/锁屏时的定时器节流与WebSocket断开？

Great question—this is a super common pain point with PWAs and real-time apps when they go into the background. Let’s break down each part of your problem with actionable info and solutions.

Every major browser has unique rules for handling background tabs/apps, driven by energy and memory conservation:

• Chrome/Edge: Background tabs get throttled after 30 seconds. Timers are capped at ~1 execution per second. WebSocket connections may stay alive but with reduced priority; after several minutes of inactivity, the browser might terminate the connection to save resources.
• Firefox: Similar timer throttling (1-second interval cap) after a short background period. WebSocket connections are maintained but may have increased latency. It also has a tab unloading mechanism for low-memory scenarios, which can terminate the JS context entirely.
• Safari (desktop/mobile): Aggressive throttling. Timers are suspended almost immediately when the tab is hidden. WebSocket connections are often disconnected after 30 seconds to 1 minute of background state. On iOS, the entire JS thread pauses after a few seconds in the background, killing all timers and WebSocket connections.

Let’s dive into the specific behaviors you’re encountering:

• Timers: All modern browsers throttle setTimeout and setInterval in background tabs. Chrome, Edge, Firefox limit intervals to 1000ms. Safari goes further—timers are effectively paused until the tab becomes visible again.
• WebSocket: Behavior varies widely. Chrome may keep connections open but reduce ping/pong frequency. Safari is the strictest, closing connections after short background periods. Some browsers also throttle incoming messages to save bandwidth.
• JavaScript Execution: Background tabs have limited JS execution time per second. Non-critical tasks are deferred, and long-running scripts may be terminated to conserve resources.

Absolutely—this is the standard, cross-browser way to detect when your app moves between foreground and background. Here’s a practical implementation:

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    // App is hidden (tab switched, locked screen, etc.)
    console.log('App entered background');
    // Pause non-critical timers, adjust WebSocket heartbeats
    saveAppStateToLocalStorage();
  } else {
    // App is visible again
    console.log('App returned to foreground');
    // Resume timers, trigger reconnection + state sync
    restoreAppStateFromLocalStorage();
    checkWebSocketConnection();
  }
});

You can also check document.visibilityState directly, which returns 'visible', 'hidden', or 'prerender' for pages loaded in the background.

To reliably test these scenarios:

• Desktop Testing:
  • Log timer events (e.g., setInterval(() => console.log('tick'), 100))
  • Switch to another tab and wait 30+ seconds, then return to check if ticks are spaced 1 second apart (or stopped in Safari)
  • For WebSocket: Open a connection, send periodic messages, switch tabs for a minute, then verify if the connection is still active
• Mobile Testing:
  • Load your PWA, switch to another app or lock the screen
  • Wait 1-2 minutes, then return to check for disconnected WebSockets or out-of-sync timers
• Dev Tools Simulation:
  • Chrome/Edge: Use DevTools > Performance to enable CPU throttling, and the Rendering tab to simulate hidden state
  • Safari: Use the "Simulate Background Tab" option in the Develop menu

Here are practical steps to fix state recovery and background behavior:

• Leverage the Visibility API:
  • When going background: Pause non-essential timers, increase WebSocket heartbeat intervals, and save critical state to localStorage
  • When returning: Resume timers, check WebSocket status, and request a full state sync from the server to catch up on missed updates
• WebSocket Reconnection & State Sync:
  • Don’t rely solely on auto-reconnect libraries—implement a custom sync. When reconnecting, send a request for the latest full state instead of incremental updates that may have been lost
  • Adjust heartbeats based on visibility: In background mode, send pings every 30s instead of 5s to avoid being flagged as inactive
• Timer Adjustments:
  • Replace UI-related short intervals with requestAnimationFrame (it pauses automatically when hidden)
  • For critical timers, use postMessage instead of setTimeout—some browsers don’t throttle postMessage as strictly in background tabs
• Service Worker Support:
  • Service Workers can run in the background to handle push notifications, and you can use them to trigger a reconnection or state sync when the app is brought back to the foreground

内容的提问来源于stack exchange，提问作者Kev