12

I've got a page that shows real-time statistics. It runs a lot of javascript, makes a lot of HTTP requests, renders SVG charts every few seconds using D3.js, has a lot of CSS animations, and rearranges the DOM frequently.

As long as the page is focused, it runs smoothly. If I switch to another tab and come back later, there's often a short pause where the page seems to be frozen before the view suddenly seems to rerender and the page becomes usable again. The longer the tab has been backgrounded, the longer this pause is. If the tab has been in the background for a very long time (hours) and I switch back to it, it will be frozen for a long time then crash.

All these behaviors are observed in Chrome. I haven't tested much in other browsers.

What isn't Chrome doing while the tab is in the background, and what is it doing during that pause when I first switch back to the tab?

UPDATE:

I'm also doing some jQuery animating. This answer and this one may be relevant.

According to that first answer:

"Inactive browser tabs buffer some of the setInterval or setTimeout functions."

stop(true,true) will stop all buffered events and execute immediatly only the last animation.

I've added a call to .stop(true, true) in my code, and at least for short trips away from the tab, I'm not detecting a hiccup. I need to leave it in the background for a long time and test it before I can tell if it made significant difference.

Community
  • 1
  • 1
Trevor Dixon
  • 23,216
  • 12
  • 72
  • 109
  • You can have dev tools open and monitor your page when its on current tab. – Mohsen Nov 16 '12 at 00:30
  • One thing that's for sure, it doesn't run `requestAnimationFrame` handlers when it's in the background – Ruan Mendes Nov 16 '12 at 00:31
  • 1
    Could you set up a test case of some sort? – Asad Saeeduddin Nov 16 '12 at 00:31
  • 1
    At least setTimeout() is throttled in modern browsers, not only Chrome. So you can't use it as a reliable time source (even on foreground). But most likely you are leaking memory or system (graphics) resources in your Javascript and when you switch the Chrome tab process on foreground it does some sort of garbage collection or tries to page in all the paged out RAM. Check your system memory usage and chrome memory usage before switching back. – Mikko Ohtamaa Nov 16 '12 at 00:40
  • What happens if you leave the tab on foreground for long time? – Mikko Ohtamaa Nov 16 '12 at 00:42
  • It seems to run fine in the foreground for as long as I let it. – Trevor Dixon Nov 16 '12 at 00:42
  • 1
    I also faces a similar issue in chrome when implementing animations. The reason is that it optimizes its tabs not to do rendering while not in focus. So the issue of application crash might be happening since your application logic has lot of overdue things to do when you focus on it which takes lot of time and freezes the application. – Ashan Nov 16 '12 at 00:30
  • Is there a source for that? I find it rather silly to stack rendering commands and then executing them all instead of just executing the last one. – Saturn Nov 16 '12 at 00:34
  • 1
    Look at the following http://paulirish.com/2011/requestanimationframe-for-smart-animating/ "if you're running the animation loop in a tab that's not visible, the browser won't keep it running" – Ashan Nov 16 '12 at 00:46
  • I already mentioned that in my comment – Ruan Mendes Nov 16 '12 at 00:49

2 Answers2

11

We had a similar issue with SVG graphs and managed to solve it using Page Visibility API introduced with HTML5. If anyone stumbles upon such an issue please refer to the following article Using the Page Visibility API

What we managed to do was to suspend all SVG rendering activities when the browser window is not visible. This managed to stop the tab from crashing.

Lasitha Petthawadu
  • 753
  • 5
  • 18
2

Yes, it's typical behavior of Chrome browser.

I guess that while your tab is in background, Chrome places all tab data on "back shelf" to clear "front shelf" that works much faster. I know, it sounds unprofessionally, but i hope that you understood.

I think it is very hard to solve this problem in your case (because you are using a lot of manipulations with graphic).. but maybe this method will save you (i had never tested it before):

Every time you update your statistics (or do some highload calculations), you can save a timestamp. Then, when you update your statistics again, you can substract that old timestamp of the new timestamp. And, if you see that the difference between timestamps is very big, use setTimeout() function before next update. Maybe, it will prevent Chrome's chash.

bonbonez
  • 6,658
  • 2
  • 15
  • 16