How to aggressively throttle background tabs in Firefox using dom.min_background_timeout_value

Question

What are the correct settings to aggressively throttle background tabs in Firefox?

Years ago I stumbled on this post explaining various about:config settings in firefox for throttling background (and foreground) tabs, but I could never make sense of their meaning. It is unclear, for example, what the units of each of these options are (seconds, milliseconds?) and whether or not increasing the value will throttle tabs more or throttle them less.

dom.min_background_timeout_value
dom.timeout.background_budget_regeneration_rate
dom.timeout.background_throttling_max_budget
dom.timeout.budget_throttling_max_delay
dom.timeout.foreground_budget_regeneration_rate
dom.timeout.foreground_throttling_max_budget
dom.timeout.throttling_delay

Specifically, let's take a super-aggressive throttling policy: I want to make it so background tabs are granted only 1ms of execution time every 30 minutes. I want this policy to go into effect 1ms after the tab is no longer in the forground. That is to say, tabs should never exceed 0.00% CPU usage for a period of 30 minutes after I leave a tab in the background.

What should the values for these firefox settings be to achieve this aggressive throttling behaviour?

Answer 1

tabs should never exceed 0.00% CPU usage for a period of 30 minutes after I leave a tab in the background.

This is achieveable by setting the following entries in about:config

dom.min_background_timeout_value 1,800,000
dom.min_tracking_background_timeout_value 1,800,000
dom.timeout.throttling_delay 1

According to the "Inactive tabs" section of the mozilla documentation on window.setTimeout:

To reduce the load (and associated battery usage) from background tabs, timeouts are throttled to firing no more often than once per second (1,000 ms) in inactive tabs.

Firefox implements this behavior since version 5 (see bug 633421, the 1000ms constant can be tweaked through the dom.min_background_timeout_value preference). Chrome implements this behavior since version 11 (crbug.com/66078).

Firefox for Android uses a timeout value of 15 minutes for background tabs since bug 736602 in Firefox 14, and background tabs can also be unloaded entirely.

So the default value of dom.min_background_timeout_value on firefox is 15 minutes (actually set to 900,000 as the unit is ms), which makes sense for a device trying to preserve battery and scarce RAM/CPU resources. Doubling that value to achieve 30 minutes = 1,800,000.

Note that there's a distinct entry in about:config for throttling tracking scripts (dom.min_tracking_background_timeout_value) that should also be increased to the same value of 1,800,000 ms.

By default, tabs aren't throttled when they're immediately no longer in the foreground. So we set dom.timeout.throttling_delay to 1 ms to begin throttling tabs almost immediately once they're no longer in the foreground.

I don't know what most of those other about:config entries do. The budget ones are particularly confounding, and further clarification is welcomed.

Answer 2

For more complex workloads than the simple "throttle all timers a lot": namely, letting timers run more frequently if they are short, there is also a timer budgeting mechanism in Firefox. This budgeting mechanism only allows timers to run if there is a 'budget' for it, which is decreased by the amount of time timers in a given tab spend running, and increased by a slow regeneration. When it is negative, the timer is blocked from running. Note that the timer appears to be per-tab: it is strongly implied by the feature ratonale that tabs which are "polite" with their timers are rewarded, and tabs that aren't get punished.

The following options in about:config can be used to tweak this:

dom.timeout.background_budget_regeneration_rate reduces the rate at which a timer is given more time to run. It is in units of the number of real-time milliseconds that must elapse before the budget for background tab timers in a tab is increased by one millisecond.

dom.timeout.background_throttling_max_budget sets the maximum number of milliseconds that can be stored within the budget. Once the budget is that large, it stops increasing.

dom.timeout.budget_throttling_max_delay sets the maximum number of milliseconds timers in a given tab can be forced to wait. It acts as an override on the rest of the budgeting mechanism.

Thus, if the regeneration_rate is set to 60, and the max_budget is set to 3000, then the tab will gain one second of execution time for every minute of real time. If the max_budget in that case is set to 3000, then after three minutes the budget will hold 3 secconds of execution time, and will stop increasing: so after six minutes, it will still hold three seconds. Lets say the max_delay is set to 1000 (ie, the budget will only hold up timers for a maximum of a single second). Note that these settings are far from optimal.

If a timer in the above tab then spends five seconds executing (which is very unlikely), the budget would stand at -2000 milisecconds. If another timer in that tab immediatly elapsed, it would be forced to wait 2 min while the budget regenerates to a positive value. However, because the max_delay is so low (1 second), only 1 second will pass before the timer is triggered anyways.

How this interacts with the more traditional timeout mechanism described by Michael is unknown to me. See this mailing list post for more details on the mechanism.