It sounds like you've got two problems going on as far as your computer is concerned:
- Zoom is a resource hog.
- Something in firefox is a resource hog.
I infer that what you actually mean is
- My GUI gets laggy and I don't like it.
1 – "Tweaking" (breaking) the scheduler to force-limit a CPU intensive process
To deal with the former, as well as complaining loudly (and not using video backgrounds), you may wish to consider limiting the amount of CPU it can have. This is done in linux via control groups or CGROUPS, which can effectively limit scheduling for a single group. For example, you can use CGROUPS to get the kernel to constrain processes within a CGROUP to use, let's say for example, 100 ms out of every 1000 ms (or .1s out of every 1s) of CPU time. This will make things worse for your Zoom experience but might be better over all.
To give this a go, sudo apt install cgroup-tools libcgroup1 libcgroup-dev, and then create a cpu-limited cgroup with
sudo cgcreate -g cpu:/cpulimit
Here, cpulimit is the group name that controls the cpu usage. Now, you have to set cpu.cfs_period_us and cpu.cfs_quota_us property on the cpulimit group.
In keeping with the above example, let's set 1 s or 1000000 us (microseconds) should be set to cpu.cfs_period_us property and 100 ms or 100000 us should be set to the cpu.cfs_quota_us property
sudo cgset -r cpu.cfs_period_us=1000000 cpulimit
sudo cgset -r cpu.cfs_quota_us=100000 cpulimit
To check to see that this is the case, run sudo cgget -g cpu:cpulimit and observe that these flags are set.
It's now the case that whatever process you add to the cpulimit CGROUP will, as the name suggests, be limited to using use 1/10th (100000/1000000 = 1/10 = 0.1 = 10%) of the total CPU cycles. At the very least, this probably helps quite a lot.
Now to actually use this and start a process, start the program or command with cgexec as follows:
sudo cgexec -g cpu:cpulimit YOUR_COMMAND
where YOUR_COMMAND can be /path/to/zoom or literally anything else.
2 – Finding performance hogs in Firefox
Firefox has a nifty about:performance page that will help you spot hungry pages. often these use a lot of javascript, display ads, or may even be so rude as to run, for example, a cryptocurrency miner without telling you. As well as killing (closing) the culprit page, one thing you might want to do to stop that happening again is taking the plunge and using a selective javascript blocker like the excellent umatrix to prevent that happening again. Sure, it breaks some pages, but you usually learn something about the web in unblocking particular links ;-).
3 – Stopping your GUI from lagging the nice way
As well as the not-often-used cgroups to place a hard limit on processor scheduling, Linux has an inbuilt idea of process priority. For reasons of history that I would love to learn if others can educate me, Linus called this priority niceness. We can renice (or sudo renice) a process to make it "nicer" -- i.e. run with a higher priority. By default, users can renice processes down to a priority of 0 (and up to 19) and root to -20. Lower niceness processes are given more priority by the scheduler. (I think the idea here is that a process that you don't really care about -- i.e. one that would be "nice to have" -- is given a higher niceness to decrease its priority).
For gnome, it /may/ help to renice the gui to a lower niceness. This is quite easy to do; e.g. sudo renice -3 -p $(pgrep Xwayland) && sudo renice -3 -p $(pgrep gnome-shell). Again, similarly to the above, nice will start a process with a specified niceness; but here you need to specify it with a - beforehand -- so that nice -10 /path/to/zoom would start zoom with a niceness of +10 (and nice --10 /path/to/zoom with a niceness of -10). This also /may/ be a better way of going about it.
