4 ms·
>Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC How long before a "performance best practices" guide suggests leaving a webs
by hueving 10y ago
>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.
- fauigerzigerk 10y agoI had a similar thought. I think browsers should require user permission for a tab to use more than 1% of a core on average.
- Someone 10y agoThat 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.
- fauigerzigerk 10y agoInitial 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.
- branchless 10y agoWould 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.
- Someone 10y agoDefine 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"]
- fauigerzigerk 10y ago>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.
- pasquinelli 10y agoWhy not ask once then remember?
- woliveirajr 10y agoThen 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. :)