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

Conversation

Projects
None yet
8 participants
@sndrs
Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

dominickendrick commented Feb 24, 2016

This is awesome btw!

@paperboyo

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Member

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

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

Member

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

@gtrufitt

This comment has been minimized.

Member

gtrufitt commented Feb 24, 2016

🎆 Awesome!

@sndrs

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

Merge pull request #12079 from guardian/imgix-optimasation
Reduce image weight, welcome hidpi screens

@sndrs sndrs merged commit 7151c3b into master Feb 25, 2016

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

This comment has been minimized.

Member

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

This comment has been minimized.

kellysutton commented Mar 4, 2016

👍 This is awesome.

@mchv

This comment has been minimized.

Member

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