Your Camera Tab Is Not a Monitoring Session: How Chrome Throttles, Freezes, and Discards the Page You Left Watching

Short answer: Guides to running a spare Android as a camera treat the viewer as free: the phone runs a small web server, you open a link in an ordinary browser, done. That part is true. What nobody writes down is that the viewer has power management too. To a browser, a camera view is a hidden tab burning CPU while nobody looks at it, which is exactly the profile browsers are now built to suppress. Timers get throttled, Chrome freezes eligible CPU-intensive pages outright when Energy Saver is on, and Memory Saver discards it entirely — and a discarded tab keeps its title and favicon in the tab strip. The last picture rendered stays on your screen. If the room is quiet, a stopped stream and a still room are the same image. All of it is checkable at chrome://discards, and none of it is a bug.

The phone side of this is well-trodden ground: a small server on the handset hands frames to anything on the network that asks for them, and it keeps doing that with the display dark. Assume all of it works perfectly.

Then you get up from the laptop.

The claim being made, and the claim not being made

The claim: a browser tab is not a monitoring session. It is a request you made once, on a machine entitled to decide you are no longer interested.

Not the claim: that your stream is broken, that the phone stopped, or that any app is at fault. The phone is almost certainly fine and its file almost certainly still growing. This is about the second machine — your laptop, the kitchen tablet, the workshop monitor — and it applies to every product here that serves a browser-viewable stream over a LAN.

It is also not a slow link. I have written about what the server should do when a viewer cannot keep up; that is a server-side problem with a server-side fix, it produces a behind picture, and it recovers by itself. What follows produces a stopped picture that does not recover until a human touches the tab.

Three mechanisms, escalating

1. Throttling — every browser, no settings involved

This is the oldest and most universal layer, and it is not Chrome-specific. From MDN's Page Visibility API documentation, describing the policies user agents apply to hidden tabs:

• "Most browsers stop sending requestAnimationFrame() callbacks to background tabs or hidden <iframe>s in order to improve performance and battery life."
• "Timers such as setTimeout() are throttled in background/inactive tabs."

The throttle is budget-based and the numbers are specific: windows are subjected to throttling after 30 seconds in Firefox and 10 seconds in Chrome, timer tasks are only permitted while the budget is non-negative, and the budget "regenerates at a rate of 10 ms per second."

Ten milliseconds per second. A viewer page doing real work on a timer — polling for a frame, redrawing a canvas, updating an overlay — is now doing it at roughly one percent of its designed rate.

Note the exemption list, because it is the shape of every list here:

• "Tabs which are playing audio are considered foreground and aren't throttled."
• Tabs using "real-time network connections (WebSockets and WebRTC) go unthrottled."
• IndexedDB processes are left unthrottled.

A muted picture arriving over plain HTTP is on none of those lists. (Yes, a page could stay unthrottled by playing a sound. That is a workaround, not a design.)

2. Freezing — Chrome 133 and later, when Energy Saver is on

Chrome announced freezing on Energy Saver in January 2025: "From Chrome 133 (February 2025), eligible CPU-intensive background tabs will be frozen when Energy Saver mode is active."

Freezing is stronger than throttling. Per that post, it "suspends task execution on a web page":

• Event handlers (for example, input, network, and sensor)
• Timers
• Promise resolvers

Network event handlers. Not a connection closed with an error your page could catch — the handlers that would have processed the bytes simply do not run.

The conditions are worth reading closely, because a camera-viewing tab satisfies all of them without trying:

• "All pages within the group have been hidden and silent for more than five minutes." A camera view is hidden the moment you switch tabs, and silent by default.
• The group is "CPU-intensive." Continuously decoding and painting incoming frames is close to a textbook example.
• And the group must not "provide audio or video conferencing functionality (detected using microphone, camera, screen/window/tab capture, or an RTCPeerConnection with an 'open' RTCDataChannel or a 'live' MediaStreamTrack)."

Read that last one again. The carve-out is for pages that produce media, not pages that consume it. Microphone, camera, screen capture, a live outbound track — the fingerprints of a video call. A video call has a person sitting in front of it. Nothing in that list describes a page whose whole job is to show you a room you are not in.

The remaining exemptions are Web USB / Bluetooth / HID / Serial, and holding a Web Lock or blocking IndexedDB connection. Controlling a device, or holding a lock. Still nothing for watching.

The documented escape hatch is an origin trial, which Chrome says "will be discontinued once new APIs for declaring important background work are released." It is equally explicit about direction of travel: "Chrome will therefore expand tab freezing to more situations."

3. Discarding — Memory Saver, and the one with no event at all

Freezing keeps the page in memory. Discarding does not. From Chrome's Memory and Energy Saver guidance: "When Memory Saver mode is enabled, Chrome will proactively discard tabs that have been unused in the background for some time."

Then the sentence that matters for anyone building a viewer:

"When a tab is discarded, its title and favicon still appear in the tab strip but the page itself is gone, exactly as if the tab had been closed normally."

There is no warning you can act on. Chrome says so directly: "there is no event that fires when a tab is discarded, so there's no way for developers to react to the fact that it's happening," and "a tab can get from the 'hidden' state to the 'discarded' state without any events firing." beforeunload, pagehide and unload do not fire. You find out afterwards, on reload, via document.wasDiscarded.

A milder item from the same document: with Energy Saver on, "Chrome conserves battery power by reducing the display refresh rate, affecting scrolling and animation fidelity and video frame rates."

Why this lands harder on a camera than on anything else

Every one of these behaviours rests on one reasonable assumption: a hidden tab is a tab nobody needs right now. For a news site, a spreadsheet, a half-read thread, that is correct almost every time.

A camera view is the page where it inverts. The whole reason it is open is that you are not looking at it. You minimised the window and went to a meeting; the picture is supposed to be there when you glance back. "Hidden" and "unwanted" have come apart, and the browser cannot tell.

Compare it to a phone-side failure. When the phone-side goes wrong there is usually something to find: a stopped service, a gap in the file list, a recording that will not open, a clock that drifted or repeated an hour. When the viewer goes wrong there is nothing to find, because nothing went wrong. A frozen tab is still loaded — Chrome is explicit that freezing "is different from discarding, where a tab is unloaded from memory" — so it is a tab in every way you can see. A discarded tab also looks like a tab. And the last frame the page painted is still on your screen, indistinguishable from a live picture of a room where no one is moving.

That is the cruelty here: the failure mode of a live view is a photograph.

The honest limitation, stated plainly

I do not think Chrome is wrong, and I am not going to pretend otherwise to make a cleaner story.

On a laptop running on battery, a hidden tab consuming CPU is a bug the overwhelming majority of the time. The exemption lists — capture APIs, device APIs, locks — are a sensible attempt to enumerate "this page is doing something the user actually asked for," and the five-minute delay, the CPU-intensity requirement and the Energy-Saver condition are all conservative.

The gap is narrower than "browsers are hostile." It is this: the convenience that makes a LAN camera pleasant — no second app to install — is bought by making the viewer a general-purpose browser tab, and that tab comes with a general-purpose browser's opinion about your attention. That is a cost of the architecture rather than of any particular product, and a cheap one to work around once you know it is there.

The test

Do not test whether the tab is open. Test whether the picture is current, and make the picture able to answer that.

1. Put something in frame that carries the time — a cheap desk clock, or a second phone with the clock app open, propped in shot. That is the whole trick: a picture containing a clock can be interrogated; a picture of a room cannot.
2. Open the view on the machine you would really use, then background it. Switch tabs, minimise the window, let the display sleep — MDN defines a document as hidden when its tab is in the background, when the window is minimised, "or because the device's screen is off," so all three count.
3. Do something else for an hour.
4. Come back and, before touching anything, read the clock in the picture and compare it to the real time.

If it says an hour ago, you have measured your own viewer on your own hardware with your own settings. Do it once per machine you intend to watch from; the answer differs between a plugged-in desktop and a laptop with Energy Saver on.

What to do about it

Ranked by how much they actually help.

• Treat the viewer as disposable and the file as the record. The only structural answer. The recording on the phone's own storage survives your laptop's opinions; a live view does not. Looking is not logging. If something must not be missed, it has to be recorded on the device, not observed in a tab.
• Reload before you trust a glance. A refresh costs a second and removes the whole class of problem. Press reload first, read the picture second.
• Foreground the machine that matters. If a screen is genuinely dedicated to this — a kitchen tablet, a workshop monitor — keep the view as the visible tab of a non-minimised window and stop the display sleeping. That is the ordinary meaning of "visible" and it sidesteps everything above.
• Turn Energy Saver / Memory Saver off there, or exclude the site. Chrome lets users tell it not to discard specific sites — a user preference, not something a page can set for you.
• Verify rather than guess. chrome://discards shows a tab's freezing eligibility and lets you force a discard, the fastest way to see what your viewer does on the way back.

Questions worth asking of any browser-based camera viewer

If you are choosing one, or building one:

• Does the page notice it was hidden and rebuild the stream on return, or does it assume the connection it opened is the connection it still has?
• Does it check document.wasDiscarded on load, and say so when the view was rebuilt?
• Is there anything in the picture itself that separates a live still room from a stopped stream — a timestamp, a frame counter, a moving element?
• Does it fail to an obvious error state, or to the last good frame? The last good frame is the friendlier-looking choice and the more dangerous one. (What a second viewer costs and what recording and streaming at once costs are separate phone-side questions, both worth reading first.)

None of this is exotic. It is one habit, applied to the machine nobody applies it to: a tab being open is a fact about your window, not a fact about the room. The status bar, the tab strip and the favicon are all reporting on the request you made an hour ago. Only the picture can tell you about now, and a picture can only tell you that if there is a clock in it.

---

Related: how the phone serves its own view over your LAN, and what "local-only" does and does not buy you.

I build Background Camera RemoteStream. Longer pieces at superfunicular.com.