Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: