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.


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?

2 Answers 2


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.

  • 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 May 23, 2021 at 4:16

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.

  • It should not be necessary to follow a link to learn the answer. Please include all of the information relevant to the solution in this post, leaving the link for proper attribution and "extra study". May 7, 2021 at 23:29
  • 1
    @music2myear I think all information is present: increasing the regeneration rate is sufficient to throttle background tabs. This answer is meant to be read in conjunction with the other answer, which leaves it as an open question as to what the budget options mean. I lack the reputation to leave a comment in this community, hence the separate answer. May 10, 2021 at 17:43
  • Answers need to be stand alone, otherwise they are merely comments and should have been posted as such. Any answer can be deleted, and if that occurs the information you rely on for context will be lost and your "answer" will be even more lost than it is. Not having the rep necessary isn't a suitable excuse. Everyone starts that way. More effort would have made this a viable answer on its own and would have earned you upvotes, instead of downvotes, and gotten you close to being able to fully participate. May 11, 2021 at 1:19
  • @music2myear happy now? added a bunch of stuff. May 12, 2021 at 17:03
  • 1
    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.. May 17, 2021 at 11:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.