41–50 of 62 posts
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.
The Great Suspender is a great plugin to achieve this.
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
https://chrome.google.com/webstore/detail/the-great-discarde...
Earlier quoted context omitted.
I had a similar thought. I think browsers should require user permission for a tab to use more than 1% of a core on average.
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…
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.
They were always boasting about building okcupid in C++. Guess they needed garbage collection after all.
Earlier quoted context omitted.
Browsers have notification APIs now, from what I've seen. No need to run a full background tab just to handle the occasional notification.
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.
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…
Try uMatrix (in Chrome). 95% of sites are readable with no modifications. Videos often don't play, but I consider this a feature not a bug.
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…
[1]: https://chrome.google.com/webstore/detail/the-great-suspende...
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.
Earlier quoted context omitted.
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 imple…
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 w…
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.