Update Aug 6, 2015: Not necessary, alternate solutions provided in comments.

If a DOM changes, and nobody is looking at it, does it use memory and power?

My assumptions are yes. This proposal is for people like me who regularly have 20+ tabs open.

Problem

We keep a lot of tabs open that we don’t need to be active all of the time. Some of these tabs can be using a lot of memory and/or power.

For example right now you might have tabs open for gmail, some Google docs, Facebook, medium, a bunch of articles you’ve been waiting for the right time read, some Github projects that look interesting, etc.

In the near future you might have tabs with asm.js-based games and applications running in them.

You have them open because you want to get back to them eventually, or you want the notifications, but you don’t necessarily need the whole web page running while they are in the background.

Proposal

There is some new API introduced to browsers that, when used, it tells browsers:

1. This page allows for the DOM to be suspended.
2. What Javascript to run when the DOM is going to be suspended because it has been an inactive tab for some amount of time.
3. What to Javascript to run when the user returns to the tab and the page DOM is returned to life.

Example API

Note: Not a suggestion of what the API should look like, just an example to help with understanding. The actual API might need to be more like a service worker.

// keep checking for new email, post notifications when email comes in
window.onsuspend = fn;  

// update DOM with changes since it was suspended
window.onreanimate = fn;

Backwards compatibility

Browsers without this feature will ignore this and always have a DOM rendering.

Shim concept

1. Listen for user interaction on the body.
2. On some timeout with no interaction, save body.innerHTML to a variable.
3. Set body.innerHTML to null (or whatever the best way is to remove free up memory by removing DOM nodes and their listeners.)
4. Call window.onsuspend
5. When user interaction on the body starts happening again, set body.innerHTML to the value from the above variable.
6. Call window.onreanimate.

Downsides

The reanimate function might need to bring back all of the listeners from before the DOM was destroyed and update the DOM with any state changes that happened during its suspension. This can be relatively straightforward with frameworks like React or Angular, but is possibly too much work in a pure jQuery environment.

Iframes might be difficult or impossible to handle correctly. Ideally an ad displayed before suspension will be the same ad in the same state after suspension, but this might not be feasible. This might have to be a compromise of this feature.

Real-world examples

I don’t know of any real examples of this feature.

Memory and Power usage of inactive tabs today

I recognize that, as part of this proposal, one should provide a table of memory and power usage of inactive tabs for popular sites today, covering various browsers, to show potential for improvement. I could use help with this, as I’m not sure how to measure power usage on a per-tab basis.

I would sort of like this, but I’m more doubting its going to happen. With this is happening. Also there are extensions like: OneTab, and The Great Suspender.

Are you aware of the Page Visibility API? It already has good browser support and sounds like it mostly does what you want. It fires events when the page goes in to the background or comes back to the foreground. It’s up to the JS handlers to stop any heavy processing and resume it in these events. In addition to that most browsers limit timers and rAF callbacks to once a second to reduce the activity of background tabs. One real world use case is we build a HTML5 game engine which pauses and resumes the game as the page goes in to the background, so it is not using up CPU processing the game when it’s not needed.

If you wanted to, you could code your visible/invisible event handlers to completely clear the page of DOM elements, but I’m not sure this is a good idea. You will trash all your event handlers, JS state, and so on. I think it is better to leave everything in memory, and if it’s not used and the system is low on memory, the OS will page it out to disk.

Yeah, this is a UA behavior, not a page behavior. As the TNW article @Edwin_Reynoso posted points out, Chrome OS has done this for a while (I know my 2GB ram Chromebook has done this since I first bought it).

Thank you for the insightful feedback @Edwin_Reynoso, @AshleyScirra, and @stuartpb!

I appreciate the detailed responses, links, and examples for why this is not necessary.

I am happy to drop this, thanks again!