Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Progressive JPG loading with callback #48

Open
MentalGear opened this issue Mar 11, 2024 · 2 comments
Open

Progressive JPG loading with callback #48

MentalGear opened this issue Mar 11, 2024 · 2 comments

Comments

@MentalGear
Copy link

MentalGear commented Mar 11, 2024 •
edited
Loading

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
Copy link
Contributor

leoj3n commented Mar 14, 2024

JonasKruckenberg/imagetools#567

@leoj3n
Copy link
Contributor

leoj3n commented Mar 14, 2024 •
edited
Loading

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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@leoj3n @MentalGear