"Two of the best ways to optimize images for the web are by using a modern image format (like WebP)"
"WebP does not offer a progressive or interlaced decoding refresh in the JPEG or PNG sense."
.... ok 🙃
As far as I can tell the 'incremental decoding' that webp provides instead is functionally useless for this purpose, it just gives you back the exact 56k-era line-by-line rendering that progressive decoding was supposed to get rid of (if the client implements it at all, which is optional)
Does anyone have any better suggestions for me than "go back to JPEG for my background images", to get reasonable-quality images on a webpage that still load comfortably on slow connections?
Note that anything that requires JS to function is not an option; I will not be implementing the pattern of "lazy-loading images after the fact", unless it can be made to work reasonably well without JS.
@joepie91 you can use to define multiple sources (e.g. AVIF and JPEG as a fallback), and i think you can just put defer as an attr for the lazy-loading
@lnl How would that work for background images?
@joepie91 ah, that's more annoying. i've done some z-index hacks myself but that site is down now
@joepie91 also, i just reminded now. chromium, gecko, and webkit put the "new" image formats in the accept header (webkit only if loading an img). depending on your setup you might be able to make use of that
@lnl Unfortunately it's not really a format problem, rather I'm trying to do progressive loading without JS, ie. a low-resolution version is visible while the high-resolution version is loading in the background
@joepie91 ah right, gts likes to just remove things that look like an html tag. picture tag. <picture>