How Web Content Can Affect Power Usage
webkit.org
webkit.org
My random observation tells that sadly most "modern" highly complex websites do it wrong and it can hardly be any worse (this applies to all web products I've been working on for last several years):
1) analytics beacons fired every N seconds (which means the network stack on mobile never goes to idle mode)
2) JS frameworks doing event delegation that capture mousemove events and various other stuff like that + various setTimeout/setInterval (perhaps from third-party code).
If you want a sample of 2) just open devtools > debugger on any page and click "pause". You will immediately hit a debugger in some just-now executing JS callback even if you do nothing at all on the page.
I disabled the extension, I don't even use it anymore.
Unfortunately, Webkit has broken certain web apps by their power saving features.
For example, on iOS, I have a Pandora-like web app that plays music. When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. I'm not doing any active JS, just an event handler for audio.ended event. The event handler never fires when my app is the in background or when the screen is off, thus, I can't play the next song. This effectively makes it impossible to build a functioning audio app/radio station on iOS using web technologies.
I've reported this issue to Apple some 2 years ago, but they still haven't fixed it.
Bonus: as of iOS 12, it also breaks web apps that are packaged with Cordova and published into the App Store.
That's a problem.
> Pandora-like web app that plays music. When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving.
I think that's intended. I would argue that you are misusing the web. I would argue that most users don't want websites to run while the browser isn't in the foreground. If you want to elevate your capability to interact with the user while in the background then build and install a native app or leverage existing native apps' functionalities.
> When my app is in the background and the current song ends, it won't play the next song because iOS has suspended Javascript execution in the name of power saving. The event handler never fires when my app is the in background or when the screen is off, thus, I can't play the next song.
That's good. I don't want garbage in the background to do anything javascript-related at all.
> This effectively makes it impossible to build a functioning audio app/radio station on iOS using web technologies.
Really? There are plenty of audio/radio apps on iOS using native technologies. You're trying to shoehorn something to do something it wasn't intended and then causing noise because it doesn't do what it wasn't intended.
> I've reported this issue to Apple some 2 years ago, but they still haven't fixed it.
What bug? You think this is a problem caused by power saving? No, it's not.
You've already stated that the song is playing until it ends, but that your javascript doesn't get notified that it ended. You think the problem is that power saving is stopping you from processing the next song to play. I disagree. I think the problem is that you aren't providing a play list to the browser. Frankly, I'm not a web developer so I don't even know if there is a playlist API. But if there isn't, then that is your problem.
A playlist would be a hell of a lot cheaper than trying to run arbitrary javascript.
Personally, I trust my browser a lot more than any native app. I cringe every time I'm forced to use a native app when the browser would do.
Why are web-technologies suddenly inferior to native technologies? Maybe I want my playlist to be accessible through a website from all my devices instead of having to download a native app on each device.
The company saves money/releases an app that would otherwise never have existed, and I get to use a service in a consistent manner across all platforms. Oh, and web-apps are more secure because they have less permissions than a regular app.
The author of the comment said web-app. That probably means a progressive web-app. This means there is an icon for the web-app on the home screen (like a normal app) and the user interacts with it, like a normal app, although in reality, everything is being handled by the browser behind the scenes.
> Progressive Web Apps are installable and live on the user's home screen, without the need for an app store. They offer an immersive full screen experience with help from a web app manifest file and can even re-engage users with web push notifications.
I would argue that in this case it makes sense for the progressive web app to have all the capabilities of a native app since that's what it looks like to the user.
Of course, if by web-app, the author means "a tab inside Safari browser", then the behavior is logical and your comment makes sense, we wouldn't want Safari to churn through iOS battery.
> That's good. I don't want garbage in the background to do anything javascript-related at all.
Why is "javascript-related" garbage better or worse than native-related garbage? Arguably, "native-related" garbage is worse because it can do more to your phone than "javascript-related garbage".
Presumably the issue here is that there is no special case where a progressive web app can let the OS know that the content it's playing should count as background audio.
Sorry, but I trust them more than those npm junkies saturating my pipes with adtech crap on every other corner of the web.
Letting javascript run when the browser isn't even in use would sacrifice one of the ways that web technologies are superior (nonintrusive when not in use) to make it a little less inferior in another way (ability to set up background tasks). That doesn't seem like a good tradeoff to me.
It shouldn't matter. Even if auto-playing music is a terrible idea for most sites, there should be a way to ask the user for permission where it is reasonable.
There has been some efforts to create a permissions API, which included MIDI devices (last time I checked), which might be able to support this: https://developer.mozilla.org/en-US/docs/Web/API/Permissions...
> You're trying to shoehorn something to do something it wasn't intended
That applies to almost all web content. Even hacker news doesn't fall into the original document browsing usage.
Beware the law of unintended consequences - if you did that, every single add would pop up an annoying permission box.
( And before you say “no, ...” remember that there are more unscrupulous ad/malware companies that will prove you wrong. )
So I think companies with scruples, not malware oriented, or just possessed of good common sense will ask only when necessary.
Your argument here is that there are classes of application that can never be built on the browser platform, based on you saying "You're trying to shoehorn something to do something it wasn't intended and then causing noise because it doesn't do what it wasn't intended."
That argument may be correct, however then Apple should make an open statement saying hey, web apps just won't do it. Otherwise people might mistakenly hear the arguments that they will do it and think I will make a web app. And the people making the arguments for web apps should be hit about how do you handle getting the app to work in the background when it is something that absolutely needs to like a radio station.
What? I built a music player, like Pandora. How is that misusing the web?
I don't want to build a native app. This is a side project for me - I don't have the time, resources, or desires to rebuild my app in proprietary technologies.
> I don't want garbage running in the background
If you're using my music player app, you absolutely want it running; otherwise the music stops.
> There are plenty of audio/radio apps on iOS using native technologies
I don't want proprietary native technologies, anymore than I want Flash or Silverlight. I want the open web.
> A playlist would be a hell of a lot cheaper than trying to run arbitrary javascript.
My app isn't a playlist. It's an app, akin to Pandora.
Desktop UI's are built around showing the user which programs are awake and active, and which are not. Mobile UI's are not. Unless/until that changes, users rely on the OS to make these decisions for them. It would be nice if we could rely on developers instead, but they will naturally be focused on their own app or page, not the system overall.
https://codereview.chromium.org/6577021
Works on mobile as well.
Much like the opt-in feature "Will you allow [website] to access your location?", there could be a "Will you allow [website] to operate in the background?" I think that is something that the community could get behind.
Then we could make a powersaving extension. It would allow a page a cumulative number of ms to use the CPU/GPU and a max number of network requests. After that it would display "This page has exceeded its quota of resources. Should all JS be halted? You can always continue the JS by clicking the little PowerSaver icon".
Here is a fun way to tame power intensive tabs (tried it with Firefox and Chromium and it works for both):
top
kill -STOP 1234
kill -CONT 1234
To pause all tabs:
pkill --signal STOP firefox
pkill --signal CONT firefox
So if we had something like native extensions, we could achieve a "pause button" by simply leveraging the STOP and CONT signal of the OS. If one were to look deeper into how browsers do their work, I wouldn't be surprised if we could target the signals more precisely and keep scrolling alive during the pause. Or we could CONT the process in case of a scroll event and then immediately STOP it again.
Another approach could be a "BrowserTamer" application that keeps the browser STOPped as long as there is no mouse/keyboard activity and CONT it for 100ms on scroll/keyboard activity. That could probably be implemented as a seperate program without help from the browsers themselfes.
That is a solution (though more like a remedy) to the symptom instead of the actual problem: Browsers trying to become operating systems and websites trying to be apps.
But I want that the user can configure the platform any way they like.
If you look at Linux, it's a bunch of files that you can alter until it behaves exactly the way you want it to.
Browsers feel much more monolithic. I would prefer them to be as open and accessible as Linux.
First, do note that hooking JS into everything also means a considerably less efficient browser. Extensibility has an overhead, extensibility in JS a much greater one.
Second, I don't see reason why something like this would ever be an extension, and not just default browser behavior. Are you viewing the page? Then it doesn't get to run unless you specifically allow it.
OR, make noscript the default state. There are very few websites that doesn't actually work just fine, and much faster without javascript enabled.
Mind you, this is on Chrome on a Macbook Pro; Safari is indeed better (kudos to the Webkit team). It’s a shame the amount of control Safari gives a user is laughable: content blockers can’t hold a candle to uBlock Origin and there’s no way to disable JavaScript and Cookies on a per-site basis.
Maybe Firefox then...
Kind of branches out to more questions like: how much energy is wasted running poorly optimized code (on the web and otherwise) where the same outcomes could be accomplished with code that executes fewer instructions? Should developers have an obligation or at least a conscience about writing performant code for the environment's sake? Would the impact even be measurable?
The mindfulness in everyone trying to be more efficient would have a positive impact on its own though.
Result is power waste on the order of small country.
p.s. glad Safari finally shows offending Safari tab name in Activity Monitor (lately it's Twitters service worker that rip 100% CPU).
If a human being pulled this kind of shit on me, I would have reduced my contact with them to a minimum a long time ago, since it would essentially be an abusive or at least one-sided relationship (that might have been great in the past.)
So why should it be any different for a website or service?
Apple is refusing to enable it in software because... TBH I don't know why. It's royalty free. I literally can't think of a reason besides juvenile pettiness.
There is no technical advantage to the MPEG family over the VP family. The VP family has widespread hardware decoding support going back many years, and the latest iterations provide significantly better results than the latest MPEG family iterations. Companies like AMD, Intel, Nvidia, ARM, and Broadcom are part of the alliance that developed AV1 [3].
There doesn't appear to be any incentive for Apple to continue blocking support for the VP family other than the fact that they're a licensor of HEVC.
[1]: https://www.mpegla.com/programs/avc-h-264/licensors/
[2]: https://www.mpegla.com/programs/hevc/licensors/
[3]: https://web.archive.org/web/20170614042710/https://www.xda-d...
The MPEG-LA isn't so much a business model as it is a pragmatic solution to patent trolls. I'm pretty sure Apple puts money into the MPEG-LA, not the other way around.
Which Apple is also a governing member of...
It may make more sense to adopt AV1, which is truly license and royalty free, but the encoding and decoding speeds are slower or just on par with other standards. Its only real advantage appears to be significant bitrate savings, so seemingly only streaming video providers would benefit.
Note that AMD didn't support HEVC (Apple's codec of choice) until UVD6 either.
Ambiguous, are you saying that they're not enabling the already-present hardware decoding on their devices in their software, or that they're not adding software decoding to their devices that don't support hardware decoding?
I read it as the latter at first, which had be very confused, so now I assume you meant the former?
OTH, AMD GPUs they use in some models do not support VP9 in their DSPs; under Windows, AMD used a shader-based decoder for DXVA acceleration up until models with VCN (Raved Ridge APUs), which do support VP9.
They have just chosen not to expose it to the userland. In past, they did something similar with Microsoft's VC-1 too: there's not a GPU that doesn't support VC-1 hw decoding, but Apple never exposed it either.
iPhones and Intel CPUs have hardware that decodes many different codecs, including vp9 and h264. iOS and OSX have drivers that make hardware decoding available for h264, however they do not make available vp9 decoding, despite the fact that the hardware is perfectly capable of doing it.
So you fallback to software decoding, which is problematic at 4k/60fps. People falsely blame YouTube/Google, when it's actually Apple's problem.
So they ignored free codecs, like Vorbis, FLAC, Speex, VP8, VP9, they would ignore Opus if it weren't in WebRTC (and still doing everything possible to contain it there), they are ignoring mkv containers, and also non-free codecs like VMA and VC-1. They know that ignoring AV1 in the future won't be so easy, but until then, they will continue push for MPEG and make use of non-MPEG harder.
Biggest offenders by far for me are Facebook and local newspaper sueddeutsche.de - the latter one randomly have issues with advertisements or whatever.
Oh the irony. Apple’s new low-latency streaming spec is based around polling the server multiple times per second, for the entire duration of a live stream. The FOSS version of low-latency HTTP streaming is based on chunked-transfer encoding via a...persistent fetch connection. Despite chunked-transfer low-latency steaming being widely deployed in production for the past few years (Twitch, Periscope use this), they didn’t think it was the right solution. I wonder what the WebKit team thinks of this.
Some kind of indicator of how much energy the current tab is consuming would be nice.
These are things browser developers have known about for a long time, but we generally always tried to "just make things work" in the browser instead of asking web developers to help out on their end (and making tools to assist with that.)
Great post by Benjamin and Simon :)
And OLED is becoming the standard for smartphones which represents the majority of web traffic.
Blackle was only really useful when CRT screens were around. It could be useful on OLEDs which are not back-lit but they have shorter life spans due to burn-in.
But it's still funny that it doesn't mention ads. Especially ads that run video. Reducing power usage is an important befit of using ad-blockers.