16 replies

1. Kornel Mastodon 18 min later

   @zachleat Yeah. You should be getting better quality, sharper color.
   Number of browsers that support WebP but not AVIF is shrinking, so maybe save some time by dropping the WebP alternative?

   1. Zach Leatherman Mastodon 39 min later

      @kornel valuable advice, thank you!

   2. Michelle Barker Mastodon 47 min later

      @kornel @zachleat In case it affects your opinion, @fershad wrote about the relative power consumption of different image formats a while back: https://fershad.com/writing/power-consumption-jpeg-webp-and-avif/. Based on those findings I wouldn’t want to drop WebP. Things might’ve changed since then though.

      1. Eric Portis Mastodon 1 hr later

         @michelle @kornel @zachleat @fershad I discussed this article with @jonsneyers when it was published. He pointed out that the energy used for network transfer from the server to the client should be accounted for; especially on mobile (radio), this costs much more than CPU decoding. He raised two other points:

         - Energy used to light up the display > both network and decode costs
         - Encode costs, esp. for AVIF, dwarf decode costs. Worth thinking about # of loads.

      2. Kornel Mastodon 1 hr later

         @michelle @zachleat @fershad I don't think this should affect anyone's decision about use on regular web pages. The energy usage in absolute terms is too tiny to matter, even multiplied by millions it's still small.

         But from overall energy efficiency perspective you should also consider that larger files will use relatively more energy on all the network equipment that sends them.

         Computers and displays also use energy while waiting for a page to load. Faster pages reduce wasted time.

         1. Zach Leatherman Mastodon 1 day later

            @kornel @michelle @fershad fwiw I went with your advice and I’m using `avif, auto` for now!

         2. fershad Mastodon 1 day later

            @kornel @michelle @zachleat @eeeps thanks for this conversation. I understand the comments about the network energy, especially for radio networks, I didn't test that segment because:

            1. There's no reliable means to measure it
            2. Network energy is (as far as I know) pretty constant https://fershad.com/writing/website-carbon-beyond-data-transfer/#data-transfer-network-energy-usage

            Eric's points on encoding are very valid, as is Kornel's point about efficiency. Both should be measured further in a more end-to-end kinda test scenario.

2. elle mundy Mastodon 20 min later

   @zachleat 2 seconds for a more compatible, higher efficiency codec? yeah i’d say so. that time difference may even be just noise depending on what else the build server is doing

   1. Zach Leatherman Mastodon 43 min later

      @exchgr yeah 100% I think the uneasiness there is mostly around the the reliability of the build cache — largely out of my control

      1. elle mundy Mastodon 45 min later

         @zachleat oo yeah that might be concerning then. not sure if this helps or what the use case is, but i’ve been using cloudflare images, which handles the transcoding for me (although it’s limited in some slightly frustrating ways)

3. Snugug Mastodon 23 min later

   @zachleat absolutely. AVIF's widespread support is why I need to jump through hoops to support HDR images, and find it generally better than webp

   1. Zach Leatherman Mastodon 43 min later

      @snugug thank you!

4. Private reply Mastodon 50 min later
5. David Moll Bluesky 7 hr later

   What does cold and warm mean in this context?

   1. Zach Leatherman Bluesky 7 hr later

      Cold cache, warm cache. Cold cache means it’s operating from scratch. Warm cache means a previous build has already run to establish a faster baseline for the next build.

      Specifically www.11ty.dev/docs/plugins...

      1. Zach Leatherman Bluesky 7 hr later

         Also www.11ty.dev/docs/deploym...