The problem sprites solved

About a decade ago, every image request on the web had a noticeable cost: under the HTTP/1.1 of the time, a browser could only load a few files at once, and each one added delay. A page with 30 small icons meant 30 requests — and thus a slow page. The solution was the CSS sprite: pack all icons into one large image and show only the relevant slice via CSS.

How it worked

A sprite image is a grid of many small graphics. In CSS you give the element this image as a background and shift the visible slice to the desired icon with background-position:

.icon {
  background-image: url("/sprite.png");
  width: 24px;
  height: 24px;
}
.icon-home   { background-position:   0 0; }
.icon-search { background-position: -24px 0; }
.icon-menu   { background-position: -48px 0; }

One image, many icons, a single request. For the technology of the time, a real performance win.

Why the problem disappeared

With HTTP/2 (and today HTTP/3) the basis changed: modern connections load many files in parallel and efficiently over a single connection — the cost per request has dropped drastically. So the sprite's main advantage — saving requests — has largely vanished. At the same time, sprites showed their downsides ever more clearly:

  • Pixel-based: sprites (usually PNG) don't scale sharply on retina displays.
  • Awkward maintenance: a new icon means rebuilding the sprite image and the position values.
  • No easy recoloring: color and dark-mode adaptation are tedious.

What takes their place today

  • Inline SVG or SVG via img: scales sharply, recolorable via CSS. The routes are covered in Embedding SVG.
  • SVG sprite: the modern evolution of the sprite idea — one SVG file with several symbol definitions, referenced via use. You keep the bundled file but gain scalability and styling.
  • Individual cached SVG icons: no longer a problem thanks to HTTP/2, and maximally flexible.

When sprites still show up

Sprites aren't entirely dead: in legacy projects, with very many tiny raster graphics (game assets, say), or where a single image is wanted for other reasons, they still have their place. For a new website with icon needs, though, the sprite approach is rarely the first choice — SVG solves the same thing more elegantly. The honest summary: knowing them doesn't hurt, needing them will be rare.

In short

  • Sprites bundled icons to save HTTP/1.1 requests.
  • HTTP/2 made that saving mostly irrelevant.
  • SVG (inline, sprite, or cached files) is the modern answer.
  • Legacy/game assets aside, you rarely need sprites now.