Reduce image weight, welcome hidpi screens #12079
Conversation
What is the percentage size reduction ? 20% for png, 50% for JPEGs? How much bandwidth do you think we'll save ? What about |
This is awesome btw! |
Enormous thanks goes to @sndrs who did all the work! And had to put up with me.
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 I offer How can we measure average daily bandwidth savings, d'you think? Or whatever would be the nicest-looking stat? :) (EDIT: issue opened: #12215) |
shouldn't |
There is this question of de-caching... By "foreseeable" I've meant whenever. Just not "never" |
In the best tradition of my not-PR-related comments, there is much more optimisation we might want to do to Lightbox, e.g.: weights 3,7MB and measures 2872px vertically on my 2560x1600 monitor ([EDIT somehow Lightbox is (EDIT 2: here is @rich-nguyen’s great explanation of how this should be handled: #12216 (comment)) |
Awesome! Good description of the change :-) I made a table to help me understand how and when we vary
Scala looks mighty fine to me |
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 |
so:
|
@@ -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"} |
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 { "" }
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
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
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
Feb 24, 2016
Author
Member
also, chrome gets a webp even if you ask for a png, which can make use of q
also, chrome gets a webp even if you ask for a png, which can make use of q
|
@dominickendrick based on that page, and those images, the %KB savings are:
dunno about |
Could we just get the average now and watch the $s after release? |
Reduce image weight, welcome hidpi screens
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 :) |
|
|
What does this change?
Updates imgix settings, based on @paperboyo's reseach:
q=85
toq=55
fit=max
to prevent upsizing images beyond the originalusm=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:q=85
toq=20
for JPGs on@1.25x
+ screensdpr=2
non-PNGs to@1.25x
+ screensdpr=1.3
PNGs to@1.25x
+ screens (PNGs aren't affected byq
)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:
@1.25x
+@1x
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 ;)