Make images smaller - Githubissues

commuterjoy commented 11 years ago

I want someone else to pick up the image resizing work so that a few people understand it.

Here's a few things to do,

Write some new image profiles that correspond to our grid, Eg. 320x192 @ 70% compression.
Remove all (or most) images from the DOM on page load.
Update the image upgrade module to map the device's window.innerWidth to your new image profiles.

Anyone want to volunteer?

stephanfowler commented 11 years ago

I'm happy to pick this up. It'd maybe be worth waiting for design/grid stuff to deploy first though - because that'll dictate the imagewidth increments that we'll need - rather than basing it on assumptions about devices?

commuterjoy commented 11 years ago

@stephanfowler excellent, thanks. I suspect we can do the work soon then massage the profile widths/heights over the coming weeks. But speak to Alex next week?

phamann commented 11 years ago

You forgot to mention: WebP

commuterjoy commented 11 years ago

Ah, yes.

https://groups.google.com/a/webmproject.org/forum/m/?fromgroups#!topic/webp-discuss/13w2gFmR3eU

commuterjoy commented 11 years ago

from @phamann

Also, our CDN doesn't seem to support vary headers on Accept, so it might be worth waiting until we switch to Varnish for this to be simple.

stephanfowler commented 11 years ago

Looks promising. Though even with CDN support for Vary:Accept, only Opera would currently benefit. Once Chrome sets its default Accept header to state WebP support, it seems to make some sense. Unclear if/when that change goes into production: https://code.google.com/p/chromium/issues/detail?id=169182

Where would the encoding into WebP happen - in the image resizer?

On 20 April 2013 18:36, Matt Chadburn notifications@github.com wrote:

from @phamann https://github.com/phamann

- http://blog.netdna.com/developer/how-to-reduce-image-size-with-webp-automagically/

http://www.igvita.com/2012/12/18/deploying-new-image-formats-on-the-web/

Also, our CDN doesn't seem to support vary headers on Accept, so it might be worth waiting until we switch to Varnish for this to be simple.

— Reply to this email directly or view it on GitHubhttps://github.com/guardian/frontend/issues/719#issuecomment-16707977 .

Please consider the environment before printing this email.

Visit guardian.co.uk - website of the year

www.guardian.co.uk www.observer.co.uk www.guardiannews.com

On your mobile, visit m.guardian.co.uk or download the Guardian iPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad

Save up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit guardian.co.uk/subscribe

This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.

Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited

A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP

Registered in England Number 908396

phamann commented 11 years ago

Ensure all JPEG's are progressive.

This creates a much faster perceived experience for the user. Great article here: http://calendar.perfplanet.com/2012/progressive-jpegs-a-new-best-practice/

commuterjoy commented 11 years ago

Also worth running an A/B test to see if images have any impact on usage.

commuterjoy commented 11 years ago

@kaelig is doing this at the moment. We should test out adding interlace() to all the images.

phamann commented 11 years ago

@commuterjoy if @kaelig is assigned to issue and currently doing, why have you closed? Surely he should just close with pull request.

kaelig commented 11 years ago

We tried to improve things but here is what blocked us:

thumbnail images served by the api are too small
therefore we are fetching the main image of the story when there is one
unfortunately the main image does not have all the crops in all cases

So we are waiting for the images to be properly served in the first place instead of adding complexity to the application.

rich-nguyen commented 11 years ago

I'll take a look at how we can serve these images, and if webp is possible with varnish (the vary:accept). It looks like chrome does state an Accept preference for webp during image requests now.

@kaelig can you remember the problem you mentioned concerning main images that "do not have all the crops in all cases"? That seems like it could just be solved with more image server profiles (as @commuterjoy first mentioned).

Regarding progressive jpegs, I would like to see more evidence of browser compatibility. I can't find an accept media-type that allows us to distinguish if a browser can handle progressive jpeg in a non-baseline manner. Could be concerns over cpu too. But I like them, progressive jpeg scans could look like mip-map blending (in the future).

kaelig commented 11 years ago

PJPEG is supported in browser vendors since I have been making websites. And I was using IE3.0 or 4.0 as well as Netscape (can't remember the version). So I would not worry about browser support too much.

commuterjoy commented 11 years ago

lets close this & reopen specific tasks.

guardian / frontend

Make images smaller #719

- http://blog.netdna.com/developer/how-to-reduce-image-size-with-webp-automagically/

Please consider the environment before printing this email.