Reduce image weight, welcome hidpi screens

[sndrs]

What does this change?

Updates imgix settings, based on @paperboyo's reseach:

• reduces quality from from q=85 to q=55
• adds fit=max to prevent upsizing images beyond the original
• changes sharpening to use usm=12 (no idea, ask @paperboyo!)

It turns out you can drop the q enormously if you serve higher resolution images for hidpi screens, so it also:

• reduces quality from q=85 to q=20 for JPGs on @1.25x+ screens
• serves dpr=2 non-PNGs to @1.25x+ screens
• serves dpr=1.3 PNGs to @1.25x+ screens (PNGs aren't affected by q)

What is the value of this and can you measure success?

Reduces image payload while improving or maintaining quality. The actual saving depends on browser capabilities and the content of the images, but for the current UK network front, desktop breakpoint:

format	current	@1.25x+	@1x
JPG	1847kb	862kb	754kb
WEBP	572kb	442kb	421kb

As mentioned above, q doesn't actually affect PNGs, which we use for cutouts. The affect of serving them @2x too is great (Steven Trasher's cutout on a standard item went from 12kb to 45kb). Offering a 1.3 version increases the file size to 19kb while still looking sharper.

Screenshots (hidpi only)

Non-hidpi look near enough identical.

Differences in these hidpi screenshots won't really be noticeable on non-hidpi screens…

before

### after

## Request for comment

@paperboyo, @jennysivapalan / @rich-nguyen for scala ;)

[dominickendrick]

What is the percentage size reduction ? 20% for png, 50% for JPEGs? How much bandwidth do you think we'll save ? What about 💰 ?

[dominickendrick]

This is awesome btw!

[paperboyo]

Enormous thanks goes to @sndrs who did all the work! And had to put up with me.

adds fit=max to prevent upsizing images beyond the original

I would love, pretty please, for that to be accompanied in some foreseeable future with an adjustment to how we display images in the Lightbox (because this will affect them). After this goes out, if image will be smaller than Lighbox'es viewport, it will sit at the top not stretched to fill full width looking silly (currently the lack of fit=max takes care of it, by requesting the upsized image - absurd and costly but works).

I offer 🍺 to anyone who could take a look at that. Or two.

How can we measure average daily bandwidth savings, d'you think? Or whatever would be the nicest-looking stat? :)

(EDIT: issue opened: #12215)

[sndrs]

After this goes out, if image will be smaller than Lighbox'es viewport, it will sit at the top not stretched to fill full width looking silly

shouldn't fit=max be part of a PR that deals with that then? rather than this?

[paperboyo]

There is this question of de-caching... By "foreseeable" I've meant whenever. Just not "never" 😆 Most obviously, that's subject to what you think is worth doing...

[paperboyo]

In the best tradition of my not-PR-related comments, there is much more optimisation we might want to do to Lightbox, e.g.:

http://www.theguardian.com/environment/gallery/2015/sep/14/the-british-wildlife-photography-awards-2015-winners-in-pictures#img-7

weights 3,7MB and measures 2872px vertically on my 2560x1600 monitor ([EDIT somehow Lightbox is dpr=1:] 2,7MB and 5755px 2,1MB 2872px after this goes out) 😆

(EDIT 2: here is @rich-nguyen’s great explanation of how this should be handled: #12216 (comment))

[OliverJAsh]

Awesome! Good description of the change :-)

I made a table to help me understand how and when we vary q and dpr which might be useful to others. Is this correct?

	q	dpr
JPG, @1.25x+	55	2
JPG, @1x+	55	1
PNG, @1.25x+	20	1.3
PNG, @1x+	55	1

Scala looks mighty fine to me 👍

[sndrs]

the pngs do get the param (all requests do), but it has no effect, hence the 1.3 dpr on pngs. jpgs/webp are affected by it, so we can drop it right down for 2x

[sndrs]

so:

	q	dpr
JPG, @1.25x+	20	2
JPG, @1x+	55	1
PNG, @1.25x+	n/a	1.3
PNG, @1x+	n/a	1

[OliverJAsh]

Could we make it explicit that q is not needed for PNGs? Perhaps:

val qualityparam = if (!isPng) { if (hidpi) {"q=20"} else {"q=55"} } else { "" }

[sndrs]

apparently imgix are looking to add lossy compression for PNGs which we would automatically pick up if it's left on them. think will leave it, since there's no specific benefit to removing it

[sndrs]

also, chrome gets a webp even if you ask for a png, which can make use of q

[gtrufitt]

🎆 Awesome!

[sndrs]

What is the percentage size reduction ? 20% for png, 50% for JPEGs? How much bandwidth do you think we'll save ? What about 💰 ?

@dominickendrick based on that page, and those images, the %KB savings are:

format	@1.25x+	@1x
JPG	54%	60%
WEBP	23%	27%

dunno about 💸

[jamesgorrie]

dunno about 💸

Could we just get the average now and watch the $s after release?
Generally speculating on cash is dangerous.

[sndrs]

looks like fastly image bandwidth has dropped from 7gb/min to 6

.

some back of an envelope calculations by @gklopper estimate an industry-saving cost reduction of ~£2000/year :)

[kellysutton]

👍 This is awesome.

[mchv]

💎 excellent work!