SpriteMe (part 3)

September 21, 2009 11:59 pm | 3 Comments

This is the third of three blog posts about SpriteMe. The first post, SpriteMe makes spriting easy, reviews SpriteMe’s features with a summary of the performance savings across the Alexa U.S. top 100 web sites. The second post, SpriteMe (part 2), talks about my experience at WordCamp that motivated SpriteMe and the logic behind how SpriteMe makes its recommendations for creating sprites. This post discusses issues around sprite file size (and memory size) and wraps up with thoughts on major next steps.

File (and Memory) Size

In SpriteMe makes spriting easy, I showed how running SpriteMe on the Alexa U.S. Top 100 eliminated eight HTTP requests on average, but resulted in a 6K increase in total size of background images. Although this is a beneficial tradeoff (8 fewer requests in exchange for 6K more data), I’d prefer to see a reduction in overall size. After all, combining images into a single sprite reduces the amount of image formatting information, and frequently produces a savings.

The primary reason that SpriteMe produces an overall size increase is because of colors. Images that use 255 colors or less use a smaller color palette and have a smaller file size. Currently, SpriteMe has no knowledge of the number of colors, and which colors, an image uses. It’s possible for SpriteMe to combine two images, each of which is 255 colors or less, into a sprite that exceeds 255 colors, resulting in an overall increase in size. In the future, I plan on having SpriteMe use a web service to provide color palette information (issue #17). Until then, if SpriteMe produces a significant size increase, you can manually rearrange the images to stay within the 255 color threshold. Try grouping similarly colored images together. Fortunately, SpriteMe makes it easy to try different combinations and immediately see the size of the resulting sprite.

Another size concern has to do with memory size. As pointed out by Vladimir Vukićević in his post To Sprite Or Not To Sprite, although an image file can have a high degree of compression, most browsers render an image based on dimensions, allocating the same amount of memory for each pixel. The image he cites as an example is a 1299×15000 png. The download size is only 26K, but because of the huge dimensions the image consumes 75M when loaded in Internet Explorer, Firefox, Safari, and Chrome. (Not Opera, however – hmmmm.) Luckily, I’ve never seen SpriteMe recommend a sprite even close to this size. Even so, SpriteMe currently doesn’t “pack” images when it lays them out in the sprite, but that is on SpriteMe’s future feature list (issue #53). If SpriteMe generates a sprite with extremely large dimensions, try grouping narrow images in one sprite, and wide images in a different sprite.

Big Ticket Items

SpriteMe has about 50 open issues currently, but these are the major features I look forward to seeing added to SpriteMe:

export modified CSS
The #1 requested feature is an easier way to export the CSS changes (background-image and background-position). Ideally, SpriteMe would display the exact rule with the appropriate modifications. But, as with many things, the devil is in the details. The CSS changes might occur across multiple rules. Tracking down the exact rules is challenging, given how styles cascade. Finally, the rule’s cssText available through the DOM is unlikely to match the original CSS, and yet developers want something as close to their original code as possible, to make it easier to diff. And, of course, the way to do this differs across browsers. This isn’t impossible, but it’s going to be very hard.
create foreground IMG sprites
SpriteMe eliminates eight HTTP requests on average across the Alexa U.S. top 100 web sites. For some sites, over thirty requests are eliminated. But an even greater potential for savings can be had by spriting normal “content images”. These are the images embedded in the page using the IMG tag. This is possible, and I’ve seen web sites that do it, but it adds a fair amount of extra complexity. The IMG tag must be wrapped by a DIV with style “position: relative; display: inline-block; overflow: hidden; width: <img-width>; height: <img-height>;”. Then the IMG’s style is set to “position: absolute; left: <sprite-offset-x>; top: <sprite-offset-y>;”. I need to test this more, gauge the potential benefits are, and see if it can be done in an intuitive way.
sprite image editor
Creating and testing sprites is a challenge, but maintaining sprites is also difficult. One idea is to retain a memory of the images that were combined into the sprite for more intelligent editing later on. For example, for each background image added to a sprite, it’s original URL and coordinates (upper-left and lower-right) can be recorded. This information would be saved in a separate manifest file or added to the sprite itself as comments. Later, a special sprite image editor could make it easy to refresh or replace one of the background images, without affecting any of the other images in the sprite.

SpriteMe’s ability to modify the live page is a powerful feature. This speeds up the development process by promoting faster iterations. I’d like to find more opportunities for this style of development. One example, somewhat related, could be with image optimization. Page Speed compresses the page’s images on-the-fly using lossless techniques. A button that swapped out the bloated images for the optimized images would allow developers to verify the quality of the images before updating their files.

Spriting is a difficult task. SpriteMe makes the job easier. We’re seeing more and more tools that help developers build high performance web sites. Add SpriteMe to your developer toolkit, and stay tuned for a rash of posts about other performance tools that have recently entered the scene.

3 Responses to SpriteMe (part 3)

  1. You can also use the css “clip” attribute for foreground images.

    Eg:

    #selector {
    position: absolute; top: 0; left: 0;
    clip:rect(0 16px 16px 0);
    }

    This elminates the extra div overflow hidden ..

  2. * Correction you would still need to wrap it in a div with position:relative

  3. Spriting foreground images goes against the point. Everytime you add a new one you’ll have to redownload all the others that would be already cached otherwise. And you’ll hurt SEO, afaik filenames matter and repetition won’t do good.