# YK Produce: genaue Scrollanalyse des Originals

Stand 7. September 2026. [Originalwebsite](https://ykproduce.co.jp/). Untersucht wurden die echten Browserzustände und die öffentlich ausgelieferten [JavaScript-Definitionen](https://ykproduce.co.jp/wp-content/themes/ykproduce/assets/js/bundle/app.bundle.js?ver=35) sowie [CSS-Regeln](https://ykproduce.co.jp/wp-content/themes/ykproduce/assets/css/app.css?ver=35). Dies ist eine Bestandsaufnahme, keine Gestaltungsempfehlung und keine Beschreibung der David-Demo.

## Korrektur der ersten Interpretation

`window.scrollY = 0` war richtig gemessen, die daraus zunächst abgeleitete Bezeichnung „transformierter eigener Inhaltscontainer“ war falsch. Tatsächlich scrollt `[data-barba="container"]` nativ mit `overflow-y: scroll`; dessen `scrollTop` verändert sich, während sein `transform` durchgehend `none` bleibt. Lenis steuert diesen Wrapper mit `.l-main` als Content, `duration: 1.1` und `wheelMultiplier: 0.58`. `window.scrollTo` steuert deshalb den falschen Scrollbereich. Es handelt sich nicht um ein virtuell transformiertes Gesamtlayout.

## Messmethode und Material

Desktop: Chrome 1440×1000. Nach Abschluss des Intros 93 Wheel-Eingaben à +120 px, danach 86 Eingaben à −120 px. Jede Eingabe wurde mit kumuliertem Input, `window.scrollY`, Lenis-Ziel/Ist/Velocity, Wrapper-`scrollTop`, BoundingRect, Transformmatrix, Scale, Rotation, Clip, Opacity und aktiven ScrollTrigger-Grenzen protokolliert. Vorwärts wurde etwa 150 ms zwischen Inputs gewartet, rückwärts 100 ms; Screenshots verlängern einzelne Intervalle. Daher sind dies überprüfbare gleich große Eingaben, aber keine künstlich perfekt gleichmäßige Zeitreihe. Lenis-Ziel stieg im Prüflauf pro 120 px-Eingabe um 70 px (Rundung des Faktors 0,58), der aktuelle Wert folgte verzögert. Am Ende vorwärts:6510 px; nach Rückwärtslauf 490 px.

Touch: Chrome mit 390×844, Touch- und iPhone-Emulation;15 echte CDP-Touch-Gesten à420 px aufwärts, anschließend 8 à400 px abwärts. Die nativen Touchwege sind durch Gestenschwellen nicht exakt identisch zur Fingerstrecke. Dies ist kein physischer iPhone-Test.

- [28-Sekunden-Ausschnitt des Originals](motion/ykproduce-scroll-review.webm)
- [Vollständige Desktopaufnahme inklusive Vor-/Rückwärtslauf](motion/ykproduce-scroll-desktop.webm)
- [Touchaufnahme](motion/ykproduce-scroll-touch.webm)
- [Rohdaten je Eingabe](motion/ykproduce-scroll-telemetry.json), [Stillstandskontrolle](motion/ykproduce-scroll-idle.json), [kompakte Galerie-Daten](motion/ykproduce-scroll-summary.json)

## 1. Fullscreen-Film → Our Two Sections

Der Hero ist kein gepinnter Vollbildabschnitt. Seine Section scrollt normal nach oben; die Videofläche wird durch einen Vorfahren mit `overflow:hidden` begrenzt. Innerhalb verschiebt ScrollTrigger das 1440×1000 px-Canvas von`translateY(0%)` bis`translateY(100%)`. Tatsächlicher Start im Desktoplauf: Scroller 10 px, Ende 4010 px, Strecke 4000 px, `scrub:true`. Das hält den Filmausschnitt länger im auslaufenden Hero und erzeugt vertikale Parallax. Es verändert weder Filmzeit noch Canvasgröße.

Gleichzeitig dreht das zentrale SVG von 0° bis 60°. Start 10 px, Ende 2010 px, Strecke 2000 px, ebenfalls`scrub:true`. Die wachsende BoundingBox des gedrehten Zeichens ist keine Skalierung: Matrix-Scale blieb 1. BeiScroller 681,92 px: Canvas-Translation+307,78 px, sichtbare Canvas-Oberkante−374,22 px; SVG-Rotation 33,55°. Die Film-Section selbst ist dann bereits 682 px nach oben gerückt.

Die gemessene Tween-Ease bei normiertem Fortschritt 0/0,25/0,5/0,75/1 lautet 0/0,4375/0,75/0,9375/1: quadratisches Ease-out. `scrub:true` heißt hier, dass die Position an Scroll gekoppelt ist; die Strecke ist innerhalb des Tweens trotzdem nicht linear. Dazu kommt die vorgelagerte Lenis-Glättung.

## 2. Dunkle Geschäftsbereiche: Text-Reveal und kleine Sticky-Labels

Die beiden großen Inhaltsblöcke liegen vertikal im normalen Dokumentfluss. Im Desktoplauf blieb das Sektionsbild über alle Stichproben bei 674,66×379,50 px, x 622,94 px und Scale 1. Titel und Bild bewegen sich mit dem Container nach oben. Es gibt weder Fullscreen-Takeover noch Bild-Morph oder eine gepinnte Kartenbühne.

Die Buchstaben der Sektionsüberschriften haben eine andere Auslösung: Die jeweilige Zeile erreicht`top 99%`, dann läuft ein zeitgesteuerter GSAP-Tween. Englisch im Desktop: Wedding-Schwelle 94 px, Creation 878 px. Die Zeichen kommen aus ungefähr 97,4 px vertikalem Versatz und 100° X-Rotation zu y 0/rotateX 0; Dauer 1,6 s,`power4.out`, Stagger 0,02 s pro Zeichen. Ein separater 2 s-Tween steuert die Zeichenfarbe. Diese Tweens haben kein`scrub`; das Scrollen startet sie, bestimmt aber nicht jeden Zwischenstand. Sie werden beim Zurückscrollen nicht automatisch rückwärts abgespielt (`toggleActions:play`). Kleinere Primärüberschriften verwenden y 110%→0%,1 s und 0,01 s Stagger bei`top 96%`.

Nur`.c-our-three__sticky-inner` haftet per CSS: Desktop`position:sticky;top:480 px`. Das erste Label bleibt ungefähr überScroller 623–1227 px auf y 480; das zweite ungefähr 1407–2011 px. Danach drückt die Unterkante des zugehörigen Abschnitts es wieder nach oben. Im gemessenen Mobile-CSS ist dasselbe Element`position:static`.

## 3. Dunkler Stack → PLAYFUL MINDS

Zwischen den Sektionen und der großen Typografie gibt es eine große vertikale Fläche. Die Hintergrundänderung beginnt, sobald`.p-home-what` die Viewportunterkante erreicht: Desktopstart 1993 px (`top bottom`). Die Farbe wechselt zeitgesteuert auf Hellgrau; parallel ändert sich die systemweite Vordergrundfarbe über 1 s. Der Canvas-Hintergrundwechsel wird mit 1,5 s angestoßen. Dies ist eine Scrollschwelle mit anschließendem Zeittween, kein fortlaufendes proportionales „Scrubbing“ der Farbe. Auf dem Rückweg wird der dunkle Zustand wieder angestoßen.

Die Schrift ist bereits riesig gesetzt und kommt durch normales vertikales Scrollen von unten ins Bild. Ihre Größe wird dabei nicht animiert. Der anfänglich angeschnittene Eindruck ist der Viewport-/Overflow-Ausschnitt, kein gemessener animierter`clip-path`.

## 4. Typografiebahn → Fotopanorama: zwei Bewegungen übereinander

Diese Passage ist die prägende Mechanik, aber nicht vollständig scrollgetrieben:

| Ebene | Tatsächliche Bewegung | Trigger und Strecke |
|---|---|---|
| Äußere Schriftbahn`.p-home-what__big-cover` | x 0→−10% ihrer 1872 px Breite, also 0→−187,2 px; Scale 1 |`top 80%`, Scroller 2193→4193 px;2000 px;`scrub:true` |
| Äußere Fotobahn`.p-home-what__images` | zusätzliche x 0→+187,2 px; durch CSS`left:-20%` liegt ihre tatsächliche Ausgangsposition bei−288 px und Endposition bei−100,8 px | derselbe Trigger und dieselbe 2000 px-Strecke |
| Innere Schriftgruppen`.p-home-what__big` | autonome Endlosschleife nach links:0→−102% | CSS`whatLoop`,50 s linear infinite; nicht vom Scrolloffset abhängig |
| Innere Fotogruppen`.p-home-what__image-cover` | autonome Endlosschleife nach rechts:−100%→0 | CSS`whatLoopReverse`,50 s linear infinite; nicht vom Scrolloffset abhängig |

Die Gruppen sind dupliziert, wodurch die Bahnen durchlaufen. Das kleine laufende Videofenster ist Teil der Schriftgruppe und reist mit ihr. Seine Wiedergabezeit läuft autonom. Die äußeren Bahnen sind Geschwister, keine ineinander verschachtelte Parallaxmaske.

Kontrollmessung ohne jeden Input, Scrollwert über 1,5 s exakt 2870 px: Äußere Schriftbahn unverändert x−105,285 px; äußere Fotobahn unverändert x−182,715 px. Die innere Schriftgruppe wandert trotzdem 80,744 px nach links und die innere Fotogruppe 86,968 px nach rechts. Die CSS-Keyframes wurden zusätzlich über`getAnimations()` im Browser bestätigt. Die−102% am Schriftende sind tatsächlich die wirksame spätere CSS-Keyframe-Definition, nicht die frühere−100%-Definition im selben Stylesheet.

Bei Rückwärtslauf kehrt nur die zusätzliche Scrolltranslation um:vorwärts bei 2835,97 px liegen die äußeren Transforms bei−101,02/+101,02 px; rückwärts bei 2854,68 px bei−103,42/+103,42 px. Die inneren Laufbänder laufen weiterhin in ihrer ursprünglichen Zeitrichtung. Deshalb ist ein Vergleich identischer Fotos an derselben Scrollposition allein kein brauchbarer Reversibilitätsnachweis.

## 5. Anschließender großer Filmblock

Nach Panorama und What’s-YKP-Text folgt`.p-home-copy`, Desktop 160 vh hoch mit`overflow:clip`. Das darin 120% hohe Video liegt absolut und bewegt sich zusätzlich von y−20% zu+80%. Start`top 70%`, im Desktoplauf 3561 px, Ende 6561 px, Strecke 3000 px,`scrub:true`. Gemessene Transformgrenzen:−384 px bis+1536 px; Video 1920 px hoch. Es bleibt Scale 1. Die sichtbare Videooberkante entsteht aus normalem Containerscroll, absolutem CSS-top und dieser Zusatztranslation zusammen. Bei der getesteten Desktophöhe 1000 px greift zusätzlich die Mediaquery`top:-90 vh`; mobil verwendet das Video`top:-30%`.

Das Fadenkreuz darüber folgt auf Desktop der Maus und benutzt beim Ein-/Austritt Clipmasken. Diese Masken gehören zur Hoverinteraktion, nicht zu der Scrollanimation. Der Film läuft zeitlich normal weiter; er wird nicht frameweise durch Scroll gesteuert.

## Mobile und Grenzen

Die Scrub-Strecken bleiben im Touchlauf grundsätzlich erhalten. Hero 10→4010 px, Zeichen 10→2010 px; Schrift/Fotobahn 1582→3582 px; Filmblock 2404→5404 px. Die Schrift-/Fotohüllen sind 507 px breit, daher beträgt die Zusatztranslation nur±50,7 px; die Fotohülle startet durch`left:-10%` bei−39 px. Der zweite Filmabschnitt ist 120 vh statt 160 vh hoch. Die Nummern haften mobil nicht.

Touch-vorwärts bei 2094 px: Schrifttranslation−22,64 px, Fototranslation+22,64 px, Scale jeweils 1. Nach Rückwärtsgesten bei 2740 px:−41,71/+41,71 px. Der Wrapper meldet nativ dieselben Scrollwerte wie Lenis; sein Transform bleibt`none`.

Im Desktop wurden 28 ScrollTrigger registriert, im Touchlauf zusätzliche Bild-Reveal-Trigger; kein registrierter Trigger hat`pin`. Keines der gemessenen Hauptbilder/-bänder hat eine scrollgetriebene Skalierung oder animierte`clip-path`-Form. Desktopfotos werden teilweise über WebGL gezeichnet; deren Farbbehandlung und Mausreaktion sind eine getrennte Ebene. Der Bericht behauptet aus DOM-Matrizen keine vollständige Vermessung aller Shader. Im Ausschnitt sichtbare Farbänderungen können auch durch den ruhenden Cursor auf einem darunter vorbeilaufenden Foto ausgelöst sein.

## Intro ausdrücklich getrennt

Die Unterwasser-Auftaktsequenz läuft nach Laden zeitlich ab. Sie wurde vor den Wheel-Messungen abgewartet und ist keine erste Scrollphase. [Echte Introaufnahme nach ungefähr 6 s](screenshots/ykproduce-23-desktop-intro-6s.png). Laufender Hero-Film,50 s-Marquees, zeitgesteuerte Buchstaben-Reveals und Hoverreaktionen sind ebenfalls nicht gleichbedeutend mit Scroll-Scrubbing.

## Sechs Originalphasen

Die Angaben sind zum Screenshotzeitpunkt erfasste Browserwerte, auf zwei Nachkommastellen gerundet; durch fortlaufende Animation können Bild und direkt anschließende DOM-Probe wenige Millisekunden auseinanderliegen.

| Bild | Kumuliertes Wheel | Scroller-Ist | Sichtbare Phase |
|---|---:|---:|---|
| [Phase 1](screenshots/ykproduce-scroll-01.png) | 0 px | 0 px | Regulärer Einstieg nach dem zeitgesteuerten Intro: Film und zentrales Zeichen stehen vor dem ersten Scroll. |
| [Phase 2](screenshots/ykproduce-scroll-02.png) | 1200 px | 681.92 px | Der Hero verlässt den Bildschirm; sein Film verschiebt sich zusätzlich nach unten, das Zeichen dreht sich. Die kleine Abschnittsnummer bleibt auf y=480 px. |
| [Phase 3](screenshots/ykproduce-scroll-03.png) | 3240 px | 1869.91 px | Die zweite Sektion läuft normal nach oben. Ihr Bild behält seine Größe; nur die kleine Nummer haftet noch. |
| [Phase 4](screenshots/ykproduce-scroll-04.png) | 4080 px | 2360.67 px | Der Hintergrund ist hell geworden. Das große Schriftband tritt von unten ein; Schrift- und Fotobahn beginnen ihre zusätzliche gegenläufige Scrollverschiebung. |
| [Phase 5](screenshots/ykproduce-scroll-05.png) | 4920 px | 2853.74 px | Schrift oben, Panorama darunter: Die äußere Schriftbahn liegt 103 px weiter links, die Fotobahn 103 px weiter rechts. Beide inneren Bänder laufen zusätzlich zeitgesteuert. |
| [Phase 6](screenshots/ykproduce-scroll-06.png) | 5880 px | 3413.73 px | Die Typografie ist oben verschwunden; das Panorama und der ruhige Textblock laufen weiter nach oben. Die Fotos werden dabei nicht vergrößert. |

Sämtliche Rohmessungen bleiben unverändert erhalten. Die frühere Interpretation des Containers wurde im ursprünglichen YK-Bericht ausdrücklich korrigiert.