"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)
@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 (I think part of your reply got lost?)
@joepie91 ah right, gts likes to just remove things that look like an html tag. picture tag. <picture>
@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 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 Hmm. Assuming you're referring to the resolution selector, how does the browser select the resolution(s) to load?
@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
@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
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.