Es gibt einen Grund, warum JavaScript-Parallax immer leicht falsch aussieht – ein bisschen losgelöst, als würden die Ebenen einen halben Frame hinter der Seite schwimmen. Es ist kein nachlässiger Code. Es liegt daran, dass Scroll-Ereignisse JavaScript erst erreichen, nachdem der Browser das Scrollen bereits gerendert hat. Der Browser hat das schon einmal gelöst, als er klebende Header in position: sticky verwandelte. Scroll-driven Animations sind derselbe Schritt, auf alle scroll-gebundenen Effekte gleichzeitig angewendet.
Zehn Jahre lang bedeutete das Animieren einer Miniatur zu einem Hero-Bild eine einzige Technik: vor dem Element messen, danach messen, den Unterschied mit einem Transform vortäuschen und abspielen. FLIP. Jede Animationsbibliothek macht das so – und jede zahlt dafür mit JavaScript auf dem Hauptthread im denkbar schlechtesten Moment. Die View Transitions API verlagert diesen Trick in den Browser – und seit React 19.2 und Next.js 16 besteht der gesamte Vertrag aus einem einzigen Prop namens name.
Im Artikel über Mikrointeraktionen schrieb ich, dass transform und opacity auf dem Compositor-Thread animiert werden, sodass selbst eine schwere Seite die Button-Animation nicht zum Stocken bringen sollte. Das stimmt weiterhin – mit einer Einschränkung, über die jener Artikel schwieg: Ist der Hauptthread durch eine lange JS-Aufgabe blockiert, bekommt die Animation womöglich nie die Chance zu starten, weil schon der Klick-Handler in der Warteschlange wartet. INP ist die Metrik, die genau diese Lücke misst – und scheduler.yield() ist eines der wenigen Mittel, sie wirklich zu schließen.
Der „Gefällt mir"-Button reagiert sofort, das Herz füllt sich, der Zähler steigt – noch bevor der Server überhaupt geantwortet hat. Das ist nicht die Geschwindigkeitsillusion aus dem Artikel über Mikrointeraktionen, das geht weiter: Die Oberfläche zeigt einen Zustand, der noch nicht existiert, und nimmt an, dass er gleich existieren wird. Ich schaue mir an, wie man das sicher baut – mit einem echten Rückzug aus der Lüge, wenn sich die Annahme nicht bestätigt, und warum manuelles setState plus catch die schlechtere Variante dessen ist, was useOptimistic bietet.
Zwei Shops, dasselbe Produkt, dieselbe Server-Antwortzeit – und trotzdem wirkt der eine schneller und vertrauenswürdiger. Der Unterschied liegt in Mikrointeraktionen: ein paar hundert Millisekunden Animation, die darüber entscheiden, ob Nutzer dem trauen, was sie auf dem Bildschirm sehen. Ich zerlege sie bis auf die Grundlagen – Trigger/Feedback-Modell, was im Rendering-Prozess des Browsers wirklich passiert, und prefers-reduced-motion.
CSS Houdini ist keine einzelne Technologie, sondern eine Sammlung von Spezifikationen mit sehr unterschiedlichem Reifegrad. Finden Sie heraus, welcher Teil davon heute produktionstauglich ist, wie @property und der Paint Worklet wirklich funktionieren – und warum der Rest weiterhin ein Experiment bleibt.
