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.

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

Why not progressive? #54

Open
JasonMrX opened this issue Mar 17, 2017 · 9 comments
Open

Why not progressive? #54

JasonMrX opened this issue Mar 17, 2017 · 9 comments

Comments

@JasonMrX
Copy link

JasonMrX commented Mar 17, 2017

Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.

I thought that image-heavy websites prefer progressive mode than sequential mode (facebook, instagram), etc). I haven't done bench marking myself, but how much faster is sequential mode in terms of decompression speed?

@robryk
Copy link
Contributor

robryk commented Mar 17, 2017

Decompression speed of progressive JPEGs is 10-200% slower; the slowdown is worse on underpowered devices. This matters even more when we have an image that is already cached on an underpowered mobile phone.

@kornelski
Copy link

If you're more concerned about bandwidth than CPU time, you can use MozJPEG's jpegtran to losslessly convert Guetzli images to progressive. This even reduces file size further.

@tomByrer
Copy link

@robryk A website that is properly configured won't be serving small devices full-sized images, so your CPU concern won't have that much impact. Also with HTTP2 PJEPGs could be rendered to screen faster regardless.

@pieroxy
Copy link

pieroxy commented Mar 20, 2017

@tomByrer I would argue that a properly configured website will serve high density screens bigger images, if only because they have more pixels to display them. Coincidentally, those screens are often the smaller out there, in phones and tablets. So small devices are likely to get served bigger images than desktops and laptops.

@ghost
Copy link

ghost commented Mar 23, 2017

@JasonMrX If you're using Windows, try jpegtran_do_plus. I found it yesterday and it work well.

@tomByrer
Copy link

@pieroxy Often mobile will have different 'art direction' (cropping) than a desktop or even 4k site would have.

You're correct that DPI should be a concern for many web images; something I intend to address with progressive. A full explanation is worthy of a blog post, not a GH-issues discussion ;)

@pieroxy
Copy link

pieroxy commented Mar 24, 2017

Agreed. FYI I wrote a small piece a while back on how to compress images for high-dpi screens.

http://pieroxy.net/blog/2016/05/01/jpeg_compression_is_80_the_magic_quality_part_1_the_retina_screens.html

@tomByrer
Copy link

chances are that you will serve your bigger images to your slowest users. That doesn't sound right.

hehehe :)
Looking at your examples on my regular desktop 1080p, it would seem that retina-sized at higher compression would be best for both screen types. Another article came to the same conclusion.

@pieroxy
Copy link

pieroxy commented Mar 24, 2017

Looking at your examples on my regular desktop 1080p, it would seem that retina-sized at higher compression would be best for both screen types

... and would be much bigger than a lower compression of a non-retina version, so no, it was not my conclusion. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants