I'd honestly like to be able to "freeze" a page entirely once it fully appeared in the browser window. A good percentage of web pages both take all my CPU and become unreadable halfway through the page.
A big factors seems to be that the pages that are built out of layers of active advertising devices - a given advertiser isn't concerned that they're one of ten monetizing devices pasted onto a gvien page.
And there's the way pages have disincentive to play nice - a page that barely works with only it open trains users to avoid other pages.
Check out The Great Suspender [1] - not quite what you mean, but it basically unloads the tab and replaces it with a bare bones placeholder after it's been inactive for a bit. When you come back to it, you just click the link and it reloads the url that it had. Super handy if you're in the habit of leaving a few windows with a few dozen tabs each laying around, as I do.
I suspect the development is now suspended (heh) in favor of The Great Discarder [1], which uses Chrome's new "discard" api's for improved performance.
The problem with uMatrix is that many sites that rely on third-party Javascript will silently fail (i.e., not load, or show a "loading" animation that never ends), so you need to remember to turn it off for such websites.
It helps if you open uMatrix every time, see what third-party CDNs are used, give them necessary permissions but not more (only images if they don't need a script, no cookies unless it's necessary, etc), and put them in the whitelist. It's a bit of work in the beginning but after a while almost all new pages you'll come across will run fine.
I'm not sure this would have the outcome you'd want. A HN page is simple, loads and the DOM isn't really altered, so no real gain. Some pages alter the DOM significantly just when scrolling, or even wait to request content until you get there. The harmful sites would probably just break, but in a different way.
Still hasn't been released as a Safari extension and that's an absolute must since other browsers murder macOS battery life, often cutting it short by 2-4 hours.
>Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC
How long before a "performance best practices" guide suggests leaving a websocket open to ensure snappier page responses when users switch to your tab.
That would get annoying soon. You won't want your browser to ask for that permission or throttle page layout to use 1% of a single core during page loads or the moment that browser-based shooting game gets lively and requires fast reactions, for example.
I think it would be better to give each tab a power budget that, initially, allows it to run for S seconds at full power, and that give it new budget at a rate of x < 100% of max power every second.
However, I fear that still won't be enough. The list of heuristics and exceptions could get so long that the resulting benaviour becomes difficult to explain.
Initial page load and rendering should be excluded from any quota.
After that the browser should automatically throttle and provide an API to let the web app ask for permission to use more CPU, similar to how geolocation works today.
I don't see why this should be too complicated from the user's point of view. We're not talking about hard limits or real time guarantees. Browsers have a lot of wiggle room on the implementation side.
Define where "initial page load and rendering" ends for a single-page web application. When the DOM becomes stable at the login screen? After the login? The moment the user starts interacting with the page?
Also, how does one control what set of pages a given permission applies to? Exact URL often will be too limited, entire domain too coarse.
Allowing a page to use lots of CPU after every user interaction may be a way out, but if you do that, you don't need the explicit permission system.
[I also think the way browsers handle those geolocation permissions already is too complex for many users. They will simply learn "click 'allow', and things will work; click 'forbid' and things may break"]
>Define where "initial page load and rendering" ends for a single-page web application
It's not hugely important. It could be DOMContentLoaded + x seconds. It could be onload unless it doesn't fire within a reasonable amount of time. As long as the browser starts throttling within seconds I don't care much about the details. Login is not a concept I find relevant in this context.
>Also, how does one control what set of pages a given permission applies to?
It should apply on a per-domain basis. That may be too coarse in some cases but nothing is perfect. Let's go for good enough.
Would love this, or the ability to "throttle" similar to limits set on network bandwidth. So many times I come back to my server to find cpu high and it's caused by one or two web pages doing god-knows what. They don't even appear complex pages.
Then after some years will come a Google AMP for background tabs, then there will be complain that it went too far, then .... everything goes in loops. :)
I have switched to The Great Discarder, by the same developer.
Advantages over The Great Suspender:
- More memory savings
- Compatible with chrome tab syncing
- Super lightweight extension that uses no content scripts or persistent background scripts
Disadvantages over The Great Suspender:
- No visibility on which tabs have been suspended
- Unable to prevent a tab from reloading when it gains focus
I just switched to The Great Discarder from The Great Suspender. You probably want to resume all suspended tabs back, because if you will remove The Great Suspender extension suspended tabs will get closed.
Other then that it was what I always wanted from The Great Suspender (or the browser) in the first place.
As I enabled it, I got the normal warning about "This plugin can view all data" etc, and I started looking for a plugin that can show me what servers plugins are connecting to... it seems there is no such thing. Perhaps time to re-enable little snitch.
I wish this could be (maybe it already can be?) disabled for environments where I don't care about battery life/power consumption. This change probably saves me a fraction of a cent per month at the cost of a worse web experience (I'm a bit of a tab hoarder).
Good point, although I find that performance is always an issue—even when I'm plugged in. I'm also a tab hoarder (though more in Firefox, thanks to Tree Style Tabs), and I find that my Mac's sluggishness is always caused by having too many tabs open.
Sadly, my workaround has been to quit and re-launch browsers, which presumably has a similar effect to this update. Looking forward to seeing if the new version keeps things snappier...
Good for debugging an issue for sure but if you do any web-dev I'd shy away from disabling it for fear you might miss something that breaks on one of your sites because of it.
Not sure if any of you use "okcupid.com", but a single tab of that site will consume 4-5GB of RAM in a matter of an hour. Eventually grinding the entire browser to a halt, and nearly killing the OS in the process. There is a SERIOUS memory issue on that site, and it's always been that way for me. Safari, Chrome, Firefox on a Mac.
I don't use okcupid.com, but gmail, for me, leaks ~4KB per second, even under Chrome 57. Years ago I reported the issue, but it remains unresolved, and I've never received a response. It's not clear to me if it's a gmail issue or a Chrome issue. Either way, leaking 4KB per second is not a good thing. I've only had gmail open for about 2 hours, and it's already using about 325MB of RAM - and there's only 5 messages in my inbox.
Maybe Safari handles it differently, but I've left Okcupid on accidentally for hours at a time in the background and I've never noticed anything specifically memory hungry with it.
How much benefit is there in doing anything at all on a background tab? Would there be many use cases where simply suspending the background tab threads would lead to a much worse user experience?
I wouldn't mind having my background Netflix just stop, or having to wait a few secs for an interval refresh after bringing a tab to front.
But seeing as this seems an active area of research and debate I have a feeling that this solution has drawbacks I'm not considering...
There are use cases such as a webmail client still fetching messages so it can notify (e.g. via browser tab icons), or so that a collaborative editor keeps up with changes.
Even consider the typical hackernews demo of a javascript genetic algorithm: you probably want to be able to leave it to run for a while while you do other things without being required to keep the tab visible.
Those notification APIs still get triggered by Javascript running in those tabs. As far as I know, there's no equivalent to the mobile notification APIs where there's a single dedicated socket listening to a central server.
Productivity application clients like a spreadsheet or document editor tend to do best when they can receive commands/updates to the document in the background via something like a WebSocket.
Otherwise, each time you switched tabs to your spreadsheet, doc, slide show, etc., it would have to poll for changes from the server in some fashion, and wait for a response. This gets pretty frustrating when you're trying to do something like copy from one document to another.
During competitions I sometimes watch two twitch streams in two different tabs, turning just the sound on and off depending on which one is more interesting. (I had up to four open at the same time.)
It would be nice if page authors (perhaps with user permission) could disable throttling on background tabs in some cases. I made a Morse code tutor with the Web Audio API, and playback breaks as soon as you switch tabs because the timeouts go to 1 second minimum. And it's practically unusable on mobile, even in the foreground, due to the horrible timing and/or excessive audio buffer sizes (not sure which).
Suspend all background tabs (~2018)
Fully pause a tab in the background after N minutes unless a web developer states that the tab should continue to run via an explicit opt-out.
Remove opt-outs (~2020+)
Remove the opt-out and pause all pages. We’ll be able to do this once we’ve (1) ensured that the web platform provides the APIs needed for major use cases and (2) given developers a sufficient deprecation period.
That sounds a bit scary, and would require a lot of rewriting or refactor existing code. I'm assuming not all the APIs are even ready yet to proactively start doing this already. But sounds like the iOS model, which has it's pros and cons. Probably has a lot of benefits though in the long run.
I hope by pause, means if they switch back it resumes instead of reloading/refreshing. Maybe even emit an event to know it resumed, if the app wants to check if new notifications, etc for it's view... Maybe you were filling out a complex game form - losing state would really be sucky if it reloads, instead of resuming.
Right now WebRTC and WebSockets are not a solution to wholesale replace Ajax based javascript polling; A LOT of established software and hardware HTTP proxies used by large corporates do not support the HTTP CONNECT protocol, and thus WebRTC and WebSockets fail.
I have a service that's used daily by a small community of people who are behind such a proxy. The service uses 10 second javascript timeouts to fetch new data from the server - This change in Chrome(ium) is going to totally break it.
I do agree that sockets are the way to go, I just don't think the rest of the internet infrastructure is completely there yet.
Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?
Ah, I see what you mean. Chrome is throttling client-side operations. Because the python kernel of an iPython notebook is running as server-side code (even if that 'server' is local), it couldn't be subject to throttling by Chrome.
Pretty sure socket.io will be fine unless it falls back to HTTP polling, which iirc it shouldn't do in the newest version of Chrome unless something is misconfigured on one end.
A big factors seems to be that the pages that are built out of layers of active advertising devices - a given advertiser isn't concerned that they're one of ten monetizing devices pasted onto a gvien page.
And there's the way pages have disincentive to play nice - a page that barely works with only it open trains users to avoid other pages.