Image sizer should output interlaced/progressive JPGs

[jmartsch]

Short description of the enhancement

Add interlaced loading of JPGs

Optional: Steps that explain the enhancement

1. Take a progressive/interlaced JPG (or a baseline JPG)
2. Upload it to a PW image field
3. In your template output a resized image foreach($page->images as $image) { $large = $image->width(500); $thumb = $image->size(100, 100); echo "<a href='$large->url'><img src='$thumb->url'></a>"; }

Current vs. suggested behavior

The ImageSizerEngineGD.php should output progressive/interlaced JPGs instead of baseline JPGs. Every major browser supports this right now. It is 2017 (almost 2018). You could add an optional parameter, to be compatible with old browsers. But progressive should be the default. Here is a nice comparisation between the two formats: http://bbshowcase.org/progressive/

This feature request was also mentioned here https://github.com/ryancramerdesign/ProcessWire/issues/1915 and here https://processwire.com/talk/topic/4573-add-support-for-progressive-jpeg/

Why would the enhancement be useful to users?

The perceived loading time of your website would be lower, especially on slow connections on mobile. A user sees the image much quicker, but in lower resolution.

There is a good article of Perceived vs. Actual Loading Time over at http://blog.teamtreehouse.com/perceived-performance

[teppokoivula]

@horst-n, is this perhaps something that you could take a closer look at? :)

[horst-n]

Hi, there are functions available for GD and Imagick too, that allow to save images as progressive/interlaced versions. It would be not more than to add a few lines (3-4) of code into the imagerendering engines to change it.

Only one open question is, should we drop support for baseline images with this change, or should we introduced a new $config->imageSizerOptions key for that? (for example: 'progressiveOutput' = true,) And then let the user decide which one he want to use? And if the later, what should be the default vallue for the new key, disabled or enabled?

Ping: @teppokoivula @ryancramerdesign

[ryancramerdesign]

I agree there should be a config option for it, though don't know if it should be disabled or enabled by default. Maybe disabled, for consistency with existing behavior? Horst, if it's just 3-4 lines of code, maybe paste here (or email) what we should add, and I can take care of making sure it's got an appropriate key and conditional for imageSizerOptions.

On Sat, Nov 18, 2017 at 5:25 AM, horst notifications@github.com wrote:

Hi, there are functions available for GD and Imagick too, that allow to save images as progressive/interlaced versions. It would be not more than to add a few lines (3-4) of code into the imagerendering engines to change it.

Only thing is, should we drop support for baseline images with this change, or should we introduced a new $config->imageSizerOptions key for that? (for example: 'progressiveOutput' = true,) And then let the user decide which one he want to use? And if the later, what should be the default vallue for the new key, disabled or enabled?

Ping: @teppokoivula https://github.com/teppokoivula @ryancramerdesign https://github.com/ryancramerdesign

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/processwire/processwire-requests/issues/134#issuecomment-345433006, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUCUMr0ORRkReC_0oQqZ8AIf-TFswC6ks5s3rCagaJpZM4Qh5mP .

[teppokoivula]

I'm not an expert on this topic, but at this point I'd say that a) introduce a new config key and b) set it to disabled by default. At a later point, if users really enjoy this, the default value could be easily switched without breaking anything (at least more than setting it to enabled by default at this point would, anyway).

Interestingly some quick googling brought up this study from Radware (2014) that actually suggests that some users might prefer non-progressive images over progressive ones. I still think that the benefits are greater than the drawbacks, though, particularly with increased mobile traffic.

[jmartsch]

Hi guys, thanks for catching up to this.

It is funny, that the progressive format is not used more widely, because back in the days of 56k it was a so called standard ^^

I agree that the old behaviour (baseline jpg) should stay as the default, so one is not surprised if he updates PW and the image loading is now different.

It would be good if we have a general setting to enable or disable progressive rendering in the config file, and it could additionally be an option for the image sizer functions, to enable or disable progressive rendering for specific images. for example you could do this: $options = array( 'quality' => 90, 'progressive' => true ); $img = $image->size($x, $y, $options);

[jmartsch]

Another very good article including advantages and disadvantages is available at https://cloudinary.com/blog/progressive_jpegs_and_green_martians#advantages_and_disadvantages. It even includes an in-between solution.

[horst-n]

@ryancramerdesign Hi Ryan, I have uploaded the needed changes. Please don't forget to also incorporate this into PageImage and the $config->imageSizerOptions. Sorry, that there is not more time for this on my site atm.

https://github.com/horst-n/processwire/blob/f072a52ccec7ffadd6831b5002ebd0b569274216/wire/core/ImageSizerEngine.php#L61-L69

https://github.com/horst-n/processwire/blob/f072a52ccec7ffadd6831b5002ebd0b569274216/wire/core/ImageSizerEngineGD.php#L286-L295

https://github.com/horst-n/processwire/blob/f072a52ccec7ffadd6831b5002ebd0b569274216/wire/modules/ImageSizerEngineIMagick.module#L337-L342

[horst-n]

please also see this one: https://github.com/horst-n/processwire/commit/89bc914467071efedb70394bfea063c57c56778f

[horst-n]

A small note to the discussion: I personally do not use progressive images. I use srcset or picture tags with a lowres version as default src, or sometimes an embedded transparent base64 data bit for fast page loading. The above combined with optimized srcset variations seems to be the best combination IMO.

[ryancramerdesign]

Thanks @horst-n ! I have added your code for interlaced images and tested it out and seems to work well (seeing visually identical but smaller file size JPEGs).

[jmartsch]

Really cool to see this integrated so quickly. Thank you.

[jacmaes]

I've upgraded a few hours just after this commit (without realizing), and some of my images are randomly not loading (even after clearing the cache). Google Maps Static Images are also giving me errors. I can't be sure if it's related to this, but downgrading to 3.84 returned everything to normal.

[horst-n]

@jacmaes, do you have explicitly enabled the interlace feature? Or do you have only updated the wire folder?

[jacmaes]

@horst-n no, I haven't explicitly enabled the feature. Actually, the seemingly random issues I was having was with your "croppable image 3" module: the URL for some of them would not be recognized, and therefore these images wouldn't load.

[horst-n]

The changes to imagesizer were only an additional option. No changes to filenames or urls. Hard to say whats going on. When you are not using the new interlace feature, nothing should have been changed.

[jmartsch]

Here is a brandnew article "Taking A Look At The State Of Progressive Images And User Perception" https://www.smashingmagazine.com/2018/02/progressive-image-loading-user-perceived-performance/ It's worth a read!