The feature is called Tab Unloading, and weirdly enough they made it not easy to access despite its usefulness.
You basically have to type about:unloads in the address bar and hit enter. If you then click on “Unload”, it will put the least used tabs to sleep. If you keep clicking that button until it’s greyed out, you’ll have unloaded all your tabs from memory.
This feature is handy if you want to temporarily switch to something that is memory hungry without having to close your 100 tabs.
Your Firefox should be doing this automatically when it detects the system needs more memory. You shouldn’t need to do it manually in almost any case
Your OS should do this automatically, your programs shouldn’t worry about cold memory.
Swapping anonymous pages is an extremely poor “solution” to cold memory. It’s the big hammer approach that technically always works but isn’t optimal for …anything really. That’s the best the kernel can easily and quickly know however which is why it’s done at all.
It’d be much better if the process could shave off memory usage using its own domain knowledge. In the example of firefox, it’s much faster and less jarring to the user to have 10 tabs reloaded from the web (browser shows a spinner as usual, doesn’t lag) rather than swapped back in from disk (entire browser lags and it probably even takes longer).
There’s no reliable mechanism to signal any of this to me knowledge however, so processes must guess the right time to do discard memory pre-emtively.
I believe you are mistaken, there is no way that reloading a tab from the web is faster than it being read from the disk.
For this you have to know that what gets swapped to disk is not the static content that you’d load upon opening a website, it’s the entire memory used by the tab.
Static web content is usually kilobytes to megabytes and is also largely cached (on disk even). A tab’s memory usage OTOH ranges from dozens to hundreds of MB.
Even a fast drive needs quite a long time (in computer terms) to load something like that, especially given that the access is likely not sequential and has a low queue depth.