search

zerodevx / svelte-img

High-performance responsive/progressive images for SvelteKit
https://zerodevx.github.io/svelte-img/
ISC License
300 stars 11 forks source link

Progressive JPG loading with callback #48

Open MentalGear opened 3 months ago

MentalGear commented 3 months ago

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.

WebP is usually 20%-30% smaller than a JPEG of equivalent quality, but progressive JPEG appears to load 50% faster. [JPGs] at 50% of the data the image looks almost as good as when the whole file is delivered.

Screenshot 2024-03-12 at 00 51 44

Blur could smoothen the pixels.

Would you consider adding support for these with progress callback to for example update a progress bar or the blur amount.

leoj3n commented 3 months ago

https://github.com/JonasKruckenberg/imagetools/issues/567

leoj3n commented 3 months ago

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 preload in <head> as explained in https://github.com/zerodevx/svelte-img/issues/41 and perhaps obviating the need to send LQIP/css gradient bloat.

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 <picture> with multiple <sources>.

A string-replacement approach like enhanced-img is going to be more optimal than component-based approaches like svelte-img and unpic-img because it doesn't have to ship the component bloat, it just results in a standard <img> tag.