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

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.

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.