Good writeup as always!
I've always end up using pngyu for PNGs regardless of the save option.
Great article! I love using tools like tinypng.com to squeeze the last drop of value from every kb :)
Thanks! I wish our tools were close enough to the results from PNG optimisers, so it wasn’t needed.
This is a really cool article with a lot of research behind it! However, I think it'd be helpful to add a note regarding image compression as part of your deployment pipeline instead of worrying about how different people and teams are exporting assets.
I think that's tough because in a lot of cases, there is no silver bullet. I recommend TinyPNG (https://tinypng.com) to our clients because it's user-friendly and has great results. The problem is that gradients/shadows/photos can look a bit over compressed - so it's not a "be-all, end-all" solution.
That's true, occasionally you'll run into assets that don't compress well with a lossy compression library but the space saving tips primarily do stuff like remove colour profiles and the like which is entirely safe to automate unless you're using a non sRGB image.
You could for example have different compression settings for assets that are in different places or different filetypes (progressive jpegs for example). That way you'd be able to deploy almost any image knowing it'll be handled appropriately without you having to worry about it.
Yeah. It's one of those things that is def easier to "control" within a team.
Is your avatar the electric gym leader from pokemon red/blue?
Haha, yeah! Lt. Surge was sort of what I was going for when I made it, nice catch :-)
Did you see the results in comparison to ImageOptim? ImageOptim does a great job, and uses lots of well known open source PNG compression libraries (Zopfli, PNGOUT, OptiPNG, AdvPNG, PNGCrush).
I didn’t compare against lossy techniques, because I think those are typically unsuitable for iOS, Android and macOS projects, and it wasn’t the point of the article (it’s also an unfair comparison). Using lossy PNG compression can be a great idea for the web though. I’m all for it. I just like being in control of it, and carefully check assets when using lossy compression.
Discussion about deployment pipeline is interesting — for iOS, PNGs get recompressed using PNGCrush by Xcode, unless you disable it. That means any work you do to reduce your files will be undone. macOS development usually means images get repackaged as TIFFs, so any work you do to your PNGs is pointless, and if you use lossy compression you’ve just likely damaged your assets with no file size benefit.
I did see them, what I meant by my original comment was mainly that it'd be nice to have a sentence or two in the summary mention that compression often happens at build or that it can be added to the pipeline for web.
I also agree that lossy techniques should be completely avoided for UI assets and photos would probably work better as lossy progressive jpegs.
A lot of designers aren't in charge of the deployment pipelines of the projects they're working on, but if they're aware that compression of UI assets could be automated there I think they could pressure whoever is responsible to implement it.
I like to think that as designers we're responsible for the end result a user gets in their hands, that includes the poor impression caused by assets that load very slowly (thinking primarily web here).
Yep, all fair points. I definitely agree with the last bit.
What’s your preferred way to automate processing PNGs for web? Gulp? Grunt? Something else?
I work on a lot of React powered applications where we use Webpack to bundle and process assets. Webpack makes setting up so called "loaders" for different filetypes (even different filetypes in different locations) very easy.
Gulp and grunt work great for these things as well though so it really depends on the needs of the project.