> Sizes are being used as a fuzzy proxy here which makes sense—putting a cap on CPU usage and memory is a lot harder to pull off. Is focusing on size ideal? Probably not. But not that far off base either.
No: this doesn't make sense :/. The core problem is that stuff sits around executing some tiny input handler or animation in a loop, burning CPU. When I have tracked the tabs that are the worst performers down to the code causing a problem, it is never a large amount of code: it is some stupid mechanism that polls the position of something (like the cursor or the scrollbar), or is trying to push some analytics to a server.
This really has nothing to do with the amount of code being downloaded. I realize some people care complain about how much stuff they have to download, but that just isn't what is actually causing most people problems. Sure, tracking CPU is sort of annoying, but it absolutely isn't hard. Chrome already is running these things in separate processes (for security), and the operating system is tracking the time used for each thread: you can just ask it and make some kind of limit if that is what you care about.
I mean, in this article I see ideas for size limits for images, which is at least consistent... but that is going way way too far: 1MB just isn't good enough for a reasonable image. If you care so much about bandwidth, make a bandwidth cap for the page and if it exceeds it--across all media--figure out some way of blocking or punishing the site.
What most of us care about is that there seems to be no limit on the CPU usage of any given page. This is easy to fix--it is a virtual machine, after all!--by just doing the same trick Erlang uses for compiling a preemptive fiber and then limiting its time execution slices.
What I know I care a lot about is when a tab I haven't looked at in three days is suddenly using CPU time _at all_. Just make it so background tabs get severely limited in their ability to do background execution and eventually get stopped entirely, and the problem is essentially solved.
(Chrome, which is apparently already big on these size limits, doesn't do this, and I swear it is because it is against Google's interests to do it as it mostly makes it more difficult to do stuff like tracking and advertising :/.)
> What I know I care a lot about is when a tab I haven't looked at in three days is suddenly using CPU time _at all_. Just make it so background tabs get severely limited in their ability to do background execution and eventually get stopped entirely, and the problem is essentially solved.
It doesn't throttle them all the way to zero, though. If they did that they'd break things like sites that change their favicon to signal "unread message".
(Disclosure: I work at Google, though not on Chrome)
yes. without background processing every web based service that has live updates would break. Email (Gmail/outlook.com/...) chat (slack/messenger/WhatsApp/Discord) SNS (fb/Twitter) even stack overflow and github have various forms of live update
On mobile platforms, app don't use polling loops for that sort of stuff, precisely so that power usage could be optimized. Time for something similar for the web?
Arent notifications same thing with only difference that they go through apple/google centralized server so your phone doesnt have to listen for multiple servers but just one?
A simple short-term workaround would a setInterval equivalent that can be set to "every so often" instead of a hard number, leaving it up to the browser or OS to coalesce updates into chunks of activity every so often.
Many services use an open tcp connection (e.g. websocket) rather than polling. Mobile platforms are doing the same thing, just on a system level. I guess service workers are the closest web analogue.
> Chrome, which is apparently already big on these size limits, doesn't do this
Not sure what you mean, Chrome's background tabs are heavily throttled. Killing completely after a day or two would be nice. I use an extension for that.
I think you're missing the goal when you say what "most of us care about", though. Background tabs aren't an issue for people without many tabs open (many people) or who are on mobile (even more). Slow loading pages definitely are.
Its maximum size is excessive unless you aim to support 4K: 5472×3648. It weighs 4.9MB. A lot!
I then went to Squoosh.app, which allows one to optimize images in various ways. The default option – MozJPEG at 75% quality – reduced image size by more than a half, down to 2.24MB, with no apparent loss of quality even at the high zoom. Illustration: https://i.imgur.com/2bkHrot.jpg
Do you really need to serve a 4K+ image, though? I reduced the image to 1920×1280, using the same app, with the same compression settings. 184kB! Illustration: https://i.imgur.com/52MctSN.jpg
At 33% zoom (which is necessary for a reasonable comparison, since Squoosh stretches the smaller image for comparison), the compressed image looks very good. It lacks the noise the original had, and looks more glossy. There are also advanced settings that one could tinker with, perhaps to a better compression with equal losses.
Is it a big deal? Perhaps – especially when you look to present the image as-is, with minimal losses between conversion from RAW to, say, PNG. For most websites, though? I reckon it's not going to be a problem: it's the sense of the image that matters, not the details.
And if you regularly serve 1MB+ images, maybe there's some sort of an indicator or tag that you could apply that will tell the browser: "Hey, look, I know you want to save bandwidth, but it's kinda my schtick to show really good images, so let me through, yeah?"
We're right at the point where people are starting to actively support 4K in web apps. Sure, not many web apps actually need it, but the ones that actually do (like photo browsers) definitely need it if they want to keep up with relevant trends over the next five years or so.
No: this doesn't make sense :/. The core problem is that stuff sits around executing some tiny input handler or animation in a loop, burning CPU. When I have tracked the tabs that are the worst performers down to the code causing a problem, it is never a large amount of code: it is some stupid mechanism that polls the position of something (like the cursor or the scrollbar), or is trying to push some analytics to a server.
This really has nothing to do with the amount of code being downloaded. I realize some people care complain about how much stuff they have to download, but that just isn't what is actually causing most people problems. Sure, tracking CPU is sort of annoying, but it absolutely isn't hard. Chrome already is running these things in separate processes (for security), and the operating system is tracking the time used for each thread: you can just ask it and make some kind of limit if that is what you care about.
I mean, in this article I see ideas for size limits for images, which is at least consistent... but that is going way way too far: 1MB just isn't good enough for a reasonable image. If you care so much about bandwidth, make a bandwidth cap for the page and if it exceeds it--across all media--figure out some way of blocking or punishing the site.
What most of us care about is that there seems to be no limit on the CPU usage of any given page. This is easy to fix--it is a virtual machine, after all!--by just doing the same trick Erlang uses for compiling a preemptive fiber and then limiting its time execution slices.
What I know I care a lot about is when a tab I haven't looked at in three days is suddenly using CPU time _at all_. Just make it so background tabs get severely limited in their ability to do background execution and eventually get stopped entirely, and the problem is essentially solved.
(Chrome, which is apparently already big on these size limits, doesn't do this, and I swear it is because it is against Google's interests to do it as it mostly makes it more difficult to do stuff like tracking and advertising :/.)