|CSS Sprites opposed to slicing an image...
||[14th, May, 2009 6:18 pm]
So I was reading a tutorial on CSS Sprites. That is, one big image with all/most the sites graphics contained on there. The purpose is to load said image and control what shows with background positioning. At first I was all gun ho and ready to jump aboard. Sounds neat! Hey, I like trying the next new thing out and seeing if it really lives up to the hype...
Well, so I go through the tutorial and start reading the comments. Apparently whats happening is the file size (total) is smaller, the http requests are fewer but the image is WAAAAAY bigger... 1000x2000, I think is the example given. So apparently, that makes the memory usage up around 7.6MB. hmmmmm. So now, is the perceived notion that the website is moving quicker worth the added taxation on system resources?
I, personally have not yet tried this technique and can see both sides of the argument from where I sit. I can see it being handy in simpler sites. Static pages, mostly. I don't think I'd want to pair this with flex, flash or other high memory sucking tasks as that.
But really. Out of 4GB of memory, what is 6MB? Wouldn't that memory free up again once you left the page!? Maybe I'm not seeing it from the right view, but I'd venture to guess you could save fractions of seconds by the use of the larger sprite images over the sliced background of yesteryear...
for smaller images, rollovers and the like, its already widely used. However, I don't know if that would technically be a sprite as it would only have two images one right on top the other. I think it might be handy if your able to pack the sprites in tighter. This, obviously, would decrease the files size even more, albeit minimally... Perhaps there's still a fine line between the slicing of an image and making a sprite of a bunch... Stay tuned!