CSS-Sprites: Wann sie noch helfen und wie du eines erstellst

Was ein CSS-Sprite tatsächlich ist

Ein CSS-Sprite besteht aus einer Bilddatei mit vielen separaten Grafiken und CSS, das jeweils nur eine davon anzeigt. Dabei wird weder zugeschnitten noch JavaScript verwendet. Das Element erhält eine feste width und height, wird das gesamte Sprite-Sheet als sein background-image, und background-position verschiebt das Sheet hinter dem Element, bis das gewünschte Symbol im sichtbaren Rahmen liegt. Der Rahmen ist ein Fenster; das Sprite-Sheet ist ein großes Blatt Papier, das dahinter verschoben wird.

Das Detail, das beim ersten Kontakt häufig verwirrt, ist, dass die Versätze negativ. Du bewegst nicht das Fenster zum Symbol, sondern das Sprite-Sheet so, dass das Symbol im Fenster erscheint. Um ein Symbol anzuzeigen, dessen linke obere Ecke 96 Pixel vom linken Rand des Sprite-Sheets entfernt liegt, verschiebst du das Sprite-Sheet um 96 Pixel nach links. Das entspricht background-position: -96px 0.

Ein konkretes Beispiel: Du ordnest fünf Symbole mit 24×24 Pixeln in einer Reihe an, mit 8 Pixeln Abstand dazwischen. Die Reihe beginnt 8 Pixel vom linken und 8 Pixel vom oberen Rand entfernt. Das Sprite-Sheet ist damit 160×32 Pixel groß. Der linke Rand des dritten Symbols liegt bei 8 + 24 + 8 + 24 + 8 = 72 Pixeln, sein oberer Rand bei 8 Pixeln. Die Regel lautet:

Ändere nur die beiden Zahlen in background-position und du erhältst aus derselben Datei ein anderes Symbol. Das ist der gesamte Mechanismus.

Der ehrliche Teil: HTTP/2 hat die Rechnung verändert

CSS-Sprites wurden erfunden, um eine konkrete Einschränkung zu umgehen. Unter HTTP/1.1 öffnete ein Browser pro Herkunft nur wenige TCP-Verbindungen, üblicherweise sechs. Jede Verbindung konnte jeweils nur eine Anfrage übertragen. Vierzig Symboldateien bedeuteten vierzig Anfragen in einer Warteschlange durch sechs Verbindungen, jeweils mit Verbindungsaufbau und Hin-und-zurück-Latenz. Durch das Zusammenführen in eine Datei wurden vierzig nacheinander abgearbeitete Anfragen zu einer. Bei hoher Latenz war das keine Mikrooptimierung, sondern häufig die größte mögliche Verbesserung einer Seite.

HTTP/2 verwendet Multiplexing. Viele Anfragen teilen gleichzeitig eine Verbindung, ohne Head-of-Line-Blocking auf HTTP-Ebene, und Header werden anfrageübergreifend komprimiert. Das konkrete Problem, für das Sprites erfunden wurden, ist weitgehend verschwunden. Wenn eine Anleitung 2026 behauptet, Sprites seien schneller, weil sie die Anfragezahl reduzieren, und es dabei belässt, beschreibt sie ein Web, das nicht mehr existiert.

Warum gibt es diesen Artikel also? Weil „der ursprüngliche Grund ist weggefallen“ nicht dasselbe bedeutet wie „es gibt keinen Grund“. Mehrere echte Vorteile bleiben trotz Multiplexing bestehen. Auf ihnen sollte die Entscheidung beruhen:

• Der Zusatzaufwand pro Anfrage sinkt nicht auf null. Multiplex-Anfragen sind günstig, nicht kostenlos. Jede enthält weiterhin Header, eine Cache-Abfrage und einen Platz in der Ressourcenplanung des Browsers. Bei fünf Symbolen fällt das nicht ins Gewicht. Bei zweihundert kleinen Symbolen ist es messbar, und das Sprite reduziert es auf einen Eintrag.
• Die Cache-Verwaltung wird einfacher. Eine Datei bedeutet einen Cache-Eintrag, einen Cache-Control Richtlinie und einen Dateinamen mit Hash zum Ungültigmachen. Zweihundert separat versionierte Symboldateien schaffen zusätzlichen Build- und Bereitstellungsaufwand, der verwaltet werden muss und meistens nicht verwaltet wird.
• Gemeinsame Versionierung. Alle Symbole werden gemeinsam ausgeliefert. So kann kein halb aktualisierter Symbolsatz entstehen, bei dem drei Symbole im alten Stil aus dem Cache kommen und die übrigen neu sind. Bei der Einführung eines Designsystems ist das eine echte Konsistenzgarantie, nicht bloß eine Frage der Ordnung.
• Kein Flackern durch ein fehlendes Symbol. Sobald das Sheet geladen ist, steht jedes darin enthaltene Symbol sofort zur Verfügung. Einzeln geladene Symbole erscheinen dagegen nacheinander, sobald ihre jeweiligen Anfragen abgeschlossen sind. Am deutlichsten fällt das genau dort auf, wo es am meisten stört: in einer Werkzeugleiste oder einem Symbolraster im sofort sichtbaren Seitenbereich.
• Zustandswechsel ohne Verzögerung. Ein Hover- oder Aktivzustand an anderer Stelle desselben Sprite-Sheets ist bereits heruntergeladen. Bei separaten Dateien wird das Hover-Bild oft erst beim ersten Darüberfahren angefordert. Dadurch entsteht ein kurzes leeres Flackern, wenn ein Nutzer die Schaltfläche zum ersten Mal berührt. Das war schon immer eines der stärksten Argumente für Sprites, und HTTP/2 hat daran nichts geändert.

Wann du kein CSS-Sprite verwenden solltest

Eine glaubwürdige Empfehlung muss auch die Fälle nennen, in denen die Antwort Nein lautet. Bei CSS-Sprites gibt es davon mehrere.

• Einfarbige, skalierbare Symbole gehören in SVG. Ein eingebettetes <svg> oder ein SVG-Sprite aus <symbol> und <use> skaliert ohne Retina-Berechnungen auf jede Größe und übernimmt die Farbe über currentColor. Für einen typischen Satz von UI-Symbolen ist das schlicht das bessere Werkzeug. Deshalb haben Sprite-Sheets bei Symbolsystemen still und leise den größten Teil ihres Marktanteils verloren.
• Für ein einziges Symbol lohnt sich ein Sprite-Sheet nie. Wenn du ein einzelnes Bild hast, verwende ein einzelnes Bild. Das Sprite bringt nur Koordinatenverwaltung und einen Build-Schritt, ohne jeden Vorteil.
• Unabhängig voneinander veränderte Symbole. Eine gemeinsame Versionierung hat zwei Seiten. Ändert sich ein Symbol, wird der Cache-Eintrag des gesamten Sprite-Sheets ungültig, und jeder Nutzer lädt alles erneut herunter. Ein häufig veränderter Symbolsatz eignet sich schlecht für Sprites.
• Alles, was Umfärben oder Themes erfordert. Bei einem Raster-Sprite sind die Farben fest eingebaut. Dunkelmodus, Marken-Themes und Zustandsfarben erfordern deshalb entweder ein zweites Sprite-Sheet oder störanfällige Filtertricks. Das ist der deutlichste strukturelle Vorteil von SVG.
• Symbole, die sich an die Schriftgröße anpassen müssen. Sprites sind an Pixelabmessungen gebunden. Wenn deine Symbole mitskalieren müssen mit em mit Text mitwachsen sollen, eignet sich ein Vektoransatz, während ein Sprite dir Schwierigkeiten bereitet.

Sprite, SVG-Sprite, eingebettetes SVG oder Symbolschrift

Verstehe die Tabelle als Entscheidungshilfe und nicht als Rangliste. Mehrfarbige Rastergrafiken – Flaggen, Logos, illustrierte Abzeichen oder Bildschirmaufnahmen von App-Symbolen – lassen sich nicht sinnvoll als SVG-Sprite darstellen. Genau in diesem Bereich sind CSS-Sprites weiterhin die richtige Lösung und nicht bloß ein Überbleibsel aus früheren Zeiten.

Eine erstellen

Der Arbeitsablauf umfasst vier Schritte, und nur der dritte ist von Hand knifflig.

1. Sammle die Symbole. Exportiere in der endgültigen Anzeigegröße oder in doppelter Größe – siehe den Retina-Abschnitt. Halte die Größen möglichst einheitlich. Ein gleichmäßiges Raster vereinfacht die Koordinatenberechnung und macht das CSS regelmäßig.
2. Stelle sie in einem Sheet zusammen. Eine einfache Reihe oder ein festes Raster ist leichter nachzuvollziehen. Ein Packalgorithmus nutzt den Platz bei unterschiedlichen Größen besser aus. Lass Zwischenräume zwischen den Symbolen.
3. Lies die Koordinaten ab. Jedes Symbol benötigt x, y, Breite und Höhe in Pixeln des Sprite-Sheets. Die manuelle Ermittlung im Bildeditor ist eine typische Fehlerquelle: Ein um ein Pixel falsch abgelesener Wert zeigt sich als schmaler Streifen des Nachbarsymbols, ohne Hinweis auf die Ursache.
4. Schreibe das CSS. Eine gemeinsame Grundregel und eine kleine Regel pro Symbol.

Die gemeinsame Grundregel ist wichtiger, als sie aussieht. Jedes Symbol benötigt dieselbe background-image, background-repeat: no-repeat, und display: inline-block. Wenn du die background-image Eine URL in fünfzig Regeln ist kein Leistungsproblem – der Browser ruft sie trotzdem nur einmal ab. Es ist aber ein Wartungsproblem: Benennst du das Sheet zum Erneuern des Caches um, musst du fünfzig Stellen statt einer ändern. Das Muster besteht daher aus einer Basisklasse mit allen gemeinsamen Eigenschaften und Symbolklassen nur für Position und Größe:

Im Markup lautet das <span class="sprite sprite-search"></span>. In Sass wird dieselbe Idee üblicherweise als Platzhalter ausgedrückt, %sprite-base, das in jede Symbolregel eingebunden wird mit @extend – dadurch entsteht in der kompilierten Ausgabe ein gemeinsamer Selektor statt wiederholter Deklarationen, und das Markup bleibt bei einer einzigen Klasse pro Symbol.

Retina und HiDPI: der Trick mit background-size

Diesen Teil überspringen die meisten Leitfäden oder erklären ihn falsch. Ein mit 1x gezeichneter Raster-Sprite wirkt auf einem 2x-Display weich. Die Lösung ist nicht, deine Versätze zu ändern. Packe stattdessen mit doppelter Auflösung und sage CSS anschließend, dass das Sheet halb so groß ist wie tatsächlich.

Nimm das vorherige Beispiel und verdopple beim Export alles: Die Symbole haben 48×48 tatsächliche Pixel, der Zwischenraum beträgt 16, und das Sheet hat 320×64 tatsächliche Pixel. Setze nun background-size: 160px 32px – genau die Hälfte der tatsächlichen Sheet-Abmessungen. Der Browser skaliert das gesamte Sheet auf einen 160×32-CSS-Pixel-Koordinatenraum herunter und ordnet die zusätzlichen Details den physischen Pixeln des Geräts auf einem HiDPI-Bildschirm zu.

Der Vorteil ist, dass alle anderen Zahlen in deinem CSS im ursprünglichen 1x-Koordinatensystem bleiben. Das dritte Symbol ist weiterhin background-position: -72px -8px mit width: 24px; height: 24px, unverändert, obwohl seine tatsächlichen Pixel in der Datei bei 144, 16 liegen. Du berechnest die Versätze einmal in CSS-Pixeln, und die einzelne background-size Deklaration in der Basisklasse übernimmt die Zuordnung der Pixeldichte für alle Symbole gleichzeitig.

Daraus folgen zwei Dinge, die ausdrücklich genannt werden sollten. Erstens: background-size gehört in die gemeinsame Grundregel und sollte nicht pro Symbol wiederholt werden. Zweitens solltest du nicht ohne guten Grund zwei Sheets über eine Media Query ausliefern. Das 2x-Sheet in halber Größe sieht auch auf 1x-Displays korrekt aus, weil der Browser es lediglich herunterrechnet. Ein Sheet und eine Regel decken so beide Fälle ab, zum Preis der größeren Datei. Da ein gut komprimiertes Symbol-Sheet meist klein ist, lohnt sich diese Abwägung normalerweise. Sie vermeidet außerdem den schwierigen Zwischenbereich gebrochener Geräte-Pixelverhältnisse wie 1.5 und 2.5, bei denen eine Media Query eine Seite wählen muss und eine davon falsch liegt.

Hover- und Zustandsvarianten

Das klassische Sprite-Layout für interaktive Elemente ist ein Raster, in dem jede Spalte ein Symbol und jede Zeile einen Zustand darstellt: Standard in Zeile eins, Hover in Zeile zwei, aktiv oder deaktiviert in Zeile drei. Da sich die Spalten nicht bewegen, ist ein Zustandswechsel eine reine Y-Verschiebung. Der X-Versatz bleibt exakt gleich.

Bei 24px großen Symbolen und einem Zwischenraum von 8px liegt Zeile eins bei y = 8 und Zeile zwei bei y = 40. Die Standardregel des dritten Symbols ist background-position: -72px -8px und seine Hover-Regel ist background-position: -72px -40px. Wenn du den vertikalen Schritt als Variable festlegst – etwa --sprite-row: 32px – du kannst den Hover-Zustand einmal in der Basisklasse ausdrücken mit calc() mit einer X-Variablen pro Symbol, statt für jedes Symbol eine zweite Regel zu schreiben.

Hier ist der Sprite einzelnen Dateien weiterhin tatsächlich überlegen: Die Hover-Pixel wurden mit den Standardpixeln geladen, sodass der erste Hover-Zustand sofort erscheint. Deshalb solltest du Zustände auch auf demselben Sheet halten, statt sie aufzuteilen. Ein separates Hover-Sheet bringt genau das Flackern durch eine Anfrage beim ersten Hover zurück, das dieses Layout verhindern sollte.

Abstände und warum auslaufende Farben hier weniger stark auftreten als in Spielen

Wenn Bilder direkt nebeneinander gepackt werden, kann die Texturabtastung über die Grenze eines Symbols hinausreichen und Farbe vom Nachbarn einbeziehen. In Spiel-Engines ist das ein ständiges, bekanntes Risiko, weil Texturen verkleinert, mit Mipmaps versehen, gefiltert und mit beliebigen Transformationen im Subpixelbereich gezeichnet werden.

CSS-Sprites befinden sich in einer weniger anspruchsvollen Umgebung. Es gibt keine Mipmaps, Hintergründe werden normalerweise an ganzzahligen Positionen zusammengesetzt, und bei exakt 1:1 ohne Transformation überschreitet keine Abtastung die Grenze. Aber „seltener“ heißt nicht „nie“. Probleme treten an vorhersehbaren Stellen auf: bei gebrochenen Geräte-Pixelverhältnissen (1.5, 2.25, 3), beim Browser-Seitenzoom mit ungewöhnlichen Prozentwerten und bei jeder transform: scale() bei einem übergeordneten Element und die background-size Verkleinerung aus dem Retina-Abschnitt – all das legt Symbolkanten auf nicht ganzzahlige Geräte-Pixelgrenzen, an denen der Compositor interpolieren muss.

Die Lösung ist dieselbe und kostet wenig: Lass einen kleinen transparenten Zwischenraum von 2 bis 4 Pixeln bei 1x, also 4 bis 8 in einem 2x-Sheet, zwischen allen Symbolen und um den Außenrand des Sheets. Das erhöht die Dateigröße nur minimal und beseitigt eine ganze Klasse von Fehlermeldungen wie „Links an diesem Symbol ist eine schwache Linie, aber nur auf meinem Laptop“. Die ausführlichere Variante des Problems – Extrusion, auslaufende Mipmap-Farben und Größen als Zweierpotenzen – wird für Spiel-Engines behandelt unter Sprite-Atlas-Packung: Abstände, Zweierpotenzen und auslaufende Farben.

Häufige Fehlerbilder

• Benachbarte Symbole sind an den Rändern sichtbar. Der Elementrahmen ist größer als das Symbol, sodass das Fenster darüber hinausgehenden Sheet-Inhalt zeigt. Entweder sind Breite oder Höhe falsch, oder der Innenabstand des Elements vergrößert den Rahmen. Prüfe, ob box-sizing: border-box verwendet wird, weil es verändert, was deine angegebene Breite umfasst.
• background-repeat: no-repeat vergessen. Die Voreinstellung ist repeat, sodass das Sprite-Sheet gekachelt wird und Teile anderer Symbole den Bereich füllen. Das fällt leicht nicht auf, wenn das Symbol zufällig nahe am Ursprung des Sprite-Sheets liegt und fast richtig aussieht.
• Ein span-Element ohne Abmessungen. Inline-Elemente ignorieren width und height vollständig, sodass ein leeres <span> mit einer Sprite-Klasse schrumpft auf Größe null, und nichts wird dargestellt. Setze display: inline-block (oder block, oder mache es zu einem Flex-Element) in der Basisklasse.
• Veraltetes Sheet nach einem Neubau. Du packst den Sprite neu, die Koordinaten ändern sich, aber ein wiederkehrender Besucher hat noch das alte Sheet im Cache und dein neues CSS. Für ihn ist deshalb jedes Symbol leicht falsch, für dich perfekt. Erneuere den Cache, indem du bei jedem Neubau den Dateinamen änderst, etwa mit einem Inhalts-Hash, sprite.a1b2c3.png), statt sich auf einen Query-String oder darauf zu verlassen, dass Nutzer die Seite unter Umgehung des Caches neu laden.
• Versätze um halbe Pixel. Ungerade Symbolgrößen, ungerade Zwischenräume oder ein ungerader Anfangsrand in einem 2x-Sheet erzeugen beim Halbieren Bruchteile von Pixeln als Versatz. Genau dieser Versatz verursacht Farbsäume an den Kanten. Halte jede Abmessung im 2x-Sheet gerade.

Häufig gestellte Fragen