CSS-Scroll-Zeitachsen oder ScrollTrigger.
Beide machen aus dem Scrollen Animation; der Unterschied ist nicht das Tempo, sondern der Ort der Arbeit: die Zeitachse des Browsers oder eine Bibliothek.
Die Frage sieht nach „was ist schneller“ aus, doch entschieden wird anderswo: wer berechnet den Fortschritt der Szene, und wo läuft diese Berechnung? Auf einer Scroll-Zeitachse berechnet ihn der Browser; mit einer Bibliothek berechnet ihn JavaScript und schreibt ihn in jedem Bild ins DOM. Die meisten weiteren Unterschiede folgen aus diesem einen.
Die Plattformseite: eine Animation an einer Zeitachse
In CSS lässt sich eine Animation statt an die Zeit an das Scrollen binden: `animation-timeline` wählt die Zeitachse (den Scroll-Container selbst oder die Sichtbarkeit eines Elements), `animation-range` sagt, welcher Teil dieser Achse genutzt wird. Weil der Bereich in Schlüsselwörtern steht, rechnet der Browser und nicht Ihr Code; eine geänderte Fenstergröße verlangt keine eigene Neuberechnung.
Das kostet etwas: das Bereichsvokabular ist klein, aber scharf. Für einen Bereich wie „Oberkante oben, Unterkante oben“ braucht es die kreuzende Variante statt des naheliegenden Schlüsselworts; in einem Abschnitt, der höher als der Viewport ist, verschiebt die falsche Wahl den Bereich um Hunderte Pixel. Und der Standardabstand rechnet die Scroll-Polsterung mit, sodass der für Ankersprünge gelassene Platz den Beginn der Achse verschieben kann.
Die Bibliotheksseite: jeder Wert liegt bei Ihnen
Eine Bibliothek ist eine Schicht, die aus dem Scrollen einen Zeitplan macht und in jedem Bild ein Callback liefert. Die Kosten messen sich in Bytes und Arbeit auf dem Haupt-Thread; der Gewinn heißt Kontrolle. Wer den Fortschritt lesen und auf ein Canvas zeichnen, einen Zählertext aktualisieren oder einen Zustand für die Barrierefreiheit ankündigen will, braucht den Wert ohnehin in JavaScript. Für Szenen, die das Layout halten, ist der Wrapper der Bibliothek ein fertiger Weg, Platz zu schaffen, ohne den Rhythmus der Seite zu brechen — doch weil er den Baum verändert, kann er auch verändern, was Ihre Selektoren treffen.
Sie ersetzen einander nicht, sie teilen sich die Arbeit
In der Praxis liegt die Grenze hier: Ist das, was CSS allein kann, eine visuelle Transformation (Verschiebung, Skalierung, Deckkraft, Unschärfe, Farbe), und ist es richtig, dass sie beim Zurückscrollen zurückläuft, dann genügt die Zeitachse. Muss der Wert in Text, auf ein Canvas oder in den Barrierefreiheitsbaum geschrieben werden, führt kein Weg an JavaScript vorbei — und selbst dann kann die Achse in CSS bleiben, während JavaScript den Fortschritt aus der Animation selbst liest. Genau diese Brücke nutzt diese Website: der Fortschritt kommt aus der CSS-Animation, geschrieben wird in JavaScript.
Mobil und Bewegungsvorliebe
Beide Ansätze müssen eine reduzierte Bewegung respektieren, doch das Tor sitzt an verschiedenen Stellen: in CSS steht die Regel in einer Media Query, bei der Bibliothek unterbleibt die Einrichtung ganz. Ein weiterer Unterschied ist die Zweiseitigkeit — eine Scroll-Zeitachse läuft in beide Richtungen und spult beim Zurückscrollen zurück. Gesten, die einmal geschehen sollen (Schreiben, Öffnen, Zählen), hängen deshalb an einem einmaligen Auslöser statt an der Achse.
Die kurze Antwort: die Plattformseite trägt heute die meisten Szenen, und zwar ohne ein einziges Byte; die Bibliothek bleibt der kürzeste Weg dort, wo sie wirklich kürzer ist — bei bedingten Abläufen, wenn das Verhalten in älteren Engines garantiert sein muss, und überall dort, wo Fortschritt zu einem Wert werden soll. Auf dieser Website fiel die Entscheidung durch Messung, und beide Bibliotheken wurden ausgemustert: Scrollen ist jetzt eine CSS-Zeitachse.
Kriterium
- Wo es läuft — CSS-Scroll-Zeitachse: In der Animations-Engine des Browsers; in unterstützenden Engines auch im Kompositor · ScrollTrigger: Auf dem Haupt-Thread, als JavaScript
- Ausgelieferte Bytes — CSS-Scroll-Zeitachse: Keine — die Syntax gehört zur Plattform · ScrollTrigger: Eine Bibliotheksdatei wird geladen (auf dieser Website 17,6 Kilobyte, auf jeder Seite)
- Browser-Unterstützung — CSS-Scroll-Zeitachse: Läuft, wo unterstützt; sonst wird die Animation nicht eingerichtet und das Element ruht auf seinem Endwert · ScrollTrigger: Die Bibliothek richtet in jeder Engine dasselbe Verhalten ein
- Bereichs-Vokabular — CSS-Scroll-Zeitachse: `animation-range`-Schlüsselwörter: cover · contain · entry · exit und ihre kreuzenden Varianten · ScrollTrigger: start/end-Zeichenketten und numerische Versätze
- Szene fixieren (Pin) — CSS-Scroll-Zeitachse: Das Element verschiebt sich auf seiner eigenen Zeitachse; kein Wrapper nötig · ScrollTrigger: Ein Wrapper (pin-spacer) wird eingefügt und Inline-Maße ins Element geschrieben
- Szenen, die Text, ARIA oder Canvas schreiben — CSS-Scroll-Zeitachse: CSS kann das nicht allein; der Fortschritt wird an JavaScript gebrückt · ScrollTrigger: Von Haus aus: ein Callback liefert in jedem Bild den Wert
- Fehlersuche — CSS-Scroll-Zeitachse: Das Animationspanel des Browsers; Zwischenwerte über `getAnimations()` · ScrollTrigger: Die Marker der Bibliothek und ihre eigene API
- Abhängigkeit und Versionen — CSS-Scroll-Zeitachse: Keine — kein Paket zum Aktualisieren · ScrollTrigger: Versionswechsel, Lizenz und Kompatibilität sind zu verfolgen
- Wo es passt — CSS-Scroll-Zeitachse: Visuelle, umkehrbare, an das Scrollen gebundene Szenen · ScrollTrigger: Bedingte Abläufe, komplexe Zeitpläne, garantiertes Verhalten in älteren Engines
HÄUFIGE FRAGEN
Trägt eine CSS-Zeitachse jede Szene?
Nein. Wo eine Szene Text schreibt, auf ein Canvas zeichnet oder ARIA aktualisiert, trägt CSS den Fortschritt, den Wert schreibt weiterhin JavaScript. Auf dieser Website zogen zwölf von zwölf Szenen auf CSS-Zeitachsen um; die Schärfegeste und die Canvas-Motoren blieben in JavaScript.
Was passiert in einem Browser ohne Unterstützung?
Die Animation wird gar nicht eingerichtet, und das Element ruht auf seinem Endwert im Markup. Verloren geht Bewegung, nicht Inhalt. Dafür lässt sich gestalten: die Szene bleibt in ihrem letzten Bild lesbar.
Was bringt das Entfernen der Bibliothek gemessen?
Zweierlei: die ausgelieferten Bytes und eine Synchronschleife in jedem Bild. Auf dieser Website sank das Anbieterpaket von 51,1 auf 33,5 Kilobyte, die am Fenster hängenden Scroll-Listener gingen auf null, und der schlechteste echte LCP fiel von 592–640 Millisekunden auf 440.