The things that take up time and energy in browsers - i.e. things like garbage collection, JIT compilation, and so on - are already things that CPUs are hyper-s

The things that take up time and energy in browsers - i.e. things like garbage collection, JIT compilation, and so on - are already things that CPUs are hyper-specialized for. And the code that is ultimately intended to execute is also well-specialized for CPUs. It's already possible to target GPUs in-browser directly; and most older HTML primitives were recast in terms of GPU operations around the time of the original iPhone. The only thing I can think of that's still been left on the table is rendering vector geometry on-GPU; but most sites don't redraw so much as to make this a huge performance win. Video decode has been offloaded to hardware for decades as well. The only reason to decode video on-CPU is if you're decoding crazy-old formats[0] that don't have hardware decoder blocks present for them. The other huge problem is networking - which is also heavily hardware-optimized and has been for a while. Large assets mean keeping your Wi-Fi or LTE baseband on for longer. You could mitigate this with compression; which can be hardware optimized... though I'm not sure how much of a benefit that provides outside of game consoles[1]. [0] In my personal experience: I wrote a Sorenson H.263 decoder for Ruffle. Right now it not only executes on-CPU, but blocks the event loop main thread. However, the video files in question are so low-quality that this isn't a significant problem for most Flash movies and everything works fine (though I do want to try on-GPU video decoding at some point). [1] Current-gen game consoles (PS5/XSeries) have hardware decompression blocks. However, the intent is to quickly decompress gigabytes worth of data quickly; most websites aren't nearly that bloated.