I mean, asking to throttle a web browser’s tabs by default, is like asking that you throttle the JVM, or Docker, by default. The web browser has become a de facto container-workload hypervisor—and for many consumers (and some systems, e.g. ChromeOS) the primary one they rely on.

I say “container workload” because it often makes sense to put CPU/memory quotas on things like VMs, but containerized workloads are rarely designed for it, rather being designed to be able to have dynamic resource allocations—spiking up to huge resource usage before returning to a baseline level. Containers (and browser tabs) are meant to sort of “negotiate” CPU time and memory usage [and IOPS, which you didn’t mention] back and forth over time, especially as both kinds of workloads use way more of all of those resources when booting up before going quiescent. And container hypervisors—like browsers—are running workloads that mostly are designed to work better on an overprovisioned powerful substrate than on a strictly-provisioned less-powerful substrate (because there’s a pool of resources any workload can borrow to boot up, and then release), and so there’s never been real demand to make them manage hard quotas for every resource effectively, the way one can in a VM hypervisor.

So, if a sysadmin wants to limit the resource usage of a container workload, they don’t even bother trying to solve this at the level of the container hypervisor; rather, they just wrap the container [and its hypervisor] in its own VM, and then use the resource-quota support inherent in the VM abstraction to manage the resource quotas for the workload.

I’d say that what you’re asking for is similar to what people demand when they want quota knobs on container hypervisors. There’s consumer demand for it, but no professional demand, so it’ll never get done to the level of quality of the quota-enforcing solutions that professionals do rely on (and, to not lose performance in the process, would need a lot more “magic” in its allocation logic, to allow for patterns like burst-usage before quiescence, so it wouldn’t really be the thing you’re looking for anyway.)

I’d personally suggest—if there is such a thing as a “browser unikernel” (I’m imagining ChromeOS stripped down to have only virtio drivers)—then running several of those in VMs would probably be your best for controlling browser workloads.

I believe there are (research) workstation OSes where hardware-virtualized VMs running unikernels are treated as first-class “applications”, in about the same way that Metro apps are treated in Windows 10. https://genode.org/, for example. (Genode is technically a microkernel where applications are all capability-isolated kernel servers, but it’s easy to have one such server that’s a VM hypervisor, and you don’t end up even noticing the difference, since the OS is already built to make communication between these isolated workloads easy.) In these OSes, a window has not just window-management window-decorations, but also resource-quota management window-decorations, since each window represents an isolated workload. Maybe that’s close to what you’re looking for—running a browser on such an OS?

Or, to rephrase in terms of blame rather than constructive problem-solving: it’s not the browser’s job to make browser tabs not steal all your resources. It’s the OS’s job. The browser has already done its job by distinguishing these workloads from one-another as separate OS processes/threads; after that, it’s up to your OS to fairly quota and schedule those processes/threads such that you, the user, don’t get a bad experience. The consumer-OS approach to running native workloads, is lagging far behind the state-of-the-art here (that state-of-the-art being the way workloads are managed in hypervisor clusters like vSphere or Google’s Borg.) Demand more of your OS!