[thelist] Sprite images and performance

Will willthemoor at gmail.com
Sun Aug 3 18:57:51 CDT 2008


Woa, this is really cool.  I was recently wondering about doing the same. No
skills here to actually do it but... 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.

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

Will


On Sun, Aug 3, 2008 at 10:10 AM, Bill Moseley <moseley at hank.org> wrote:

> Sorry, this is a bit long.  It will only be interesting to those that
> are combining multiple background images into sprites to improve web
> site performance.  Hopefully, there's a few developers out there
> with experience in working with sprites.
>
>
> Under development we want the css to reference individual background
> images -- basically, we don't want the designers to have to worry
> about building sprite files.
>
> Instead, I have a production build script that parses the css,
> extracts out the background image links from "url()" settings, builds
> a sprite file from all the images and then rewrites the css with the
> new image location and a background-position css rule.
>
> I'm using ImageMagick to build the sprite images along with some
> additional minification/stripping tools.  (Yes, I'm aware of existing
> tools such as SmartSprites).
>
> Making the sprite generation automatic has a few challenges.
>
> Here's my concerns and questions:
>
> 1) I've seen a number or recommendations to arrange the icons in the
> sprite file horizontally[1], and indeed in my tests that does result
> in smaller files.  But, I think vertically aligned might be safer.
>
> My concern is that it will be more likely that adjacent images in the
> sprite will show up with horizontally aligned images than vertically
> aligned images because a block element with a background image could
> end up very wide in a fluid layout if a user has a very wide screen.
>
> For this reason I'm thinking vertical arrangement is better.  Any
> one have experience with this?
>
> 2) On the sprite page I'm adding 100px transparent space between each
> image (to avoid showing adjacent images).
>
> Does this seem like a reasonable amount of space?
>
>
> 2) Assume a sprite is arranged vertically -- images below the previous
> one. And assume they are small icons (say 16x16).
>
> If I also include a very wide (but small) image (say 1000x20) the
> resulting image size is much more than the size of the icons along
> plus the size of the bar alone (in one test the sum of the two was 50K
> but the resulting image was 90K).  I guess all that empty transparent
> space created by adding the wide image takes up more file space than I
> imagined.
>
> Is that extra 40K worth a separate HTTP request?  Perhaps.
>
> I guess my question is when automatically processing a long list of
> background images what can I use to determine when to exclude an image
> from the sprite?  (I'm currently using an exclude list in my
> configuration file and also by checking if the total "area" of an
> image exceeds some threshold.)
>
> Those are my main concerns.  Anyone have any experience working with
> sprites they can share?
>
> FWIW -- I'm using PerlMagick to generate the sprites.  I have not
> looked into optimizing with ImageMagick yet, but here's my simple
> approach so far:
>
>    my $im = Image::Magick->new;
>    $im->Read( @image_list );
>
>    my $montage = $im->Montage(
>        mode        => 'Concatenate',
>        tile        => '1x',
>        background  => 'none',
>        border      => 50,
>        bordercolor => 'none',
>    );
>
>    $montage->Write( $sprite_path );
>
>
>
>
> [1] See Optimizing CSS Sprites at:
> http://developer.yahoo.com/performance/rules.html
>
>
>
> --
> Bill Moseley
> moseley at hank.org
> Sent from my iMutt
>
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>



More information about the thelist mailing list