Video Acceleration API is... A video acceleration API. It shouldn't have anything to do with sound. Nor should mesa... Unless of course there's something totally broken regards the fallback to unaccelerated decoding, but I doubt it. Firefox error messages kinda suck though.

The Cubeb / OnMediaSinkAudioError lines are likely the relevant ones, I suggent a general websearch on those for a start. I don't have Debian / Devuan on any desktops right now to investigate myself.

What more does running with MOZ_LOG=cubeb:5 (or a log level of your choosing) have to say?
Do you have any custom ALSA configuration (.asoundrc, /etc/asound.conf)?

If it hadn't, https-everywhere would have killed it anyway. You can't really have local proxies and SSL at the same time, at least not how modern browsers are designed and modern users are trained.
All it takes is for someone to notice that faceborg is suddenly signed by proxomitron instead of DigiCert Inc, and the "muh securitee" wailing starts. Users are of course properly groomed to run arond with their hair on fire if they see any kind of browser "security warning", rather than reading details and making informed decisions.

All this is really just the same old war. Commercial entities want total control over how their sites (and apps, in the mobile space) display and how you interact with them, and that means locking down browser endpoints and preventing tampering with DNS and network traffic.

Pervasive use of obfuscated javascript where HTML would do.
Ever-expanding list of web "standards" and extensions that make it near-impossible for independent browsers to stay compatible.
HTTPS everywhere (even when no sensitive data is being exchanged).
DOH, and the "your ISP could spy on you, better trust google or cloudflare instead" non-argument.
Manifest v3 and the wider attack on content filters.
WEI (shot down for now, but it'll be back).
"SafetyNet" and other mobile OS attestation systems (which will come to PCs in time, we have "anti-cheat" rootkits and the like already).

All of this is touted as being for your security... It's not, it's for theirs. Google is of course the arch-villain here, because nobody wants to control what you see so much as a corporation funded by and founded on advertising.

IMO the only real solution is wholesale rejection of the current "web v2 (and supposed v3)" and it's centralisation of power. It's corrupt beyond recovery at this point, and is only getting worse.
I'd love to see the likes of gnunet, gemini, and other decentralised solutions gain popularity, but so long as all the frogs want is online shopping and social media, we're kinda screwed. If the water only gets a little bit warmer with each new "improvement" it's fine, right?

Squid doesn't have anything to do with DNS, it's a caching/filtering HTTP proxy. Such proxies aren't seen much anymore, because they don't really work on encrypted (i.e. HTTPS) connections.
Anything that does caching/inspection/filtering of HTTPS traffic needs to decrypt it, and that means installing a root cert on the client, which pretty much breaks the SSL trust model... Not that it stops corporate networks from doing exactly that, for "safety".

The browser has the SSL keys so it can do all this. That's kinda how most decent ad/content blockers work already, once you go beyond host lists and into selective element blocking (that's also part of why manifest v3 is bad, as it hobbles this ability to modify content before it is displayed or executed).

DNS is another matter altogether, and there's nothing stopping you running your own resolver (e.g. BIND) on your own network, with your own rules. Screwing around with cache expiry/TTL and locally resolved "whitelists" will likely just land you in a world of "my DNS is broken" hurt though.

Benchmarks or it didn't happen.

Okay then, why (technical explanation, not pseudo-jargon and hand-waving)... Also, benchmarks or it didn't happen.

That's an extremely normal memory consumption for a fresh-boot minimal XFCE desktop.

Unless your system has some weird caching limitation (which AFAIK hasn't been a thing since L2 moved on-die in ~1999), you have severe memory fragmentation, or you are running into memory pressure, how much RAM the desktop uses is of no relevance to system latency.
Again, benchmarks please.

Sigh. Benchmarks or it didn't happen.
"Everything will be twice as fast" is an extraordinary claim, and extraordinary claims require extraordinary evidence.

Subjective performance. Where benchmarks?

Either you have found a bug (in which case you should report it, with all relevant technical information and logs), or this is just more hand-wavy pseudo-technical "explanations" for "I broke it because I don't know what I'm doing", like the last post... Guess which one I'm betting on.

...
Or perhaps it's asking to much for someone with "extensive experience, having tested and worked with basically 80% of all the linux distros" to exercise any scientific rigour whatsoever when doing performance tuning and writing "guides"?

Well it is Motörhead, I mean that's kinda the point.

https://www.youtube.com/watch?v=Wh3t49NsWBA

Sounds like a pretty comfy rock you have there

I don't entirely disagree with you, I just extend "Say no to GMO" with "until rigorous testing and effective regulation is in place".
Any new technology has pitfalls and dangers, and biology and ecology are particularly problematic due to the complexity of the interactions involved. That doesn't mean we shouldn't pursue it, just that it needs to be done slowly and carefully. In light of the track record concerning corporations funding their own "safety" studies, IMO that means considerable expansion of the FDA, or formation of a new agency entirely.

IOW, I'm not against GM in principle, rather reckless application of technology in general. If done properly, GM could be a game changer for a great many fields... If not, it's a disaster just waiting for a place to happen.

Much the same could be said for the current AI craze, or any number of other technologies. As ever, the fundamental problem is rampant under-regulated commercialisation of technologies that should still be confined to the lab.

Profit, that's why.

Processed foods that are quickly digested leave you hungry again soon after = more profitable.
Sugar (or corn syrup) is incredibly cheap, and makes everything more palatable = more profitable.
Homogenous ingredients that are low in fibre (goto 1) are easier to process, and keep and freeze better = more profitable.

In general, if cheaper ingredients can be substituted and palatability recovered by adding sugar, fat, or flavourings... That's exactly what will be done.
I've worked around enough food production to see this in action, and it's usually a "slippery slope" process - one little recipe change, manger gets his bonus for cutting costs, repeat until your product is corn syrup and lard, with artificial flavour and colour.

There are no incentives to make "over-the-counter" goods better for you, only cheaper, tastier, and more addictive.
The "health food" market isn't much better, and has it's own brand of deceptive profiteering - usually leveraging public ignorance to inflate prices for things nobody actually needs.
Either way, outside of old-school "farmers market" type independents, honest food always looses to profitable food.

Regulators are primarily concerned with safety, and none of this bullshit will make anyone sick... at least in the short term.
The long-term impact nobody wants to tackle, because it's difficult and time-consuming to prove (and food megacorps will just buy some counter "studies" or tie things up with lawyers and lobbying anyway), and it boils down to a collective-good vs. corporate-profit fight, which nobody wants to start.

Welcome to capitalconsumerism, the shining land where everyone (scientists and regulators included) has their price, and we allow corporations to become more powerful than governments.

Only when you take garden-variety (pun not intended ) stupidity and greed and dress it up as some super-secret plot to take over the world.
The problems with the worlds food supply are old, pervasive, and readily apparent to anyone with a brain...
Also nowhere more obvious than in the USA, and other "Americanised" western countries where large food corporations have taken root.
That's not a conspiracy, it's just an observation.

Indeed. The problem is that you're essentially fighting a psychology war with corporations far better resourced than you are, and for many, that's a fight they're not going to win.
How can we expect people to make good choices when that's made artificially difficult (yes, fresh produce is at the back for a reason, etc.) at every turn, and they are constantly bombarded with advertising telling them to do the opposite?

Not to put too fine a point on it: Post some (properly controlled) benchmarks or I call shenanigans.
Without data to back it up (with the notable exception if side-channel mitigations, which have a well-documented performance impact), this is nothing but pointless ricer rambling.

This in particular:

Is complete and utter hogwash.
Computers are deterministic systems, and applications haven't been written to rely on system performance for correct operation (e.g. delay loop timing) since the 1980s. If your "tweaks" are causing bugs or unintended behaviour then your system is grossly misconfigured, your compiler is producing broken code, or your hardware is unstable (i.e. overclocked).

Programs being "designed to run at slow speeds" is pure fantasy, running as root to "reduce delays" is questionable at best (again, benchmarks or baloney) and gratuitously dangerous advice at worst, and the rest is a lightly-mangled manual install guide with a garnish of hyperbole and a dash of blatant misinformation.
If you're going to advise people to ignore decades of security best-practice and run a GUI as root, at least provide some benchmarks so they can make an informed decision WRT the supposed benefits.

The conditions which cause a fsck on boot are not hidden, but f2fs is prone to triggering a full (and extremely slow) fsck on kernel version changes. Its fsck is also arguably quite broken, and both of those are good reasons it's not a supported root filesystem in the installer.
Forcibly skipping filesystem checks is a real good way to end up with a hosed filesystem, and comments like this do not improve the credibility of your "mini-guide" one bit...

Nor does:

Because the MBR is not a partition and can never be one, so this is misleading bollocks. What you are presumably referring to is reserving space for GRUB at the start of the disk, and 8MB for that is ridiculous.

FWIW, I run Gentoo as a daily-driver, and have benchmarked things like LTO and some (not completely stupid) experimental compiler optimisations fairly comprehensively. I too can make an unstable system with weird bugs and bizarre behaviour... That doesn't make it any faster under real-world workloads, only more broken.
Even the most rabid -fbroken-math -funroll-brain -fomg-speed gentoo ricers admit that objective gains are minimal for anything but very specific (usually scientific data analysis or synthetic benchmark) workloads, and that's going deep into the weeds at the compiler level, not just futzing about with "gaming" kernels and unfsckable filesystems on a binary distro.

About the only useful advice here is 'mitigations=off' (which should also have a warning WRT the security implications), and the use of lazytime over noatime, which is not widely known but will actually reduce disk access.

For the rest:
Where is your proof that f2fs is faster than ext4 or xfs?
Where is your proof that running as root improves latency?
Where is your proof that the xanmod kernel improves game performance?

And last but not least, what is:

doing in a "guide" for a distribution that doesn't package systemd or systemctl to begin with?

Elogind is a part of systemd, forked and split out into a standalone daemon. Nothing more, nothing less, and nothing at all to do with "gaps".

Indeed.
Had the OP phrased the post as a bug report or request for help, help they likely would have received. Whining about how terrible the distro is because  an update on unstable "Removed internet access" gets... Some ROFL at best.

I'll tolerate plenty of complains if a routine update to a stable release causes borkage (particularly if the post includes technical details, as opposed to "$gui_thing got broke because I didn't read apt output"), hell, sometimes I'll even join in...
But unstable and testing are subject to this kind of dependency screwyness at any time, and that's kinda the point of having unstable and testing branches to begin with.

i.e.

This^ The answer is: fix it yourself (and/or file a bug report), or wait.