Webflow Interactions oder GSAP: Was wann besser ist

Seit Webflow GSAP übernommen hat, stellt sich in jedem Projekt dieselbe Frage: Baue ich eine Animation mit den Interactions im Designer oder schreibe ich GSAP-Code? Beides läuft am Ende auf derselben Technik. Der Unterschied liegt darin, wer die Animation später versteht und pflegt. Hier ist, wie ich entscheide.

Was Interactions gut können

Interactions baust Du visuell im Designer: Auslöser wählen, Elemente auswählen, Bewegung einstellen. Kein Code, und Du siehst das Ergebnis sofort.

• Hover und Klick: Buttons, Karten, Menüs.
• Einblenden beim Scrollen: Elemente, die sanft hereinkommen.
• Seitenstart: eine kurze Animation, wenn die Seite lädt.
• Wiederverwendung: Eine Interaction mit Klassen läuft auf jeder Seite, auf der die Klasse vorkommt.

Die Projektkarten auf sxlvx.de sind so gebaut. Wenn Du mit der Maus über eine Karte fährst, fächern sich die Bilder auf. Das ist eine Interaction, die auf der Startseite, den Leistungsseiten, den Case Studies und im Blog läuft. Gebaut einmal, gepflegt an einer Stelle.

Wann ich zu GSAP-Code greife

Code lohnt sich, sobald eine Animation rechnen oder reagieren muss:

• Lange Scroll-Szenen: Animationen, die exakt am Scrollen hängen und über mehrere Bildschirmhöhen laufen.
• Messen und Ausrichten: Ein Element soll genau auf ein anderes zeigen, egal wie breit der Bildschirm ist.
• Inhalte aus Daten: Zahlen, die hochzählen, Listen, die aus dem CMS kommen, Texte, die in Wörter zerlegt werden.
• 3D und Physik: alles, was über Verschieben, Drehen und Einblenden hinausgeht.

Die Szenen auf meinen Leistungsseiten sind so gebaut. Beim Webdesign wird aus Fragen ein Wireframe und daraus eine Seite, und ein Mauszeiger zeigt dabei auf die richtigen Stellen. Wie das technisch funktioniert, steht ausführlich in meinem Beitrag GSAP in Webflow: So baue ich Scroll-Animationen.

Meine Entscheidungsregel

Ich stelle mir drei Fragen:

1. Muss jemand anderes das später ändern? Wenn ja, Interactions. Code im Embed fasst niemand gern an.
2. Muss die Animation etwas messen oder berechnen? Wenn ja, GSAP-Code.
3. Gibt es die Animation nur einmal? Eine einzelne Hero-Szene darf Code sein. Ein Effekt, der überall vorkommt, gehört in eine Interaction.

In der Praxis landen die meisten Websites bei einer Mischung: Interactions für alles Wiederkehrende, GSAP für die zwei oder drei Momente, an die man sich erinnern soll.

Performance: Die Technik ist selten das Problem

Ob Interaction oder Code, beides nutzt dieselbe Grundlage. Langsam wird eine Seite durch zu viele Animationen gleichzeitig, durch riesige Bilder in Bewegung oder durch doppelt geladene Bibliotheken.

Genau das ist mir auf sxlvx.de passiert: Ich hatte GSAP in jedem Embed noch einmal selbst eingebunden, obwohl Webflow es schon mitliefert. Seit die Embeds Webflows GSAP nutzen, ist das Problem weg. Die Zahlen dazu stehen im GSAP-Beitrag.

Drei Regeln, die ich immer einhalte:

• Nur transform und opacity animieren, nicht Breite, Höhe oder Abstände.
• Bei reduzierter Bewegung im Betriebssystem keine großen Animationen abspielen.
• Inhalte müssen auch ohne Animation lesbar sein. Google und Screenreader sehen keine Effekte.

Animation ist kein Selbstzweck

Bewegung lenkt den Blick. Zu viel davon lenkt ab. Ich frage bei jeder Animation, was sie erklären oder betonen soll. Wenn die Antwort „sieht cool aus“ ist, fliegt sie meistens wieder raus.

Ein Beispiel ist mein Website-Kosten-Rechner. Unter dem Rechner zählen die Ergebnisse meiner Partner beim Scrollen hoch und Versprechen, die ich nicht mache, werden durchgestrichen. Die Bewegung trägt dort die Aussage. Alles andere bleibt ruhig.

Wenn Du eine Website mit Bewegung planst, die etwas erzählt statt nur zu glitzern, schau Dir an, wie ich als Webflow Agentur in Ulm arbeite, oder schreib mir.

Gute Animation merkst Du nicht. Du verstehst nur schneller.