5 ms·

Power Consumption of JPEG, WebP, and AVIF

95 points by robin_reala 3y ago

amq 3y ago
Would be interesting to additionally see JPEG XL.
- Findecanor 3y ago
  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.
Pannoniae 3y ago
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....
- emllnd 3y ago
  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.
  - Pannoniae 3y ago
    Yup, I know that they are not the same, but they are measuring wall clock, and claiming it is power consumption....
    - zamadatix 3y ago
      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.
Sephr 3y ago
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.
- tyzoid 3y ago
  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.
- ksec 3y ago
  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.
tedunangst 3y ago
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.
codersfocus 3y ago
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...
- maigret 3y ago
  What you say is blatantly wrong. I advise you to read the book World Wide Waste. It changed my view on that topic.
- labster 3y ago
  He definitely emitted more carbon from us by not including an abstract at the beginning.
menotyou 3y ago
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.
Dwedit 3y ago
Note that Lossy Webp and Lossless Webp are two different file formats that happen share a file extension and library.
vlovich123 3y ago
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.
mikae1 3y ago
> 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 https://siipo.la/blog/is-webp-really-better-than-jpeg
- Dwedit 3y ago
  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.
- kristianp 3y ago
  https://squoosh.app/ https://squoosh.app/ Having a quick look at squoosh, it uses lossy compression of webp by default.
- ksec 3y ago
  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.
  - KronisLV 3y ago
    > 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.
Banditoz 3y ago
> 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/ 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?
- maigret 3y ago
  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.
- Telemakhos 3y ago
  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.
  - jwells89 3y ago
    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.
tommiegannert 3y ago
> Test 1: 103 µWh (0.000103 kwh) For those who like SI base units: 100 µWh is 360 mJ.
zamadatix 3y ago
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.
neilv 3y ago
> 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.
byyll 3y ago
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.
corysama 3y ago
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.
hristov 3y ago
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.
- izacus 3y ago
  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.
  - RetroTechie 3y ago
    In other words: if data goes over the air, [smallest files] practically always wins. (besides saving recipients' data budgets)
- youngtaff 3y ago
  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
  - TacticalCoder 3y ago
    Not really because the image is encoded only once and the image is typically then served over the Internet a huge number of times.
    - 3y ago
26fingies 3y ago
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
weitzj 3y ago
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
jeffbee 3y ago
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.
jeroenhd 3y ago
I'm surprised AVIF decoding is that more expensive. Is Firefox not using modern CPUs' hardware acceleration for AV1 to decode these images?
zeroimpl 3y ago
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.
sebbu 3y ago
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.
JyrkiAlakuijala 3y ago
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.

95 points by robin_reala 3y ago

amq 3y ago

Would be interesting to additionally see JPEG XL.

Findecanor 3y ago
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.

Pannoniae 3y ago

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

emllnd 3y ago
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.
- Pannoniae 3y ago
  Yup, I know that they are not the same, but they are measuring wall clock, and claiming it is power consumption....
  - zamadatix 3y ago
    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.

Sephr 3y ago

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.

tyzoid 3y ago
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.
ksec 3y ago
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.

tedunangst 3y ago

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.

codersfocus 3y ago

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

maigret 3y ago
What you say is blatantly wrong. I advise you to read the book World Wide Waste. It changed my view on that topic.
labster 3y ago
He definitely emitted more carbon from us by not including an abstract at the beginning.

menotyou 3y ago

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.

Dwedit 3y ago

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

vlovich123 3y ago

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.

mikae1 3y ago

> 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 https://siipo.la/blog/is-webp-really-better-than-jpeg

Dwedit 3y ago
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.
kristianp 3y ago
https://squoosh.app/ https://squoosh.app/ Having a quick look at squoosh, it uses lossy compression of webp by default.
ksec 3y ago
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.
- KronisLV 3y ago
  > 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.

Banditoz 3y ago

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

maigret 3y ago
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.
Telemakhos 3y ago
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.
- jwells89 3y ago
  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.

tommiegannert 3y ago

> Test 1: 103 µWh (0.000103 kwh) For those who like SI base units: 100 µWh is 360 mJ.

zamadatix 3y ago

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.

neilv 3y ago

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

byyll 3y ago

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.

corysama 3y ago

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.

hristov 3y ago

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.

izacus 3y ago
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.
- RetroTechie 3y ago
  In other words: if data goes over the air, [smallest files] practically always wins. (besides saving recipients' data budgets)
youngtaff 3y ago
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
- TacticalCoder 3y ago
  Not really because the image is encoded only once and the image is typically then served over the Internet a huge number of times.
  - 3y ago

26fingies 3y ago

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

weitzj 3y ago

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

jeffbee 3y ago

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.

jeroenhd 3y ago

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

zeroimpl 3y ago

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.

sebbu 3y ago

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.

JyrkiAlakuijala 3y ago

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.