It’s reasonably well known that Fireworks can create alpha-transparent 8-bit png files (so can various other widgets but curiously, still not Firework’s celebrity sibling, Photoshop).

That’s an awesome trick, because they’re generally about a third of the size of 32-bit – however they are limited to 256 colours, which won’t work for CSS-spriting most designs.

Which leads me to a technique I’ve been trying recently: When you have a design with several clearly identifiable colour groups, make separate sprites for each colour – blue, red, purple, whatever – then export them as 8-bit.

Examples:

A recent Facebook game had a character sprite sheet that was a meg. I split out the character faces, that had lots of gradients and mixed colours into a 32-bit sprite (~200k) and 8-bit exported the mostly flat-fill, similar-coloured bodies (~200k), resulting in a hefty saving (~600k / 60%). (Note the heads and bodies were already separate as they were swoppable, so the split wasn’t a big deal.)

Another recent app had a design with several bold primary colours used for different icon and button sets. I went to town with this technique, making 4 colour-specific 8-bit sprites and a single 32-bit catch all sprite for the other colours and things that didn’t work at 8-bit:

Each sprite was at least 20k smaller than its 32-bit equivalent, which easily justifies the ‘weight’ of each extra file request (calculated by one BBC dev many years back as very roughly equivalent to ~2.5k on a default Apache install).

Corollaries:

This may not be a suitable technique for elements where there are

  • subtle or extensive gradients
  • a mix of of colours or
  • only a few items of that colour – where the saving won’t offset the downloading of an extra file