Progressive JPG loading with callback #48
Comments
|
A benefit to preferring progressive jpg over webp->avif->jpg is less redundant markup sent over the wire, especially when using multiple sizes across multiple fallback image types (even though gzip does a good job of compressing it), faster build times and less storage cost for redundant images, the ability to use It's not entirely clear to me if Cloudflare is required to see all the benefits they mention, or if any regular H2 server would work as well. Sound like they may be doing some server-side optimizations not available outside of paid CPU on cloudflare. Edit: https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web#serversideprioritization EDIT (other thoughts): Cloudflare and Vercel both have the user agent checking feature, where they send a 304 if the user has the latest image in cache, otherwise automatically sending the supported webp/avif/jpeg depending what the UA says they support. Settling on a single image format such as the progressive jpeg would eliminates any need for this 304 dance and so reducing unnecessary network requests that would be incurred when choosing this method over A string-replacement approach like enhanced-img is going to be more optimal than component-based approaches like |
Thx again for this most excellent library !
Progressive JPGs can provide great content hints in faster time than current image loading/blur LQIP. There's a whole study done by cloudflare on it, describing that progressive JPGs might even be more desirable than webp depending on the case.
Blur could smoothen the pixels.
Would you consider adding support for these with
progresscallback to for example update a progress bar or the blur amount.The text was updated successfully, but these errors were encountered: