A sprite is typically a single image file that contains more than one image, or fragments of a single image.
Historically, sprites were used in video games, and contained the graphics for objects that would be drawn into the game. Graphics processors were not powerful enough to continually draw full-frames, so a single frame would be drawn to screen and the artwork of a player's character, or moving scenery would be drawn separately from the main frame and this would be interpolated with the existing graphics. These graphics elements were floated above the main graphics buffer and due to their ethereal nature were christened sprites.
A CSS sprite consists of a single image file that contains multiple images within it, and this image is manipulated using CSS styles for display in a web page.
This website (SpriteThing.com), simplistic in design (to say the least) uses a CSS sprite file as a simple example of how a CSS sprite could be used. The sprite file consists of 37 images. Please bear in mind that with the advent of advanced styles in CSS2 and CSS3 it wouldn't necessarily be best practice to use some of the types of images as embedded in the sprite file for this website, it's chiefly for example purposes.
Some of the images embedded in the sprite file for this site are quite large, larger than the typical CSS sprite image. Indeed, it is not typical to embed the entire website imagebase within a sprite image. There are several reaons for this, here are a few:
On the topic of efficiency, it is necessary to trade off the overhead of blocking download threads in the browser (when acquiring multiple images) against the data transferred. It's true that, in both instances, once an image has been cached by a web browser, it will not be requested again while the cached file remains valid.
In the example of the images in the SpriteThing.com sprite file, not all of the 36 images are needed across the site, in fact, only three are used on every page. However, their inclusion within the sprite file incurs little detriment to the page load time. Once the image is loaded on the first page request, it will be cached and no further requests for the image shall be required. Furthermore, the combined file size of the sprite image and its associated CSS rules is 38.41 KB. The individual files total 50.8 KB, and yes, these were all optimised as much as they could be. The sprite files are 75% smaller than the individual images, and 40 KB isn't a large file as far as images are concerned. Across the entirety of a website, this should result in a reduction of data transfer based on a typical client.
As you can see, these requests have come from a local source, so won't be impacted upon by particularly by network latency. Also, in the sprite example you'll notice a blank transparent gif is loaded (t.gif), this is used so that img tags can be utilised to display images in their normal fashion, permitting, for example, the use of the alt tag for describing the image, if needed, although this is not strictly necessary. This is discussed further in How do I use Sprite Thing.
In this example, on average, the sprite-based solution loads in approximately 40ms, the individual image approach takes 122ms on average to the load event firing. Now, of course, this would be to load every image in this website, which may be a rather trite example, but, in this case, loading the individual images would take three times as long.
This boils down to keeping assets for a single graphics entity within one file for ease of management and touches on the same issue of maintenance. One CSS image may have four button state styles one for the normal state, one for the hover state, one for the active state and a fourth for the disabled state. This image would be accompanied by four or five CSS style rules for the inclusion of the image and the various offsets for the positions of the images within the sprite.
If the color of the buttons is altered, this is a simple change to the image file to update the graphics. If the button is to be shrunk in size, this will affect the offsets of the states and the CSS rules would need to be adjusted to match. Having just one file to alter makes management of this process simpler.
Of course, this style of button would be trivial to create in CSS, this is a very basic example.
It can be simpler to manage sprites of the same size within a single image file. Where the graphic assets in the image are the same size, the CSS rules can be calculated based on an offset along one axis - horizontally or vertically.
In addition to this, where an image may be repeated multiple times horizontally or vertically, for, say, styled horizontal rules, each of the graphics can be emebedded in a single CSS sprite and repeated using background-repeat: repeat-x;. This is only possible if the images are the same size (in one dimension) in the sprite file.
Here's a simple example of a sprite file containing three different line styles in a single image, and below it the same image file repeated along the horizontal axis in a bar which fills the page.
In order for these lines to be used in this manner, they must all occupy the entire width of the image and, consequently, it is logical to store them in a single file. In this example the image is 1px wide, it wouldn't necessarily need to be, but the element to be repeated would need to fill the entire width of the image to be used in this way. Similarly, were an image to be repeated vertically, it would need to occupy the whole height of the image - or be man.
Where a sprite file contains many graphics, maintaining these assets can become an arduous task.
Take the scenario that, prior to release of a new website, the development team decides, in order to improve the page load speed, to place all their most used small image assets into a sprite file. Six months later, as the development of the website continues, images are replaced or altered on the website, and the sprite file is not kept in sync with the rest of the site. Before launch of the latest version, the release team notice the increase in requested assets - it's time to update sprite image and CSS rules to deal with the changed images. Updating the sprite files is quite a time consuming venture and, consequently, adds additional cost to the delivery of the updated design. Graphics need to be updated, sprites copied in to the existing image. CSS rules need to be rewritten to cope with the change in coordinates. And one gets overlooked. Not a big issue, but it's another job to be done.
The beauty of Sprite Thing is that this maintenance is not an issue, old images can be removed, new images can be uploaded and the image file and CSS is automatically generated.