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

Reduce image weight, welcome hidpi screens #12079

Merged
merged 6 commits into from Feb 25, 2016
Merged

Reduce image weight, welcome hidpi screens #12079

merged 6 commits into from Feb 25, 2016

Conversation

@sndrs
Copy link
Member

@sndrs sndrs commented Feb 24, 2016

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

screen shot 2016-02-24 at 15 05 02

screen shot 2016-02-24 at 15 06 23

### after

screen shot 2016-02-24 at 15 04 54

screen shot 2016-02-24 at 15 06 52

## Request for comment

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

@dominickendrick
Copy link
Contributor

@dominickendrick dominickendrick commented Feb 24, 2016

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

@dominickendrick
Copy link
Contributor

@dominickendrick dominickendrick commented Feb 24, 2016

This is awesome btw!

@paperboyo
Copy link
Contributor

@paperboyo paperboyo commented Feb 24, 2016

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
Copy link
Member Author

@sndrs sndrs commented Feb 24, 2016

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

@paperboyo paperboyo commented Feb 24, 2016

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

@paperboyo paperboyo commented Feb 24, 2016

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

@OliverJAsh OliverJAsh commented Feb 24, 2016

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
Copy link
Member Author

@sndrs sndrs commented Feb 24, 2016

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
Copy link
Member Author

@sndrs sndrs commented Feb 24, 2016

so:

q dpr
JPG, @1.25x+ 20 2
JPG, @1x+ 55 1
PNG, @1.25x+ n/a 1.3
PNG, @1x+ n/a 1
@@ -36,13 +38,21 @@ sealed trait ElementProfile {

// NOTE - if you modify this in any way there is a decent chance that you decache all our images :(
lazy val resizeString = {
val qualityparam = "q=85"
val qualityparam = if (hidpi) {"q=20"} else {"q=55"}

This comment has been minimized.

@OliverJAsh

OliverJAsh Feb 24, 2016
Contributor

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 { "" }

This comment has been minimized.

@sndrs

sndrs Feb 24, 2016
Author Member

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

This comment has been minimized.

@sndrs

sndrs Feb 24, 2016
Author Member

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

@gtrufitt
Copy link
Member

@gtrufitt gtrufitt commented Feb 24, 2016

🎆 Awesome!

@sndrs
Copy link
Member Author

@sndrs sndrs commented Feb 24, 2016

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

@jamesgorrie jamesgorrie commented Feb 25, 2016

dunno about 💸

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

sndrs added a commit that referenced this pull request Feb 25, 2016
Reduce image weight, welcome hidpi screens
@sndrs sndrs merged commit 7151c3b into master Feb 25, 2016
1 check passed
1 check passed
continuous-integration/teamcity Finished TeamCity Build dotcom :: pull requests : Running
Details
@sndrs sndrs deleted the imgix-optimasation branch Feb 25, 2016
@sndrs
Copy link
Member Author

@sndrs sndrs commented Feb 25, 2016

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

screen shot 2016-02-25 at 11 59 49.

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

@kellysutton
Copy link

@kellysutton kellysutton commented Mar 4, 2016

👍 This is awesome.

@mchv
Copy link
Member

@mchv mchv commented Apr 3, 2016

💎 excellent work!

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

Successfully merging this pull request may close these issues.

None yet

8 participants
You can’t perform that action at this time.