Sprites sind kein veralteter Trick aus der Mottenkiste. Sie sind oft die performantere Lösung – und werden von den meisten Entwicklern nicht mal in Betracht gezogen.
Das ist ein Fehler.
#Was Twitter 2015 verstanden hat
Als Twitter den Herz-Button eingeführt hat, stand das Team vor einem konkreten Problem. Die neue Like-Animation bestand aus 16 gleichzeitig animierenden Elementen: 14 Partikel, ein aufploppender Kreis, das Herz selbst. Auf Low-End-Geräten war das schlicht nicht machbar – zu viele DOM-Knoten, zu viel Rechenaufwand.
Die Lösung kam nicht aus einer neuen Bibliothek. Sie kam aus den 90ern.
Ein Sprite-Sheet: alle Frames der Animation nebeneinander in einem einzigen Bild. CSS scrollt durch die Frames. Der Browser rendert immer nur ein statisches Bild – kein Layout-Recalculation, kein JavaScript, kein Canvas. Das Gerät muss nur ein Bild anzeigen und die Position verschieben.
Das ist keine Magie. Das ist Physik.
#Warum das heute noch relevant ist
Ich höre oft: "Aber wir haben doch CSS-Animationen, Lottie, GSAP." Stimmt. Und für viele Anwendungsfälle sind das die richtigen Werkzeuge. Aber sie haben alle einen gemeinsamen Nachteil: Sie arbeiten mit dem DOM oder mit JavaScript.
Sprites nicht.
Ein Sprite-Sheet ist nach dem ersten Laden gecacht. Die Animation läuft über animation und steps() in CSS – fertig. Kein Script muss laden, kein Framework muss initialisieren. Das ist besonders relevant bei Micro-Animationen, die auf Interaktion reagieren sollen. Like-Buttons, Favoriten-Icons, kleine Feedback-Animationen.
Genau dort, wo du Geschwindigkeit und Zuverlässigkeit brauchst, liefern Sprites.
#Wie es technisch funktioniert
Das Grundprinzip ist einfach. Du nimmst ein Bild mit allen Frames nebeneinander – das Sprite-Sheet. Dann zeigst du immer nur einen Ausschnitt davon an und bewegst das Bild Frame für Frame weiter.
Früher hat man das mit background-position gemacht und JavaScript getaktet. Heute geht das sauberer: CSS animation mit der steps()-Funktion springt diskret zwischen den Frames, statt flüssig zu interpolieren. Kein JavaScript-Gefrickel, kein Takt-Management.
.sprite {
animation: play 0.6s steps(10) infinite;
}
@keyframes play {
to { background-position: -1000px 0; }
}
Das war's im Kern. Ein Bild, eine CSS-Property, eine Animation.
#Das Gegenargument – und warum es nicht zieht
"Sprites sind aufwendig zu erstellen. Ich brauche ein fertiges Asset." Das stimmt. Du brauchst ein Sprite-Sheet, und das muss jemand bauen oder exportieren. Tools wie Adobe Animate, Aseprite oder sogar After Effects mit dem richtigen Export können das übernehmen.
Aber der Aufwand lohnt sich in bestimmten Szenarien. Wenn eine Animation auf vielen Geräten gleichzeitig laufen muss – zum Beispiel in einer Liste mit hunderten Einträgen – ist ein Sprite deutlich günstiger als 16 animierte DOM-Elemente pro Eintrag.
Ein anderes Gegenargument: "Lottie macht das doch auch performant." Lottie ist gut. Aber Lottie braucht eine JavaScript-Library, parst eine JSON-Datei und rendert dann mit Canvas oder SVG. Das ist mehr Overhead als ein gecachtes PNG mit zwei CSS-Zeilen.
Für komplexe Charakteranimationen oder große Illustrationen ist Lottie die bessere Wahl. Für kleine, häufig verwendete Micro-Animationen sind Sprites oft effizienter.
#Wann du Sprites einsetzen solltest
Nicht immer. Aber öfter als du denkst.
Sprites passen gut, wenn du eine Animation hast, die auf Low-End-Geräten laufen muss. Oder wenn viele Instanzen derselben Animation gleichzeitig auf dem Screen sind. Oder wenn du kein JavaScript laden willst – etwa in kritischen Rendering-Pfaden.
Sie passen weniger gut bei großen, detailreichen Animationen. Dort werden die Sprite-Sheets schnell groß und fressen Bandbreite. Auch bei Animationen, die auf Benutzereingaben reagieren und dynamisch variieren müssen, stoßen Sprites an ihre Grenzen.
#Was du konkret mitnehmen kannst
Erstens: Kenn dein Werkzeugset. Sprites existieren. Sie funktionieren. Sie sind in bestimmten Kontexten die beste Option. Wer das nicht weiß, greift automatisch zur schwereren Lösung.
Zweitens: Frag dich bei jeder Micro-Animation, ob du wirklich JavaScript brauchst. Oft nicht.
Drittens: Schau dir an, was Browser schon lange können, bevor du eine neue Library einbindest. steps() in CSS ist kein Geheimtipp – es ist einfach zu wenig bekannt.
Twitter hat 2015 keinen Algorithmus optimiert. Die haben einen alten Trick aus dem Regal gezogen und ihn auf ein modernes Problem angewendet. Das ist gutes Engineering. Nicht das Neueste nehmen, sondern das Richtige.
