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

Improve homepage promo image workflow #1231

Open
alextea opened this issue May 16, 2017 · 5 comments
Open

Improve homepage promo image workflow #1231

alextea opened this issue May 16, 2017 · 5 comments

Comments

@alextea
Copy link
Contributor

alextea commented May 16, 2017

Often when homepage promo images are added or changed they are bigger than necessary and this causes performance to suffer.

We should improve the workflow to ensure that developers updating the images are aware of the constraints and images are appropriately resized and compressed.

Some ideas on how to achieve this:

  • a script to automatically compress and resize images
  • a unit test to warn if images are too big
  • guidance on how to resize and compress images

Some things to consider:

  • lossy compression can lead to artefacting, so the images will need to be previewed to ensure there's no visual defects
  • images with flat colours are better as pngs than jpgs, so the scripts will need to be able to consider this
  • we might get better file size and a clearer image if we use a larger image that uses higher than usual compression
  • we should strip out embedded colour profiles and convert to sRGB
  • we should strip out image metadata
  • jpgs should be progressive to speed up the time they take to display
@mcgoooo
Copy link
Contributor

mcgoooo commented May 16, 2017

@edwardhorsford
Copy link

Would love to see improvements in this area. I feel like automated tests might be a good start - enough to prod someone to check the image and spend a bit of time optimising them.

  • For even smaller images, we could consider using a slimmed down colour profile such as Facebook's C2. Converting to C2 profile rather than sRGB would save 3-4kb per image. C2 simulates sRGB but in a much smaller size.

@mcgoooo
Copy link
Contributor

mcgoooo commented May 16, 2017

the link above makes it part of the asset pipeline, and bar it doing the wrong thing, it's configure and forget

@alextea
Copy link
Contributor Author

alextea commented May 16, 2017

A couple of issues I can see with using the asset_pipeline is that it will be recompressing images, and if it's using lossy compression this could be bad. If the images aren't the right size or are too large it might not be as efficient.

@mcgoooo
Copy link
Contributor

mcgoooo commented May 16, 2017

it would be relatively simple to hook into it only when needed i reckon as well, using the base ruby library if we wished more fine grained control.

https://github.com/toy/image_optim

the one linked above is just the fire and forget option, i have used it with good success on previous projects.

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

No branches or pull requests

4 participants