
How Web Content Can Affect Power Usage - ingve
https://webkit.org/blog/8970/how-web-content-can-affect-power-usage/
======
jakub_g
Re: JavaScript and networking:

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.

~~~
snek
I wonder how much energy would be saved if people stopped using recaptcha v3,
which is basically a perfect storm of event handlers and network usage.

~~~
sebazzz
And that would also break the power grap of Google. Everyone is training their
machine learning algorithms.

~~~
jjeaff
I don't think v3 actually asks any questions.

------
judah
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.

~~~
inetknght
> _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.

~~~
marmada
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".

~~~
saagarjha
> 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.

~~~
roguecoder
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.

------
TekMol
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.

~~~
Razengan
> _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.

~~~
TekMol
The browser _is_ a platform that runs applications aka websites. Nothing wrong
with that.

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.

------
latexr
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.

~~~
nottorp
I don't bother disabling js per site so I don't know about that, but I'm
pretty sure there is an uBlock Origin build for Safari since I'm using it.

[https://github.com/el1t/uBlock-Safari](https://github.com/el1t/uBlock-Safari)

~~~
lorenzhs
That isn't maintained any more, the last commit was more than a year ago. It's
stuck at version 1.16.

~~~
nottorp
Ouch. No way I'm going back to "i will prevent your system from sleeping for
arbitrary reasons" Chrome.

Maybe Firefox then...

~~~
1_player
Firefox is even worse in macOS

------
akersten
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?

~~~
ryacko
A tablet costs less than $10 in electricity per year. The energy to mine,
refine, and assemble the materials for a tablet is much higher.

The mindfulness in everyone trying to be more efficient would have a positive
impact on its own though.

~~~
Scoundreller
When we move to full OLED, ubiquitous night mode will drive down their
device's power usage.

------
dzhiurgis
Says company who refuses to implement VP9 (because other company doesn't want
to spend on x264 licenses).

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).

~~~
martinald
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).

~~~
nwallin
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.

~~~
zenexer
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.

[1]:
[https://www.mpegla.com/programs/avc-h-264/licensors/](https://www.mpegla.com/programs/avc-h-264/licensors/)

[2]:
[https://www.mpegla.com/programs/hevc/licensors/](https://www.mpegla.com/programs/hevc/licensors/)

[3]:
[https://web.archive.org/web/20170614042710/https://www.xda-d...](https://web.archive.org/web/20170614042710/https://www.xda-
developers.com/av1-future-video-codecs-google-hevc/)

~~~
nwallin
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.

------
vdnkh
> 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.

------
netheril96
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.

------
deedubaya
I wonder what the Internet's net power consumption is for server side vs
client side HTML rendering.

------
akling
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.)

Great post by Benjamin and Simon :)

------
bonyt
There is a search engine (that gets results from Google) with a black
background that claims to reduce energy usage on monitors.

[https://en.wikipedia.org/wiki/Blackle](https://en.wikipedia.org/wiki/Blackle)

~~~
tobr
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.

~~~
amiga-workbench
This site is really old, back when it was new, CRT's were still very common.

------
mirimir
OK, so TFA is for web developers.

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.

------
jakeogh
thread on email @
[https://news.ycombinator.com/item?id=20800439](https://news.ycombinator.com/item?id=20800439)

