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 foreground. 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?

score 11 · Accepted Answer · edited Jan 30 '23 at 07:59

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

This is achievable 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 are not immediately throttled when they are placed in the background. To change this, we set dom.timeout.throttling_delay to 1 ms to begin throttling tabs almost immediately upon being moved to the background.

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

This's interesting. I think this should be put on preferences so Normal average user know.. like option super battery save, medium, or normal. that would help the battery life of laptop — Benyamin Limanto, May 23 '21 at 04:16
Very useful answer. I cleaned it up a bit, but I think it's worthy of a larger update. BTW, do you have any URLs of good sites on which to test this functionality? — RockPaperLz- Mask it or Casket, Jan 30 '23 at 08:19
@RockPaperLz-MaskitorCasket in recent years, I've found that the most resource-hungry websites that crash my computer if I don't enable background tab throttling are social media sites like facebook, twitter, and linkedin. Jira is also exceptionally horrible. — Michael Altfield, Jan 30 '23 at 20:48
Thank. Fortunately, I don't use any of those sites. As you mention, they are all horrible... for many reasons. Maybe I'll create a test account just to use an example. If you think of any of any other sites, especially any that don't require accounts, I'm interested. — RockPaperLz- Mask it or Casket, Jan 31 '23 at 09:00
I have been experimenting with various settings from your answer and from the one written by Calum. I need to continue testing, but with only a single tab open, I think I may be experiencing some performance degradation. That shouldn't be the case, as there are no background tabs, but it seems to be what I am experiencing. Can you think of any reason why this may be happening? — RockPaperLz- Mask it or Casket, Jan 31 '23 at 09:03

score 5 · Answer 2 · edited Jan 30 '23 at 08:06

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 rationale 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 seconds 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 (i.e., 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 milliseconds. If another timer in that tab immediately 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.

Thanks for the additional explanation! Are all budget timers per-tab? If not, Is there any way to set these budgets on a per-domain basis? Like, I don't want reasonable-site-a from never checking a message queue just because facebook is chewing through my entire background budget.. — Michael Altfield, May 17 '21 at 11:17
Can you please provide an example of a more reasonable throttle budget that you'd recommend? For example, maybe granting each tab/domain 3 seconds of execution every 10 minutes? — Michael Altfield, May 17 '21 at 11:22
@MichaelAltfield I added a more clear example: I decided to use a smaller ratio than the requested 3sec:10min, since I wanted to keep the number pretty simple. This mechanism is more complicated than a simple "3 secconds per 10 min": you can get that affect, but it allows for more customization. For instance, does it get 6 secconds after 20 min? — Calum McConnell, May 19 '21 at 04:30

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

2 Answers2