[thelist] Sprite images and performance

Bill Moseley moseley at hank.org
Sun Aug 3 20:12:40 CDT 2008

On Sun, Aug 03, 2008 at 04:57:51PM -0700, Will wrote:
> One question I have is do you have a
> way for your css developers to exclude a certain image from the sprite?  I'm
> thining somewhat of the scenario you described - small bg image on a
> wide/tall container.

The goal was to allow the designers to just use images directly, and
leave the optimization details to the build script.  The build script
is suppose to figure out how best to setup the sprites.

We use a build profile (text file) that places dependent css and js
files into groups, and then those groups into sets where each set ends
up being a link to a single js or css file, minified (and gzipped for
clients that can accept gzipped content).

In that profile there can be a list of regular expressions to exclude.
So, yes, the designer could use a specific directory or filename
scheme to exclude images.

Again, my initial goal was to not have the designer or developer (that
writes the css) worry about the performance tuning issues and try and
infer from parsing the CSS (and looking at image size, color depth, etc.)

(SmartSprites, on the other hand, uses comments in the css to say what
css should have sprites and which sprite file to set, which I'm not so
fond of).

As it turns out, I'm using Perl and the two CSS parsers I've tried
from CPAN get confused when trying to parse our valid real-world css.
So, I'm now parsing line-by-line, so designers could add a comment to
the css to say to exclude a given background image from the sprites.

That's the long answer.

> On the extra 40k issue, are you mashing up gifs and jpegs?  That'd add up
> quick.

No, all .gif.  I create a sprite file called icons.png (png8)
that is not very wide (16 px icons) but very tall (long):

$ file icons.png 
icons.png: PNG image data, 116 x 8468, 8-bit colormap, non-interlaced

(the extra 100px is padding around the icons)

$ ls -l icons.png
-rw-r--r-- 1 moseley moseley 14628 2008-08-03 17:37 icons.png

Now I have another .gif that is more wide than tall:

$ file big.gif
big.gif: GIF image data, version 89a, 1119 x 504

$ ls -l big.gif
-rw------- 1 moseley moseley 40541 2008-08-03 17:38 big.gif

Together the files add up to 55,169 bytes.

Now, if I rebuild icons.png but include the "big.gif" I get:

$ file icons_and_big.png 
icons_and_big.png: PNG image data, 1219 x 9072, 8-bit colormap, non-interlaced

$ ls -l icons_and_big.png 
-rw-r--r-- 1 moseley moseley 92438 2008-08-03 17:46 icons_and_big.png

So, 37269 bytes bigger than the sum of the two images.  So, seems like
all that transparent space takes up a bit of room.

There are tools for shrinking it more.  For example:

$ ./pngout/pngout-linux-i686-static icons_and_big.png 
 In:   92438 bytes               icons_and_big.png /c3 /f0 /d8
Out:   63847 bytes               icons_and_big.png /c3 /f0 /d8, 255 colors
Chg:  -28591 bytes ( 69% of original)

Which is pretty impressive, but took about 5 minutes to run on a 2Ghz
Core2 Duo.

Bill Moseley
moseley at hank.org
Sent from my iMutt

More information about the thelist mailing list