Reduce size of project images

[rufuspollock]

project images for projects are often quite massive (somtimes >500K) and this is bad for page performance and b/w usage.

Especially a problem on project listing page (cf #46) as we load all project images

[loleg]

I've made the image loading dynamic, initiated via JavaScript, where we can fine tune it until we have a thumbnailing workflow.

[andylolz]

Whatever happens with the js, we’ll still need to resize these large image files.

Is 235px width ok? I can resize and store these in /img/projects

[loleg]

In the lightbox they are shown at double column, ie about 550px size.

[andylolz]

Ah ok, cool

[mchelen]

Optimizing images can also make a big difference in file size. For example, using https://kraken.io/ takes this image from 651.14 KB to 173.90 KB. The quality is maintained pretty well, but that might depend on the content in the image. Original: http://kartograph.org/showcase/eastcoast/eastcoast-90dpi_export.png Optimized: http://dl.kraken.io/69770496ea9dbba5155b39b886e3fa30/eastcoast-90dpi_export.png

[andylolz]

Yep exactly. But rather than crushing pngs, I was thinking I would resize and then jpegify with compression. Does that sound ok?

[rufuspollock]

@andylolz going ahead and doing this would be great. I propose we then put these images in:

/img/projects/{project-name}/screenshot.png

And if we have different sizes do the usual thing of adding e.g. -small to the filename.

@loleg @mchelen wdyt?

[loleg]

Sounds good.

[mchelen]

Sounds good to me, IDK what dimensions/size limits are best but probably anything under 100-200kb would be good. On Jan 13, 2014 4:03 AM, "Oleg Lavrovsky" notifications@github.com wrote:

Sounds good.

— Reply to this email directly or view it on GitHubhttps://github.com/okfn/okfn.github.com/issues/164#issuecomment-32153218 .

[rufuspollock]

@mchelen @loleg @andylolz is there work remaining here or can we close?

[mchelen]

I like the idea from https://github.com/okfn/okfn.github.com/issues/164#issuecomment-32152885 The approach I would usually take is save the full images there, and use a Grunt script with imagemin to create the final lower resolution / smaller file size production images.

[loleg]

I think the proposal of @mchelen is reasonable, but would also consider an approach like robwierzbowski/jekyll-picture-tag if that works with GitHub Pages.

[mchelen]

@loleg jekyll-picture-tag looks really cool. It's probably not supported by GH pages unless you build the site locally before pushing, but that would be worth testing. My question is whether it supports external image links, or if it would need a step to copy the images locally first.

[rufuspollock]

@mchelen @loleg what's the status of this issue? Is it WONTFIX or do we want to do more to close this out?

[loleg]

@rgrp I'm fine with pulling in the patch from @mchelen - as long as we raise a separate issue to simplify the build steps, e.g. revisit the idea of using jekyll-picture-tag in the future.

[rufuspollock]

@loleg my thing is i'd a bit concerned about having to run a build to do a deploy (will the patch require that going forward)?

[mchelen]

@rgrp Build is only required when you want to optimize the images. So for example when adding a new project with an external image URL, it will initially use the external URL. Then once someone runs build, it will fetch the image, optimize it, and use this new local & optimized version instead of the external URL. I can't think of any simpler way to optimize images when they are external URLs.

@loleg jekyll-picture-tag is great but it will still need a prior step to fetch external images. Maybe the best way to handle that in the future is to require contributors to add the image directly to the repo, instead of using external URLs in the first place.

[rufuspollock]

@mchelen @loleg. Awesome let's get this in :-)