Replying to this part:
Update 2022:
None of the below solutions (provided in 2016) work anymore. Is there currently (in the year 2022) any way to "prevent background tabs from loading in Firefox" ?
Since it appears to still be relevant in late 2023 and I have been hunting for the something similar so essentially just sharing my notes so far with whoever finds this post via search engines.
~~I unfortunately did not see many about:config
options for controlling whether or not background tabs are opened in a loaded state or not...~~ There IS some built-in stuff but it seems that it might be poorly documented. See notes at end of this post for more details and links.
As far as addons go, there were a lot of options. And I will say right off that I am going a lot broader than OP's use-case but I will circle back to that (scroll past the list). In other words, some things in this list are related to discarded/suspended/unloaded tabs but are NOT applied automatically. There are also some addons like LoadTabOnSelect 3 that do NOT have FOSS licenses (e.g. "All Rights Reserved") which I'm completely uninterested in and just blatantly ignoring. I probably missed a few (or new ones might come out) so don't consider this as 100% comprehensive, just as more thorough than usual.
Last, aside from Tabhunter and BulkURL, I have NOT tested these myself so it's possible some of these might work better than others. I don't plan on maintaining this list, but I might circle back later once I've tested a few if there's anything worthwhile to add - I'm posting now before I have a chance to forget or get sidetracked.
Table of FOSS addons related to tab discarding:
WARNING: Most of these - in particular the automated discard type ones rather than Bulk URL Opener / Tabhunter / ones that just add context-menu options - are likely to conflict with each other. If you plan on trying multiple, I suggest disabling all but one of them at any given time and testing it out independent of the others.
Addon |
Last updated |
License |
# Users |
Public Repo |
Notes |
Auto Tab Discard by tlintspr |
Dec 17, 2022 |
MPL 2.0 |
61,694 |
github |
looks to have lots of options including to discard inactive tabs after some configurable number of seconds (as well as a lot of other options). Preview |
Auto Tab Reaper by Chris Trotman |
Dec 29, 2020 |
MIT |
22 |
github |
automatically discards tabs, skipping pinned and audible tabs. default 30 minute delay but configurable to 1, 5, and 10 minutes. |
Bulk URL Opener by Euan |
Jun 19, 2022 |
MIT |
3,979 |
github |
opens urls pasted from clipboard. has an option under addon settings to "Delay tab loading until tab is selected" |
Discard Tab by freddyb |
Dec 1, 2018 |
MPL 2.0 |
287 |
github |
allows discarding tabs via right-click |
Discard Tab by Sergey Vlasov |
Aug 6, 2020 |
MPL 2.0 |
33 |
github |
fork of Unload Tab by Js with Alt+U shortcut and tab context menu |
Dormancy by dietrich ayala |
Jan 9, 2019 |
MPL 1.1 |
262 |
github |
Discards tabs every x minutes (default: 10). Description doesn't mention it but the code (background.js) appears to exclude pinned tabs, audible tabs, and user-configurable sites. |
HoldTab by Mikhail Vyrtsev |
Oct 20, 2017 |
BSD |
125 |
github |
Delays new tab loading until you activate it |
Lazy tabs by martin |
Jul 3, 2021 |
GPL 3.0 |
28 |
N/A |
Open links in paused (discarded) tabs and pause selected tabs (from the right-click context menu) |
Limit Active Tabs by igorlogius |
Aug 2, 2023 |
BSD |
24 |
github |
Limits the number of active tabs, by unloading older tabs (determined by last tab activation) |
Load Background Tabs Lazily by kgersen |
Sep 18, 2023 |
MPL 2.0 |
414 |
N/A |
Allow only a specific number of new background tabs to load at one time. |
Load Background Tabs on Select by igorlogius |
Sep 19, 2023 |
BSD |
23 |
github |
Prevents tabs which are opend in the background from loading until they have been manually activated once |
LoadTabOnSelect by Aaron Horler |
Sep 6, 2017 |
Apache 2.0 |
329 |
github |
Load newly-opened background tabs on selection, rather than automatically in the background. |
LoadTabOnSelect Evolution by Un Crevard |
Nov 17, 2020 |
GPL 3.0 |
11 |
github |
Fork from LoadTabOnSelect. Load backgrounded tabs ONLY on selection. |
New Tab Suspender by Pradeep Mishra |
Nov 20, 2021 |
MPL 2.0 |
9,119 |
github |
can suspend after a timeout |
Open from Clipboard by igorlogius |
Aug 4, 2023 |
BSD |
52 |
github |
Opens tabs from clipboard without loading page content (e.g. discarded state) |
Open link in new discarded tab by def00111 |
Aug 13, 2018 |
MPL 2.0 |
17 |
N/A |
Adds 'Open link in new discarded tab' option |
Tab Discard (Suspender) by Glin |
Jul 5, 2020 |
MPL 2.0 |
214 |
N/A |
looks like you click a toolbar button to suspend current tab |
Tab hunter by Eric Promislow |
Mar 18, 2023 |
MPL 1.1 |
833 |
github |
Can manually discard selected tabs (select tabs in addon > More > Discard Tabs buttons) |
Tab Suspender by TabSuspender |
Jul 15, 2019 |
MPL 2.0 |
764 |
N/A |
Adds 'Open link in new discarded tab' option |
Tab Unloader by Afnan Khan |
Feb 1, 2020 |
MIT |
684 |
N/A |
has tab-menu options to positionally disable (e.g. to the left/to the right/other) |
Tab Unloader for Tree Style Tab by Lej77 |
Apr 22, 2022 |
GPL 3.0 |
1,252 |
github |
Tab unload options for Tree Style Tab. |
The Safer Suspender by Elsa zz |
Dec 29, 2021 |
GPL 3.0 |
12 |
github |
automatically suspend tabs that have not been used for a while |
Total Suspender by k5md |
Apr 18, 2020 |
MIT |
2,400 |
github |
suspends all non-active tabs w configurable time, whitelisting, and able to ignore audible tabs |
Unload Tab from Context Menu by Bogdan Filipchuk |
Jan 25, 2019 |
MIT |
105 |
github |
Gives tab-menu option for 'Unload Tab' |
UnloadTabs by NiklasG |
Sep 6, 2019 |
MPL 2.0 |
3,388 |
github |
Gives tab-menu options for 'Unload Tab' and 'Unload Other Tabs' |
Recommended FOSS addons for automatic tab discarding:
As to what I would actually recommend for someone in the original poster's position (e.g. don't load ANY tabs until selected), first, I would remind that I have not personally tested these and am going by descriptions. Second, since I am strongly biased (perhaps differently than OP or whoever is reading this), I would ignore ANY addons that don't have a public code repository, even if they have a FOSS license, as well as anything that hasn't been updated in more than 2-3 years. My reasoning being that really old addons are more likely to run afoul of api changes by Mozilla and that anything without a public repository is less likely to receive support from the community (e.g. less bug reports/patches, less eyeballs reviewing the code for anything shady, etc).
Going by the descriptions of what's left, Load Background Tabs on Select by igorlogius or LoadTabOnSelect Evolution by Un Crevard sound like the closest fit to the OP's requirements.
But many of the others would likely work just as well for anyone who didn't need literally EVERY background tab to be suspended (e.g. for someone who was ok with tabs being processed by whitelist, timeout, or some other criteria). In that case, Auto Tab Discard by tlintspr, Auto Tab Reaper by Chris Trotman, or Total Suspender by k5md all might be good options. Ditto for Load Background Tabs Lazily by kgersen that was already mentioned by masgo.
about:config settings related to built-in tab discarding:
As hinted at near the top of this post, there's also browser.tabs.unloadOnLowMemory
which controls whether or not Firefox itself will attempt to unload tabs when low on memory. But the article may be out of date or missing some scenarios (e.g. Linux) as it implies this setting to be true
by default (at least, if using an unmodified version directly from Mozilla).
On some systems or forked projects, this may not always be the case. For instance, I am using Firefox 118.0.2 on Fedora 38 and even with a fresh ~/.mozilla
profile, the Firefox from Fedora central repositories (which is packaged by either Fedora contributors and/or Red Hat employees rather than coming from Mozilla directly) uses browser.tabs.unloadOnLowMemory=false
by default. This appears to be defined in the file /usr/lib64/firefox/omni.ja
. The Librewolf fork, run on the same system, also defaults to browser.tabs.unloadOnLowMemory=false
and appears to have a similar definition in /usr/share/librewolf/omni.ja
. It seems this is also the case on Ubuntu but I am clear if this is related to issues with the feature under Linux ([1] [2] [3], [4]), packager/community preference, or something else entirely. Likewise, no clue if the setting behaves differently for native builds vs flatpak/snap ones. This page has a more detailed discussion of how things work on Windows.
Some other setting related to browser.tabs.unloadOnLowMemory
are:
browser.low_commit_space_threshold_percent
- see here for a more in-depth discussion
browser.low_commit_space_threshold_mb
- see here for a more in-depth discussion
browser.tabs.min_inactive_duration_before_unload
: value is in miliseconds. default: 600000
(ms aka 600 sec aka 10 min). From here
about:config settings tangentially-related tab discarding:
I'm assuming that anyone hunting for tab unloading might also be concerned with performance/stability, what situations cause a link to be opened in the background (which could affect whether an addon that prevents background-tabs from loading operates on it or not), and anything that might cause the browser to reload a tab without the user explicitly telling it to.
accessibility.blockautorefresh
: defaults to false. set to true to prevent auto-refreshing tabs. Some pages/sites ask a browser to automatically refresh a page after a given timeout by including the HTML element <meta http-equiv="refresh">
or by sending a Refresh: HTTP header. This property controls whether or not firefox will refresh the page when that happens. Restart of FF after changing this may be necessary before it takes effect. See here for more info. This shouldn't affect a tab that hasn't been loaded but like with regular loading, if you have a large number of tabs open, it could be wasting extra memory/cpu time.
browser.cache.check_doc_frequency
: see doc here. This could be relevant in a few niche situations. The default (3
) aka "Check for a new version when the page is out of date" is probably fine for most. But there may be situations where you only want to load from cache (2
), never load from cache (1
), or only load it a page once per firefox session (0
).
network.http.use-cache
/ browser.cache.memory.enable
/ browser.cache.disk.enable
/ browser.cache.disk_cache_ssl
/ browser.cache.disk.capacity
/ browser.cache.memory.capacity
: if you have these disabled or set too low, respectively, Firefox could be needlessly auto-refreshing the page from the web instead of from cache, wasting more system resources in the process. Probably only an issue if you are loading a large number of tabs and want to avoid refreshes. All of the non-*capacity ones should default to true
. The capacity values are in KB (technically KiB - e.g. the binary unit, not the SI one) and a value of 0
effecting disables that kind of cache. browser.cache.memory.capacity
also supports -1
(the default) which means to auto-manage based on available RAM. browser.cache.disk.capacity
does NOT support -1
and must be an actual positive number or zero (default is 50000
aka 48.8 MiB according to the documentation but for me it was preset as 256000
aka 250 MiB as of Firefox 118.0.2 on Fedora 38). This gist page has some other tips for cache-related improvements.
dom.ipc.processCount
/ dom.ipc.processCount.webIsolated
: The default seems to vary by which document you are reading but for me (Firefox 118.0.2 on Fedora 38) it was dom.ipc.processCount=8
and dom.ipc.processCount.webIsolated=4
. These are harder to understand unless you have read/understand the FF Process Model but essentially, they limit the # of processes per site of a given type. For most users, the webIsolated property is going to be more relevant as this will generally control the # of processes used when each site loaded (UNLESS you've turned off site isolation aka Fission by setting fission.autostart=false
which is not recommended, in which case dom.ipc.processCount
will be more relevant). This will not affect pre-allocated processes, processes used by firefox unrelated to sites (e.g. addons and such) and a few other things. So if you reduce to say dom.ipc.processCount.webIsolated=1
, you probably won't notice a performance improvement but may notice improved stability.
There are also several properties that control if links open to background vs foreground tabs which might come into play for addons that auto-manage background stuff. There is already an excellent answer here from jscher2000 (he makes some pretty useful addons too), which I will quote here in case the link ever goes dead:
Ignore the services.sync.prefs.sync.browser.tabs.loadInBackground preference, this just tells Firefox whether to include the next preference when it Syncs preference.
browser.tabs.loadInBackground is set to true by default and is the one that has the checkbox on the Options page. This covers the case where you specifically direct a link to a new tab, for example, from the right-click context menu, or by Ctrl+clicking or middle-clicking a link. I suggest double-clicking it to false, and then double-clicking it back to true, just to make sure you and Firefox are on the same page.
browser.tabs.loadDivertedInBackground is set to false by default. This covers the case where the link is coded to open in a new window and Firefox diverts it to a new tab instead -- Firefox switches to those immediately. If you are having problems with this kind of link, double-click the preference to switch the value from false to true.
browser.tabs.loadBookmarksInBackground is set to false by default. Not your issue, but something to consider experimenting with for the future.
browser.search.context.loadInBackground is set to false by default. This is for those searches you run by selecting text in a page, right-clicking, and using the item "Search Google for [text]" (or if your default search engine is not Google, your default search engine will be mentioned there instead). Not your issue, but something to consider experimenting with for the future.