explore different time limit for stopping background execution on mobile |
|||||
Issue descriptionToday we have a hard-coded 5 minute limit that background tabs can run (includes foreground tab with the screen off). At that point we pause all timer tasks. We're working on also pausing other tasks. The purpose of the 5 minute limit AFAIK is to make it so that a user can do do a different task while they wait for a previous action to complete, e.g. clicking on a link, sending an email, etc. 5 minutes is a relatively long time. We should consider shorter windows. 1 minute maybe? <random-brainstorming-probably-bad-idea> Or, maybe it shouldn't be a hard-coded time. What if it's max(1m, first-TTI-after-backgrounding)? I phrased it this way to try to handle single page apps and other in-page actions. Maybe TTI is wrong. Is there some other metric we could look at for "this tab is probably done doing whatever the last user action was"? </random-brainstorming-probably-bad-idea>
,
Nov 26 2017
Determining this dynamically for each site would be nice with "first idle after loading" signal? (aren't we using similar metric for session restore?) As a simple initial improvement this could be based on aggregate UMA. Example: at 9X% percentile pages are "done" (i.e. FMP + first idle in background) in Nmins - then we could use that number.
,
Nov 27 2017
I'm still wondering a bit how large of an impact tweaking this number will have. Basically the current policy gives every tab 5 a minute budget to do stuff in the background every time you open or view it. If users often switch between tabs, then these 5 minute intervals might add up, but if tabs are mostly long-lived background tabs then the threshold doesn't really matter. Maybe we should do a Finch trial with a bunch of different values for N before we design anything more elaborate?
,
Mar 15 2018
,
Mar 15 2018
,
Aug 15
,
Oct 9
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by panicker@google.com
, Sep 13 2017