"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 are you familiar with <picture> and <source>? they allow you to declare varying image qualities/formats, with user agents locally picking the best option
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture
💭 { my personal website makes heavy use of https://github.com/rbuchberger/jekyll_picture_tag to render images in jpeg/webp/jxl and output <picture> blocks }
@unlobito It's been brought up, but I'm unsure how this would be applied as a background image - aside from that, does this actually work to do progressive loading?
When specifying multiple `background-image`s, for example, Firefox will still just show a flash of white while loading the first one, and the fallback never seems to be used.
@joepie91 🙈 I should have pointed to https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set instead
it’s supported in all browsers as of 2023 (new to me!), but the front image on https://lobi.to/ is an older implementation that relies on z-index tricks to use <picture> as a background image
@unlobito Right, but then that doesn't do progressive loading? Since that's what I'm looking for.
@joepie91 i think we might be coming about this from different angles ^^;
i’m mostly thinking of resolution in a DPI sense, but i appreciate you might mean resolution in a photo quality sense
disappointingly, it seems there’s a gap in the CSS spec for explicitly signalling an image as only appropriate for high-bandwidth connections: https://github.com/whatwg/html/issues/4421
you could provide both PJPEG and webp for a given photo, but a browser might mistakenly pick the “slower” option :(
@unlobito Right, yeah, my concern is specifically network speed rather than screen resolution, and loading a reduced-resolution version first (whether quality or resolution) works around that issue
@joepie91 they’re selected based on the screen DPI
https://developer.mozilla.org/en-US/docs/Web/CSS/resolution goes into more details, also explains how 1x/2x/3x are selected