[knaq]

I remember that the web was very usable with a 133 MHz CPU, 32 MiB of RAM, a 3600 RPM hard disk, and a 1.5 megabit (0.128 megabit up) connection.

That budget Android phone blows away the hardware that I was using. A quick search for the Samsung A50 tells me: "on Verizon's network in downtown Manhattan [...] average data speeds of 57.4Mbps down and 64.8Mbps up". That is 38 to 506 times faster. It has an absurdly fast 8-core CPU running at 2300 MHz. Ignoring the fact that MHz is a terrible benchmark, that is a factor of 138 faster. The RAM is bigger by a factor of 128 or 192. There isn't really any hard drive latency on the phone.

Yes, the web is slow.

The trouble is that browsers make no attempt to stop web sites from using infinite resources. The assumptions are that web sites will politely cooperate to share my computing resources, and of course I couldn't possibly want to actually use tabbed browsing to access lots of web sites, and we all discard our hardware as electronic waste after just a few years.

[noodlesoups]

It's impossible to make any sane limits that would universally apply to web pages. An isolated environment for an arbitrary application is the web's purpose, not just loading a text document.

You can actually play hw-accelerated doom3 on a browser today no problems. No add-ons, no nothing needed.

[knaq]

You could require user consent for resource increases.

For example, start the RAM at 12 times the number of CSS pixels. When the limit is hit, freeze the allocations until the user authorizes a doubling of the limit. Web sites would need about 10 authorization clicks to go from 4 MiB to 4 GiB. That goes for everything on the page, all sharing the limit.

Web sites would quickly change to minimize that, out of fear that users might not keep accepting the resource usage.

CPU usage could be similar, probably based on threads. The default is that only a single tab in a single window gets any time at all. Everything else is suspended. Users can grant permission for stuff like music players.

Network usage would also need to be limited, though limiting the RAM and CPU will tend to limit network usage as a side effect.

[noodlesoups]

It's more likely users would be mad that their browser update makes them play cookie-clicker to get to their sites.

By and large users are unaware of how much resources something uses, or should use. They don't really care about anything but getting from A to B as fast as possible, with as few interruptions as possible.

Computer resources are just like any other resource; expendable. User will always use more if that means it's more convenient. Human time is very valuable. Accepting multiple dialogues would take even more time than loading a fat page

as an add: there is no single resource you can bind the multiplier to; many sites use no css, but lots of js, or webgl, wasm, tables... There is simply no possible way to foresee what will be slow and what wont

[knaq]

The "CSS pixel" is just a pixel, unscaled for high-dpi displays. The point is to avoid revealing the hardware while allowing a bigger starting amount for a bigger window. If you prefer, just pretend I wrote "32 MiB".

Human time is valuable. That is the whole point of this. My time is wasted when my computer gets so slow that it takes 10 seconds for the Caps Lock light to respond. My time is wasted when the mouse lag is so awful that it takes me half an hour to kill a few tasks. My time is wasted when I have to walk away from an unusable computer, checking back every few hours to see if the OS might have killed the biggest task.

Web browser resource consumption is why I have a fresh new HN account. I had to power cycle the computer today, and it seems that Chromium won't save passwords over a restart unless I upload them all to Google.

[noodlesoups]

All problems are fractal in nature, they require a problem-scope in order to be solvable.

In this case, it would be "how fast is fast enough?", which would be fast enough that the human operating the application doesen't lose focus.

For most pages I've viewed with my 150€ phone, submit->time to interactive is between 1-3 seconds for the first non-cached load, and much faster for when revisiting. This is sufficient worst-case for any conceivable tasks performed on web-apps today.

Some exceptions that come to mind (like Reddit) have ulterior motives to force slowness so that people have to use their native app instead (which isn't much better for what I've heard)