Detailed explanation
CSS sprites are a technique for combining several small images, such as navigation icons or button states, into one larger image called a sprite sheet. Each element uses that sheet as its background, but its dimensions reveal only the required region. The images are not separate files at runtime: CSS selects which part of the shared image appears. This technique is especially associated with older websites that used many small raster graphics.
For example, a sheet might contain a 32×32 home icon at the top-left corner and a 32×32 search icon immediately to its right. A shared .icon rule sets background-image: url('sprite.png'), width: 32px, height: 32px, and background-repeat: no-repeat. The home class uses background-position: 0 0, while the search class uses background-position: -32px 0. The negative horizontal offset moves the sheet left, bringing the search region into the element's background painting area. If the element is an ordinary inline span, display: inline-block is also needed for its width and height to apply as intended.
Sprites became popular because fetching many individual images created substantial overhead, particularly with HTTP/1.1 connection limits and request scheduling. One sprite sheet replaces those separate image requests with a shared resource that the browser can cache. Keeping normal and hover graphics in the same loaded sheet can also avoid waiting for another image when the user interacts. However, downloading a large sheet for just one icon wastes bytes, and changing one graphic changes the shared asset, potentially invalidating its cached version.
Today, HTTP/2 and HTTP/3 multiplexing reduce the request-count advantage, so sprites are an option rather than an automatic performance improvement. They can still suit fixed icon collections or existing raster-heavy interfaces, but SVG symbols or individual SVG files are often easier to scale and maintain. High-density raster sprites require appropriately scaled assets, background-size, and matching offsets. Interviewers generally look for the positioning mechanism, the historical network benefit, and a balanced explanation of modern trade-offs rather than a claim that sprites are always faster.
Key points to remember
- A sprite sheet combines multiple graphics into one image resource.
- Element dimensions and background-position expose the desired region; negative offsets shift the sheet left or up.
- Sprites historically reduced HTTP request overhead, especially under HTTP/1.1.
- Shared caching helps reuse, but unused graphics and whole-sheet cache invalidation can offset the benefit.
- HTTP/2 and HTTP/3 reduce the advantage; choose sprites based on actual usage, maintenance, and measured performance.
Common mistakes candidates make
- Claiming that sprites always improve performance or always reduce total image bytes.
- Using incorrect offset signs or forgetting explicit dimensions and inline-block for inline elements.
- Using a CSS background as the only way to communicate an icon's meaning, without accessible text or an accessible name.
Likely follow-up questions
How do you make a raster sprite sharp on high-density screens?
Use a higher-resolution sheet and set background-size to its intended CSS dimensions. For a 2× asset, halve the sheet dimensions and pixel coordinates when expressing sizes and offsets in CSS.
Are CSS sprites obsolete with HTTP/2?
No, but multiplexing makes reducing request count less valuable than it was under HTTP/1.1. Compare transferred bytes, caching behaviour, and loading time rather than assuming a combined sheet is faster.
How should sprite icons be made accessible?
CSS background images do not provide alternative text. Give an icon-only button an accessible name, such as aria-label="Search", or include visible text; purely decorative icons need no separate description.
Interview tip: Explain the two-icon positioning example first, then connect the historical request savings to today's performance and maintenance trade-offs.