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 tried this for a bit on mobile, but unfortunately it just breaks too much of the internet to be feasible. YMMV, and to each their own, but I'm not willing to sacrifice that much usability when an adblocker covers most use cases.
Power saving is great, except when it breaks apps.
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.
And they are obviously never going to fix it. You can’t give websites a way to run in the background on a phone, they’ll just drain the battery with analytics, ads, cryptocoin mining or just spinning. They can’t be trusted.
Apple OS's are already overloaded with permission dialogues. Add enough of them and you'll start to really frustrate users, and/or cause them to blanket accept everything.
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.
Webpages can play media in the background on Android, but it involves locking the screen, then pressing the play button on the lock screen to confirm that you really wanted that.
That would be the consistent way to solve the issue if Apple wanted web apps to be as powerful as native iOS apps. But they don't, and that ship sailed long, long ago.
> Power saving is great, except when it breaks apps.
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.
There seems to be a large concerted effort to make the browser the platform of choice for building apps, I see arguments all the time that web apps can be made to do what native apps can do and so forth, and that even if there is a lag in the development of web apps that lag will be covered in time and the network effects and ease of discoverability of web apps will triumph (I am stuck for time here so I had to summarize various arguments I've seen, I suppose others have seen them as well)
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.
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.
I was working on a SPA that needed to ask location information to tell the user service outages in their area, we spent a lot of time optimizing the permissions asking flow, making sure we didn't ask too often etc.
So I think companies with scruples, not malware oriented, or just possessed of good common sense will ask only when necessary.
There are already a bunch of those pop ups that trigger when a script tries to access the microphone, USB, camera, etc. There just isn't any unified API for asking for permissions.
I'm pretty sure your comment misunderstands the original comment, and even if it didn't, it is rather aggressive.
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".
Web technologies are not "suddenly" inferior to native technologies. They have always been inferior in some ways, and superior in others.
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.
> 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.
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.
But there is no case where it should be up to a web app whether its content should count as background audio. It is possible that a user should be able to flag such a situation, but native apps both have affirmative consent when downloading an application and have permissions models the user can manage, whereas the web has neither and web browsers need to assume both malicious and incompetent web devs will do terrible things with any feature they allow.
Because native garbage from the AppStore is at least vetted by Apple. For example background execution permissions will be subject to extra scrutiny by the reviewers.
Sorry, but I trust them more than those npm junkies saturating my pipes with adtech crap on every other corner of the web.
And with the App Store, the user has a chance to get an idea of what the app in question does and can make judgment calls as to quality, trustworthiness, etc before any code is executed.
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.
Instead of a permission prompt, Safari could make it so sites that use the Media Session API (https://developers.google.com/web/updates/2017/02/media-sess...) get to run code in the background if they have a media control visible in an active notification. (If the user doesn't want the site to run in the background, then the user could swipe away the media controller notification.)
I wonder if Apple is reluctant to do something like these because a website will use it to stay in the background (as the Facebook app did a while back) but in this case there is no App Store Review to force websites to behave.
This is one of the more frustrating limitations of the iOS mobile browser I’ve had to deal with. You can work around it by live streaming the music to the client, and handling track playback on the backend. Music Player Daemon is a good package to do this, but it will only handle one user per instance.
Building a react native version of your app shouldn’t take more than a few days and you could then integrate with the native expectations. Have you tried that?
As a first step, browsers should make extensions more powerful again. It's a pain that extensions are so teethless these days.
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
Look at the ID of the most busy tab. Let's say it's 1234
kill -STOP 1234
Boom! Immediately the tab is frozen and it's CPU usage drops to zero.
kill -CONT 1234
Now it is alive again.
To pause all tabs:
pkill --signal STOP firefox
And to continue:
pkill --signal CONT firefox
For Chromium, just use "chromium" instead of "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.
> As a first step, browsers should make extensions more powerful again.
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.
> As a first step, browsers should make extensions more powerful again.
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.
The most common reason for my computer fans to become audible is JavaScript on a webpage. That is insane, because in most cases it makes no difference to the content.
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.
Just some tangential food for thought: A few years ago Google did an Earth Day stunt where they set their homepage background color to black to symbolize saving energy by remembering to turn out the lights. It was tongue-in-cheek, but I've been curious ever since if major websites making a conscientious change to reduce JS execution and transfer bandwidth would have a measurable impact on worldwide power consumption.
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?
Sure it's not the other way round? Nearly everything has hardware h264 decoding. Google forces VP9 via YouTube which doesn't have hardware decoding on many (most?) devices so massive CPU usage (and virtually impossible to watch in 4K/60fps in software decode mode).
No. Virtually all devices since 2015 have hardware accelerated vp9 decoding. iPhones have had it going back to the iPhone 6.
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.
Since the Sorenson Video 3 / QDesign Music 2 fiasco in the 90ties, Apple has pushed hard for MPEG codecs, and when they were insufficient, for homegrown solutions (Apple Lossless).
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.
Apple partially owns the patents for MPEG4-AVC (H.264) [1] and HEVC (H.265) [2]. VP8 (WebM + WebP), VP9, and AV1 are threats to Apple's business because they're royalty-free. Apple wants to force companies to continue licensing H.264 and H.265.
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.
I've heard that angle, but it doesn't really make any sense. Samsung is also on that list, and all their SoCs since 2014 have had vp9 support. They've had vp9 support longer than HEVC.
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.
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.
Weird. VP9 playback on YouTube for Chrome is appalling on my newish laptop in 4K, which can deal fine with HEVC (at extremely high and difficult bitrates) in VLC etc.
> Apple is refusing to enable it in software because...
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?
Every single Intel GPU they ship in their computers has supported VP9 decoding for years.
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.
False. AMD supported VP9 decoding as of UVD6. Their APUs got UVD6 in Carrizo, released in June 2015. Some Volcanic Islands GPUs (June 2015) had UVD6, with a full rollout of UVD6 in all Arctic Islands GPUs. (June 2016)
Note that AMD didn't support HEVC (Apple's codec of choice) until UVD6 either.
Ok I've got latest generation Ryzen mobile. HEVC & H264 (both in native apps and YouTube chrome) is flawless using virtually zero CPU. VP9 in chrome is horrendous at 4K. Many complaints about this. Some saying that Ryzen only supports a very limited profile of VP9, which would make sense.
This is why I don't use Twitter much anymore, nor Instagram, nor FB, etc.
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?
> p.s. glad Safari finally shows offending Safari tab name in Activity Monitor (lately it's Twitters service worker that rip 100% CPU).
Biggest offenders by far for me are Facebook and local newspaper sueddeutsche.de - the latter one randomly have issues with advertisements or whatever.
> Avoid network polling to obtain periodic updates from a server. Use WebSockets or Fetch with a persistent connection, instead of polling.
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.
The biggest question now is how to incentivize developers to care about battery efficiency. Currently if your website is energy saving, the users cannot feel anything. Why bother spending time optimizing then?
Some kind of indicator of how much energy the current tab is consuming would be nice.
Having worked on WebKit performance in the past, it's great to see more of this knowledge being pushed out to web developers.
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.)
It actually uses more energy for most people's display devices to show black. It's because the screens are back-lit and it costs energy to block out the light rather than let it pass through.
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.
That doesn’t make sense at all for most types of screens. If anything, I wonder if a darker design might make visitors increase their screen brightness to compensate.
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.