Skip to content
This repository has been archived by the owner on Jan 18, 2022. It is now read-only.

Disable re-rendering the DOM for background tabs until they enter the foreground #30

Open
carcinocron opened this issue Jan 30, 2017 · 3 comments

Comments

@carcinocron
Copy link

My primary goal: save battery life and increase performance for users running Chrome and/or Firefox (or any browser that supports the appropriate APIs).

Recent discussion titled: "Chrome will aggressively throttle background tabs"

https://news.ycombinator.com/item?id=13471543

I run a real time charting platform for Bitcoin traders (like those using BitMEX) and the app does a lot of updating/refreshing. I recently learned of the visibilitychange API and managed to make huge improvements in the app's performance when running in the background - on the order of ~75% reduction in CPU usage when running in the background. [1]
var doVisualUpdates = true;

document.addEventListener('visibilitychange', function(){
doVisualUpdates = !document.hidden;
});
Basically, you can use this to determine if your tab is running "in the background" and avoid redrawing/refreshing components to show updates that won't ever be seen.
[1] https://twitter.com/cryptowat_ch/status/817502626896089090

What does Vue.js do when the tab is in the background (user is looking at another tab, might return in future). Chrome will throttle tabs that don't have active websockets/audio. I do have an active websockets on my application and I expect my average user to be slammed with DOM updates from websockets.

  1. Does Vue.js hold all DOM updates until the user returns to the tab?
  2. Can there be a mixin or other type of plugin for this?
  3. If it needs to be handled outside of Vue.js, how?
  4. What is the browser support for each solution?
@LinusBorg
Copy link
Member

LinusBorg commented Jan 30, 2017

Interesting Question. I think the right layer to solve this would not be Vue's DOM updates, but the data updates.

If we somehow halt the DOM updates, it will be very complicated to somehow cache them and do them all as soon as the tab is active again.

I expect my average user to be slammed with DOM updates from websockets.

I assume what is really happening is the user being slammed with data updates from the websocket, and then DOM updates happen due to Reactivity recognizing those updates, right?

So this could be solvable quite easily if you use vuex. We could overload the store's commit method to cache all incoming calls when the tab is in the background, and only apply them when the tab is visible again.

Made a quick PoC: https://jsfiddle.net/Linusborg/swaeed82/

We could possibly extend this with a blacklist or whitelist for certain mutations to keep other functionalities working.

@akarelas
Copy link

akarelas commented Jul 7, 2017

I've done this for my own project. If I find time, I'll upload it as an npm package this weekend, or next week.

@akarelas
Copy link

akarelas commented Jul 7, 2017

It's not that hard, by the way... Caching, re-activating the updates, etc... I did it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants