On iOS, both in native and web applications, there's a notion of "what's in front gets resources". If a web page or app isn't on screen, it's using little or no CPU time. They also have a reduced memory footprint. I think this notion should be extended to the desktop version of Safari/WebKit. Many users on the desktop end up with a lot of windows and tabs. It's not uncommon for me to have dozens, and I have friends who end up with hundreds (**cough** Siracusa **cough**). The web is a wonderful research tool, and as a result, we end up with a lot of "mind state" in the form of tabs. To deal with this, many folks with tab glut have resorted to tools like this: https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg?hl=en I think the developers of the browser itself could do a lot better job at suspending tabs. Tabs become inactive because its container window is no longer frontmost or because it's replaced by another tab. When this happens a tab could be replaced with a picture of the content, it's process spun down, and memory resources deallocated. Yes, there is probably a cost to replace that picture and restart the process when the tab becomes active again, but it would be much more bearable than overall system sluggishness and crashes associated with resource abuse. It's also going to save me time hunting down com.apple.WebKit.WebContent processes that are hogging the CPU and memory. Yes, it will probably break some websites. Just like getting rid of Flash did, but that turned out great in the end. Getting JavaScript developers into the same mindset as iOS developers would lead to a better web experience for everyone. If you know that Safari isn't going to run your script while it's in the background, you code accordingly. I could also see this behavior as a user preference - one that self-reinforces. One of the times when I accumulate the most tabs is when I'm doing HTML/CSS/JavaScript development. I'm going to benefit from this change at the same time my code is being affected by suspension. As more developers learn why this is good for them, and for others, you could eventually turn this user preference on by default. Thanks for your time in considering this proposal!
<rdar://problem/28593512>
Broadly speaking, WebKit already has this feature. It doesn't kill background tabs, but it does throttle background tab activity. We've done some benchmarking that shows that throttled background tabs use minimal CPU and memory (since they page out to disk and stay there). One way to move this conversation forward is to provide an example tab set that, when loaded in Safari Technology Preview, makes you have a bad time. We might find a simple bug in the existing throttling feature, or we might find a motivating example for some bigger design change.
What is the easiest way to collect a set of tabs that's misbehaving? I'm assuming there's a .plist or some other data file that maintains the window/tab state.
(In reply to comment #3) > What is the easiest way to collect a set of tabs that's misbehaving? I'm > assuming there's a .plist or some other data file that maintains the > window/tab state. Yup! Safari: ~/Library/Safari/LastSession.plist Safari Technology Preview: ~/Library/SafariTechnologyPreview/LastSession.plist The .plist updates about once every 10s.
Now that you've armed me with a small bit of knowledge, I'm experimenting with Safari and the Activity Monitor :-) When I load this page in Safari 10 (running on latest public Sierra), I see about 12-13% CPU usage: https://stripe.com/docs If I create another tab, and make it frontmost, the CPU usage drops down to well under 1% as expected. If I move the window to another space, I also see CPU usage go down. Awesome! However, if I create another window and make it frontmost in the same space, the CPU usage for the previously opened window/tab doesn't go down. Maybe the throttling needs to be applied to the frontmost tab of an inactive window, too. Personally, I tend to collect "ideas" in separate windows with multiple tabs. The Stripe site is me thinking about adding ApplePay to one of our commerce sites - it's the frontmost tab in the window because it's the last thing I looked at. The problem is that I have eight other windows in that space: only the frontmost one is collecting my current work. The Stripe tab is churning away with no benefit to me, it's hidden by a bunch of other windows, and I'm still using Activity Monitor to find battery killers. I hope this info is useful - I'm really glad you folks are thinking about this issue!
(In reply to comment #5) > If I create another tab, and make it frontmost, the CPU usage drops down to > well under 1% as expected. If I move the window to another space, I also see > CPU usage go down. Awesome! FYI minimizing the window to the dock should work too. > However, if I create another window and make it frontmost in the same space, > the CPU usage for the previously opened window/tab doesn't go down. We will also apply throttling if the window is fully occluded. If you create another window and arrange it such that it completely hides the previous window then you should see CPU drop. This should work with a single large window, or if multiple smaller windows (of any app) are tiled to cover the first window. This means that if you have a stack of windows open there is a good chance that any Safari windows deeper into the stack will be getting full force throttling applied to all tabs, including frontmost. For tabs where something is animating we assume this may be desired behaviour, and do not apply any throttling. E.g. you might have arranged your windows such that you can watch a video in a background-but-visible Safari window while actively working in another window that is frontmost. But for any tab where there are no user visible changes for ~45 seconds a softer version of the throttling mechanism should be kicking in. The Stripe page is not changing and ought to be benefiting from this – however this doesn't seem to be working – CPU usage does not appear to improve after 45s. It looks like either the throttling of visually idle pages is not kicking in for this page, or is triggering as expected but the more restricted throttling is ineffective at curbing CPU in this case. Either way, this is something we should investigate. <rdar://problem/28627484> Also, this page should not be using 10%+ CPU to do nothing. We should investigate. <rdar://problem/28627458>