Power Consumption of JPEG, WebP, and AVIF | Hacker News Reader

Power Consumption of JPEG, WebP, and AVIF

fershad.com

95 pointsrobin_reala48 comments

> The grid intensity in your location is 387 g/kWh. That's higher than average, so this site has been modified to use less power on your device.

Interesting, my location has "high grid intensity", so it showed me a lite version, with low-res images and some JS <script> tags commented out.

But the author explains the steps to determine this:

1. A Cloudflare Worker checks the request object for the country a visitor is located in.

2. If a location is found, then a fetch request is made to the CO2signal API CO2signal sends back data about the current grid intensity at the visitor's location.

3. The current grid intensity is checked against the annual average grid intensity for that country (data from CO2.js).

4. If the grid intensity is equal to or greater than the annual average, then the HTML response is modified using the Cloudflare Workers HTMLRewriter. If the grid intensity is less than the annual average, the regular (unmodified) site is returned to the user.

(https://fershad.com/carbon-aware-site/)

Surely all these steps combined above use more power than just sending the unchanged HTML page to the user?

Might be. For sure anyone should optimize no matter what. Of course now many developers only consider the number of feature they produce or use (“shiny new library! Will fit well on my CV!”), but there is a big satisfaction of improving existing things as well.

But to decide whether this approach works, we should first test it, improve it, and then we can benchmark it.

I find the idea interesting. Could be cached for all pages, or handled by the browser. It would be massively interesting in gaming and streaming, helping also support old devices better.

Why not always send the smaller, simpler version, if it is functionally equivalent to the one with extra javascript and bigger images? Surely that would be simpler and save even more energy.

My thoughts exactly. Maybe add a button that can load the "HD" version of a site if the user actually wants it, but I suspect for many types of sites and many users it really doesn't matter.

I’m in CA and got the same notice. But I checked the grid intensity and it’s emitting 146g/KWhr.

http://www.caiso.com/TodaysOutlook/Pages/emissions.html

So the data might be wrong as well which may mislead the user.

Tweeted at him here: https://x.com/edwardstarcraft/status/1695508531028566090

I thought it was measuring grid intensity in a different sense, like high/low demand for energy. (Sometimes, the grid has high demand for electricity, and other times the demand is lower, maybe even such that wholesale electricity prices are negative.)

Now that I think about it, I'm wondering whether Google could change electricity prices by e.g. flipping a switch on YouTube H.264 availability in a particular region...

How much power consumption is being used for these API calls and special scripts to calculate CO2 usage?

All the Workers stuff runs on a machine that your request was already going to pass through anyway, and does very little actual work compared to everything your client machine has to do to render a complex site. I would guess that part of the work is easily offset.

The only question is really step 2: How much work is required to communicate with the CO2signal API? If that API is also in a Worker and/or is able to make good use of the local Cloudflare cache then it might be quite cheap. If it has to talk to an external server somewhere then it's hard to say.

With all that said, presumably the net effect is negligible either way and the real goal is to raise awareness and demonstrate how these APIs could be used.

(disclosure: I'm the lead engineer for Cloudflare Workers.)

This is completely pointless without considering the power used to transmit the data. He has AVIF using about 30% more power than Webp, while creating files a little more than half the size of webp.

Well one has to consider the power used to transmit the files. If I had to guess the power to transmit is much higher than the CPU rendering power and one should just optimize for smaller file sizes while keeping image quality and rendering time acceptable.

For the usual person to get that file on the internet, one needs the processors of about 20 routers/switches and the like to move the data back and forth, the data has to go through a couple of hundred of kilometers of distance (at least) on fiber optic, the signal being generated by power hungry lasers, etc.

I work on mobile and power use of radios seriously eclipses power use of any media decoders later - there's a reason why "race to idle" is so important to battery life.

This article is kinda funny and quanit with it's carbon calculations while ignoring the biggest difference in power use.

In other words: if data goes over the air, [smallest files] practically always wins.

(besides saving recipients' data budgets)

You would also need to consider the power usage to encode the images and AVIF can be pretty high there and it’s computational costs are larger than the other formats

Not really because the image is encoded only once and the image is typically then served over the Internet a huge number of times.

One should still add them up, the results may be surprising

(One should also account for the energy spent bookkeeping all energy expenditure)

IRL an image is likely to be transcoded multiple times…

Say you upload a high res source image to Cloudinary (or similar), then it gets requested in multiple sizes… each size will need to be generated.

Each generated version might be cached for a while but then at some point will get evicted so will need to be regenerate when someone requests it

I’ve worked with sites where this is exactly the case

> The grid intensity in your location is [...] g/kWh. That's higher than average, so this site has been modified to use less power on your device.

They could cut their resource usage further, beyond that of the power-saving version of their site, by getting rid of the power-saving detection behavior. Just do the sensible version all the time.

Their actual HTML is pretty clean.

Does seem pretty incomplete to not consider download time, etc. My browser doesn't turn the screen off while downloading images, and that uses way more power than decoding the image does.

I think the author will emit more carbon in their lifetime worrying about the web's carbon footprint than the web will emit.

Of ALL the problems with environmental sustainability, you picked this one...

What you say is blatantly wrong. I advise you to read the book World Wide Waste. It changed my view on that topic.

He definitely emitted more carbon from us by not including an abstract at the beginning.

The compression density should be roughly the same for such experiments. AVIF and WebP slow down when more detail is added, jpeg a little less.

Jpegli will make smaller jpegs that are faster to decode.

I don't see the point of computing the second derivative (not in the mathematical sense, in the everyday sense) here. Energy usage is a derivative of performance, which is a derivative of time spent on running the thing.

Why didn't the blog just compare the speed of those algorithms? Power consumption is just calculated by multiplying the runtime by a constant here, it's not measured by a power meter or anything....

Wall clock speed does not correlate linear to power consumption (in the general case). To oversimplify, consider decoding singlethreaded on one core versus multithreaded on 8 or 20 cores.

In some special cases multiplying runtime might be enough to achieve some accuracy, but that’s not the whole story.

It would be interesting to see this experiment done so that the decode is done enough times for each format so the power consumption differences could actually be measured on a power/watt meter.

Yup, I know that they are not the same, but they are measuring wall clock, and claiming it is power consumption....

Where did the author use wall clock as a proxy for power consumption? The only time based thing I saw was power usage over time and that is still measuring power usage directly just explaining when in the process the most power was used.

There is a nugget of a good idea here. My user agent should be able to inform the site of my sensitivity to local resource usage. Perhaps I have a fast and efficient computer, or a powerful one with a zero-emissions primary power source. It would be nifty to communicate my preferences along with the request. But I can't see it being anything more than an irritant if a site tries to infer such things on my behalf.

> Test 1: 103 µWh (0.000103 kwh)

For those who like SI base units: 100 µWh is 360 mJ.

Testing on Firefox makes these figures not entirely useful due to a lack of support for some hardware decoders.

I'd like to see an ideal comparison using hardware-based decoders all from the same vendor and the same manufacturing process node.

Are there any hardware accelerated decoders for static images? AVIF and WebP's lossy (vp8) codec might have some support, but I'm be curious to see what percentage of browsers actually have support for accelerated decoding.

Most if not all ( I am not even aware there is one ) browser dont use hardware decoding for images. Hardware decoding is only used for video.

Would be interesting to additionally see JPEG XL.

Indeed. I expected it to be included before reading.

But I would also expect JPEG-XL to score worse than Webp and old JPEG at the moment because it is newer and implementations could therefore yet be less optimised.

I have to imagine that over time AV1 will get better CPU and hardware acceleration as happens with h264. Not sure measuring “carbon footprint” is too elucidating.

A lot of screens these days are OLED and as I understand it they use more energy when displaying light images than dark images. The screen is also a major power hog. So I wonder what the energy tradeoff would be by using a dark background instead of changing image formats

> There’s plenty of guidance for developers to use modern image formats like WebP and AVIF which generally have a smaller file size compared to older formats like JPEG.

I wouldn't consider WebP over JPEG for lossy compression of photographs: https://siipo.la/blog/is-webp-really-better-than-jpeg

Lossless WebP trounces PNG for compression level, and decompresses very fast too. Lossless JPEG-XL compresses better than Lossless WebP most of the time, but cannot compete for decompression performance.

https://squoosh.app/

Having a quick look at squoosh, it uses lossy compression of webp by default.

Funny in 2023 this is still a topic of debate. I suppose one could argue WebP is now officially supported everywhere why not use it for however small the difference advantage it might have.

> WebP is now officially supported everywhere

I wish, there is still occasionally some weird behavior, like when you take an image from Reddit that's a WebP file and try to past it into WhatsApp through the clipboard. It doesn't upload as a regular photo that you could add a comment to or edit it, but instead as a file, even without a proper thumbnail preview. Super annoying and I don't think that there are that many good reasons for this to be a thing.

Then again, if you don't care about use cases like that and just want to store images on you website, you can probably just pick what seems like the best option for your own needs. I'd go with JPEG or PNG just because they've been around forever, at least for as long as I don't have to worry about bandwidth too much.

Note that Lossy Webp and Lossless Webp are two different file formats that happen share a file extension and library.

Another good control to add would be not using the default settings in Sqoosh.app. Just because one format defaults to high compression and another low compression does not say anything about which is more power efficient at compressing. Ideally you'd match up the optimized visual quality.

Though really I'm not sure this question makes sense in the first place. Optimizing the power used by the client during decode specifically seems unlikely to be the best way to optimize power usage of the website transfer. In particular, optimized transfer time of the same fewer total bits to all clients should far outweigh any savings from using a lighter-to-decode image format.

Video would be a whole different world. I wonder how the energy efficiency of different hardware decoders compares for even the same format.

Not on this topic, but I wonder why on your cell phone you have to opt-in to safe battery/energy.

Like what amount of energy could you save with the leverage of iOS/Android if people were to opt-out of energy-saving mode

Reminds me that all browsers (except opera presto) conserves all images from the current page in raw pixel (or BMP) format in memory, whether they're currently shown on screen or not. There has been a few bug reports (OOM) in firefox 4 (and the chrome version of the time) that got never fixed.

I had a page that was showing a few thousands DVD covers (in jpg, around full hd resolution), it crashed all browsers except opera presto.

Interesting experiment though the writer is write it's very tiny. Only 1 browser on 1 OS on single hardware, not taking into account energy spent for conversion as well as time using a device spent for the code doing the conversion. Also not taking into account if results would differ if a page has 5 images instead of 1. Many variables.

Related I’m surprised how slow my Mac is at rendering HEIF images compared to JPEG. Reviewing photographs transferred from my phone after a vacation is almost painfully slow. Seems like that format really requires hardware acceleration.

I would expect transmission of the data to require far more energy than decoding. Even loading the data from local storage should outweigh decoding. Math is cheap, but bits are heavy. Moving them is slow and expensive.

Would be interesting to research certain other protocols. I believe using XML is relevant problem for the climate as the ubiquitous XML parsing is notoriously CPU hungry compared to more traditional protocols.

I'm surprised AVIF decoding is that more expensive. Is Firefox not using modern CPUs' hardware acceleration for AV1 to decode these images?

Reply on news.ycombinator.com