· Loris Hliddal

Apple-Scroll-Effekt: Scrollytelling performant bauen

Zusammenfassung (in 30 Sekunden)

Der Scroll-Effekt auf Apples MacBook-Produktseiten – das Gerät dreht sich, klappt auf und wechselt seine Zustände, während man scrollt – ist kein Live-3D im Browser. Es ist eine vorgerenderte Sequenz, deren Fortschritt an die Scroll-Position gekoppelt wird. Das Prinzip ist erstaunlich einfach. Die Qualität entsteht woanders.

Genau dort scheitern die meisten Nachbauten: Sie kosten zu viel Rechenarbeit pro Bild, ruckeln auf dem Handy und der Mittelklasse-Hardware der Kundschaft, blockieren beim Laden den Browser und beschädigen die Core Web Vitals. Der sichtbare Effekt ist identisch – das Engineering darunter nicht.

Dieser Artikel zeigt, wie der Apple-Scroll-Effekt technisch funktioniert, woran Scrollytelling in der Praxis kaputtgeht, und was ein Scroll-System wirklich performant macht – belegt mit Messdaten aus unserem eigenen System.

MacBook etwa zu drei Vierteln aufgeklappt, der Bildschirm zeigt bereits unsere Homepage – ein Standbild aus der scroll-getriebenen Sequenz
Mitten in der Aufklapp-Bewegung: Beim Scrollen öffnet sich das Gerät und der Bildschirm baut sich auf – genau der Apple-Effekt, um den es hier geht.

Apples MacBook-Produktseite ist zum heimlichen Referenzbild für „hochwertige Website” geworden. Man scrollt, und das Produkt inszeniert sich wie in einem Film: Es rotiert, der Bildschirm baut sich auf, einzelne Kapitel ziehen vorbei. Fast jede Anfrage nach einem „besonderen” Web-Auftritt enthält irgendeine Variante des Satzes: „So etwas wie bei Apple.” Die spannende Frage ist nicht, ob man das nachbauen kann. Sondern warum die meisten Nachbauten sich billiger anfühlen als das Original – obwohl der Effekt gleich aussieht.

Scroll-Position
Wie weit ist die Sektion gescrollt?
ergibt
Fortschritt 0 → 1
Eine einzige Zahl steuert alles
wählt
Passendes Bild / Videozeit
Vorgerenderter Frame statt Live-Berechnung
zeigt
Glatte Sequenz
Geringe Last, kein Live-3D

Wie Apple den Scroll-Effekt auf der MacBook-Seite wirklich macht

Der erste Reflex ist, hinter dem Effekt eine Live-3D-Engine zu vermuten, die das MacBook im Browser in Echtzeit rendert. Das wäre der teure, fragile Weg – und Apple geht ihn bewusst nicht. Stattdessen ist die sichtbare Produktbewegung ein vorproduziertes Video beziehungsweise eine Bildsequenz, deren Wiedergabe nicht über die Zeit, sondern über den Scroll-Fortschritt gesteuert wird. Man „spult” beim Scrollen durch ein fertiges Video. Entwickler nennen das einen Scroll-Scrub.

Der entscheidende Trick ist die Arbeitsteilung. Die teure visuelle Arbeit – Kamerafahrt, Beleuchtung, Materialien, Bildschirminhalte – passiert einmalig beim Rendern, lange bevor ein Besucher die Seite öffnet. Im Browser bleibt nur eine billige Aufgabe übrig: zur aktuellen Scroll-Position das passende, bereits fertige Bild zeigen. Die Kapitel-Texte daneben bleiben dabei echtes HTML, kein Teil des Videos.

So sieht das in der Praxis aus – die vorgerenderte Sequenz, die in unserem eigenen scroll-getriebenen System steckt:

Echtes Projektmaterial
Vorgerenderte Sequenz aus unserem MacBook-Scroll-System: Im Browser wird daraus beim Scrollen jeweils das passende Bild gezeigt – keine Live-3D-Berechnung. Das Video lädt erst, wenn es in Sichtweite kommt.
Was hinter dem Apple-Scroll-Effekt wirklich steckt
AnnahmeMythosRealität bei Apple
Wie entsteht die Bewegung?Live-3D-Engine im BrowserVorgerendertes Video / Bildsequenz
Was steuert den Ablauf?Eine Zeitachse / AutoplayDer Scroll-Fortschritt (0 bis 1)
Wo sind die Texte?Ins Video eingebranntEchtes HTML daneben
Wo liegt die Hauptarbeit?Im Browser des BesuchersEinmalig im Render, vorab

Damit ist auch klar, warum das Prinzip jeder nachbauen kann – und warum trotzdem so wenige es gut hinbekommen. Das Konzept „Scroll steuert ein Video” ist trivial. Schwer ist alles, was dazwischen liegt: das Video flüssig laden, das richtige Bild rechtzeitig bereithalten, schnelles Scrollen abfangen, ohne dass es springt, und das Ganze auf schwacher Hardware nicht zur Diashow werden lassen.

Warum die meisten Scrollytelling-Nachbauten ruckeln

Ruckeln hat eine exakte technische Definition. Bei 60 Bildern pro Sekunde hat der Browser für jedes einzelne Bild genau 16,7 Millisekunden Zeit, um alles zu erledigen: Scroll-Position lesen, Effekt berechnen, neu zeichnen. Wird dieses Budget überschritten, fällt ein Bild aus – und das menschliche Auge nimmt genau das als Ruckeln wahr.

16,7 ms Zeitbudget pro Bild bei 60 fps – wer es überschreitet, produziert sichtbares Ruckeln
Quelle: Frame-Budget bei 60 Bildern pro Sekunde (web.dev, Rendering Performance)

Genau hier reihen sich die typischen Fehler auf. Viele Scroll-Effekte berechnen pro Bild viel zu viel im JavaScript, lösen teure Layout-Neuberechnungen aus, statt günstige GPU-Transformationen zu nutzen, oder laden ein riesiges Video, das beim Start den Hauptprozess des Browsers blockiert und damit die Interaktivität – und den Core-Web-Vitals-Wert INP – beschädigt.

web.dev — Rendering Performance, 2024

Dazu kommt das Speicherproblem. Eine flüssige Bildsequenz besteht aus hunderten hochauflösenden Einzelbildern. Wer sie naiv alle gleichzeitig entschlüsselt im Speicher hält, bringt schwächere Geräte ins Schwitzen oder zum Absturz. Und der unsichtbarste Fehler von allen: Der Effekt wird auf einem High-End-MacBook in der Agentur entwickelt und getestet – wo alles flüssig läuft – und erst beim Kunden auf dem Mittelklasse-Notebook oder dem Smartphone zur ruckelnden Enttäuschung.

Effekt sieht gut aus
Getestet auf Agentur-Hardware
live beim Kunden
Mittelklasse-Notebook
Gleiche Arbeit, langsamere CPU
Budget gesprengt → Frames fallen
Folge
Ruckeln statt Wow
Wirkt billig statt hochwertig

Hält Ihre Scroll-Animation 60 fps?

Bevor es weitergeht, lohnt sich ein Gefühl für die Grössenordnungen. Der folgende Rechner macht das Frame-Budget greifbar: Stellen Sie ein, wie viel Arbeit eine Scroll-Animation pro Bild verursacht – und sehen Sie, ab wann es auf der realen Hardware Ihrer Besucher kippt.

Frame-Budget-Rechner: Hält Ihre Scroll-Animation 60 fps?
Bei 60 Bildern pro Sekunde hat der Browser exakt 16,7 ms pro Frame. Stellen Sie ein, was Ihre Animation pro Frame tut – und sehen Sie, ob es flüssig bleibt oder zur Diashow wird.
60 fps ist der Standard für flüssiges Scrollen.
8,0 ms
Scroll-Handler, Positionsberechnungen, Effekt-Logik.
6,0 ms
Entsteht, wenn Animationen Grösse/Position statt GPU-Transforms ändern. Sauber gebaut: nahe 0.
3,0 ms
Neuzeichnen sichtbarer Pixel.
Schwächere Hardware braucht für dieselbe Arbeit länger.
Ergebnis auf Mittelklasse-Laptop
Flüssig
Bleibt im Budget.
Frame-Budget bei 60 fps
16,7 ms
Alles darunter pro Frame läuft flüssig.

Die Lehre aus dem Rechner ist immer dieselbe: Nicht der Effekt entscheidet über Flüssigkeit, sondern wie sparsam er pro Bild arbeitet – und auf welchem Gerät man misst. Ein Effekt, der auf dem Entwickler-MacBook 10 Millisekunden braucht, liegt auf einem Mittelklasse-Notebook schnell bei 18 und auf einem schwachen Smartphone jenseits von 30. Aus „flüssig” wird so unbemerkt „Diashow”.

Wie ein Scroll-System gebaut wird, das nicht ruckelt

Die gute Nachricht: Jedes dieser Probleme ist lösbar. Es ist eine Frage von Engineering-Disziplin, nicht von Glück. Genau diese Disziplin – Probleme an der Wurzel lösen, statt Symptome zu überdecken – ist der Kern unserer Arbeit als Entwicklungspartner und steckt in dem scroll-getriebenen MacBook-System, das wir für unseren eigenen Auftritt gebaut haben. Die wichtigsten Hebel:

Was ein flüssiges Scroll-System ausmacht
Visuals vorrendern statt live berechnen
Pflicht
Nur GPU-Transformationen, kein Layout-Thrash
Pflicht
Bilder gestreamt & im Budget entschlüsseln
Hoch
Schnelle Sprünge dämpfen (kein Teleport)
Hoch
Alles live im Browser rendern
Bremst jedes Gerät

Konkret heisst das: Das grosse Scroll-Video wird nicht stumpf geladen, sondern als Datenstrom in den Decoder geschrieben (über die MediaSource-Schnittstelle des Browsers), damit der Hauptprozess frei bleibt und nichts den Seitenstart blockiert.

MDN Web Docs — MediaSource API, 2025

Die Bildsequenz hält immer nur ein begrenztes Fenster entschlüsselter Bilder im Speicher und lädt in Scroll-Richtung voraus – mit einer harten Obergrenze gleichzeitiger Decode-Aufgaben, damit kein Gerät überlastet wird. Und scrollt jemand sehr schnell, springt das Bild nicht teleportierend ans Ziel, sondern läuft kontrolliert nach: Ein grosser Zeitsprung wird sichtbar auf kleine Schritte gedämpft, sodass die Bewegung nachvollziehbar bleibt.

Wie gut das funktioniert, lässt sich messen – und genau das haben wir auf der Live-Seite getan, mit der Mess-Schicht, die direkt im System eingebaut ist:

showroom-scroll-diagnostics.log
[SCRUB] 779 Bilder gezeichnet während eines Scroll-Durchlaufs
[OK] 0 fehlende Bilder, 0 falsche Bilder, 0 Ersatzbilder
[OK] Render-Schleife nie über 9,4 ms (Budget: 16,7 ms)
[GUARD] Ziel-Sprung 1,9 s → sichtbar auf 0,4 s gedämpft (kein Teleport)
[RESULT] flüssige Sequenz, keine gefallenen Frames

Der vielleicht überraschendste Wert betrifft nicht die Animation selbst, sondern die Gesamt-Performance der Seite. Obwohl im Hintergrund ein mehrere Megabyte grosses Scroll-Video steckt, bleibt die Seite kerngesund:

Eigene Messung, PageSpeed Insights & Runtime-Diagnostik, Juni 2026
Messung auf der Live-SeiteWert
PageSpeed Performance (Desktop)100 / 100
Total Blocking Time (Browser blockiert)0 ms
Layout-Verschiebung (CLS)0
Gedroppte Frames beim Scrollen0
Grösse des geladenen Scroll-Videos7,33 MB
100 / 100 PageSpeed-Performance auf Desktop – mit einem 7,33 MB grossen Scroll-Video an Bord
Eigene Messung, Google PageSpeed Insights, Juni 2026

Das ist der eigentliche Punkt: „aufwändig” und „performant” schliessen sich nicht aus. Sie sind das Ergebnis derselben Entscheidung – nämlich die schwere Arbeit dorthin zu verlagern, wo sie den Besucher nichts kostet. Das Loop oben zeigt nur das Material; die eigentliche Magie ist die Kopplung an Ihr Scrollen – und die erlebt man am besten direkt:

Den Scroll-Effekt live & scroll-gekoppelt ansehen Im Showroom steuert Ihr Scrollen die Sequenz in Echtzeit – inklusive des leichten Plan B auf dem Handy.

Der unsichtbare Teil: was auf dem Handy passiert

Das wertvollste Stück Engineering an einem Scroll-System ist das, was niemand bewusst sieht: der Plan B. Eine aufwändige Scroll-Inszenierung gehört nicht auf jedes Gerät – und ein sauber gebautes System weiss das.

Unser System prüft vor dem Start sechs harte Signale: Ist es ein Smartphone? Hat der Bildschirm eine ungeeignete Geometrie? Hat die Nutzerin „Bewegung reduzieren” aktiviert? Ist der Datensparmodus an, die Verbindung sehr langsam oder das Gerät speicherarm? Trifft auch nur eines zu, wird das schwere Scroll-Video gar nicht erst geladen. Stattdessen erscheint eine ebenso hochwertige, aber leichte Variante. Auf dem Handy heisst das konkret: Das mehrere Megabyte grosse Video wird nie angefasst.

Der entscheidende Punkt

Die schwierige Arbeit an einer Scroll-Animation ist nicht der Effekt – den sieht man im Pitch-Video. Die schwierige Arbeit ist die kontrollierte Verschlechterung: dafür zu sorgen, dass schwache Geräte, langsame Verbindungen und Nutzer mit Bewegungsempfindlichkeit eine andere, passende Erfahrung bekommen statt einer kaputten. Das ist der Unterschied zwischen einem Effekt und einem System.

Diese Rücksicht ist nebenbei keine reine Technik-Kür, sondern Pflicht: Die Einstellung „Bewegung reduzieren” zu respektieren, ist Teil der Barrierefreiheits-Standards für animierte Inhalte.

MDN Web Docs — prefers-reduced-motion, 2025

Ein Effekt, der diese Wahl ignoriert, ist nicht „mutiger”, sondern schlechter gebaut.

Fazit: Der Effekt ist gratis, das Engineering nicht

Den Apple-Scroll-Effekt nachzubauen, ist kein Geheimnis – das Prinzip „Scroll steuert eine vorgerenderte Sequenz” lässt sich in wenigen Stunden zusammenstecken. Was es von einer billigen Kopie zu einem Erlebnis macht, das Vertrauen ausstrahlt, ist die unsichtbare Schicht darunter: Frame-Budgets, Speicher-Management, gedämpfte Sprünge, eingebaute Messung und ein durchdachter Plan B für jedes Gerät.

Schweizer Entscheider durchschauen den Unterschied sofort – nicht im Code, sondern im Bauchgefühl. Eine Seite, die auf dem eigenen Notebook ruckelt, signalisiert das Gegenteil von Präzision. Eine, die mühelos und flüssig läuft, signalisiert Engineering. Genau dieser Anspruch steckt in der Art, wie wir bei Garçon Studios Websites bauen: nicht der Effekt um des Effekts willen, sondern Technik, die ihre eigene Last vor dem Besucher versteckt. Wer eine scroll-getriebene Inszenierung will, die diesen Test besteht, braucht keinen Effekt-Bastler, sondern saubere Webentwicklung in Zürich.

Quellenangaben

5 Quellen

Scroll-Erlebnis bauen lassen, das nicht ruckelt

Eine scroll-getriebene Inszenierung auf Apple-Niveau – sauber gebaut, auf jedem Gerät flüssig und ohne Schaden an Ladezeit und Sichtbarkeit.

Projekt anfragen