Performance-Bericht
Das 3D bleibt, die Kosten verlassen den ersten Seitenaufruf
Die Startseite zeigt eine Scroll-Story in Echtzeit-3D. Auf einem Mittelklasse-Handy blockierte sie den Main Thread für Sekunden, und PageSpeed Insights konnte den Test nicht abschließen. Hier die Änderungen, die Zahlen und was jede Änderung kostet.
PageSpeed Insights, mobil
| Seite | Score | LCP | TBT | CLS | FCP | Bericht | |
|---|---|---|---|---|---|---|---|
| Startseite/en-us | Vorher | Nicht abgeschlossen (2 Versuche: Renderer abgestürzt, dann Zeitüberschreitung) | PSI ↗ | ||||
| Nachher | 95 | 2.6 s | 80 ms | 0 | 1.7 s | PSI ↗ | |
| Produktseite/en-us/products/portva-140 | Vorher | 93 | 3.2 s | 40 ms | 0.007 | 0.9 s | PSI ↗ |
| Nachher | 94 | 3.0 s | 50 ms | 0.007 | 0.9 s | PSI ↗ | |
| Kollektion/en-us/collections/all | Vorher | 99 | 2.0 s | 10 ms | 0 | 0.9 s | PSI ↗ |
| Nachher | 98 | 2.4 s | 20 ms | 0 | 0.9 s | PSI ↗ | |
Was der Browser tun muss (lokaler Build)
Startseite
- JavaScript
- 557 → 295 KB-47%
- Übertragung gesamt
- 1,018 → 438 KB-57%
- Bilder
- 23 → 23 KB
- Main-Thread-Arbeit
- 4,435 → 1,596 ms-64%
- TBT
- 522 → 55 ms-89%
Produktseite
- JavaScript
- 297 → 298 KB
- Übertragung gesamt
- 721 → 560 KB-22%
- Bilder
- 297 → 133 KB-55%
- Main-Thread-Arbeit
- 1,207 → 1,128 ms-7%
- TBT
- 45 → 48 ms+7%
Kollektion
- JavaScript
- 295 → 295 KB
- Übertragung gesamt
- 515 → 515 KB
- Bilder
- 102 → 102 KB
- Main-Thread-Arbeit
- 740 → 824 ms+11%
- TBT
- 55 → 52 ms-5%
Was sich geändert hat – und was es kostet
- 01
three.js wartet auf die erste Interaktion
Der Hero zeigt zuerst das Produkt-Rendering. three.js, React Three Fiber und das Modell laden beim ersten Scrollen, Tippen oder Bewegen der Maus – genau dann, wenn sich die Story zu bewegen beginnt.
Kompromiss: Auf dem Handy ersetzt das Live-Modell das Poster etwa eine Sekunde nach dem ersten Tippen. Das Poster ist dasselbe Rendering, der Wechsel ist also eine Überblendung, kein Sprung.
- 02
Die Canvas rendert nur beim Scrollen
Die WebGL-Canvas zeichnete 60 Bilder pro Sekunde, auch auf einer ruhenden Seite. Jetzt rendert sie nur, wenn die Scroll-Timeline das Modell bewegt. Auf Rechnern ohne GPU (wie bei PageSpeed) wurde die Seite mit der alten Schleife nie ruhig.
Kompromiss: Künftige Idle-Animationen müssen ihre Frames selbst anfordern.
- 03
Der Kaufbereich ist im vorgerenderten HTML
Die Produktansicht las ?variant= selbst und machte Foto, Titel und Preis damit zu einem dynamischen Loch: Das LCP-Bild wurde erst entdeckt, wenn dieser Teil gestreamt wurde. Die statische Shell rendert jetzt die Standardvariante, das Bild-Preload steht im <head>, und die angefragte Variante ersetzt sie in derselben Antwort.
Kompromiss: Ein Deep Link auf eine andere Farbe kann bei langsamer Verbindung kurz die Standardfarbe zeigen.
- 04
Bilder werden gestaffelt geladen
Nur das Foto, auf dem man landet, lädt mit der Seite. Weitere Galeriebilder und Farbvarianten werden geladen, sobald die Seite ruhig ist, und bleiben danach gemountet – der Wechsel ist sofort. Thumbnails laden mit niedriger Priorität.
Kompromiss: Wer in der ersten Sekunde über eine Farbe fährt, sieht eventuell noch kurz die Standardfarbe.
- 05
Lifestyle-Szenen sind vorskaliert
Die Szenen wurden in jeder Größe als 2560-px-JPEGs (~180 KB) ausgeliefert. Ein Skript erzeugt jetzt WebP mit 640/1080/1920 px (6–27 KB), und der Image-Loader wählt die passende Größe.
Kompromiss: Bei neuen Renderings muss das Skript erneut laufen (scripts/scene-variants.mjs).
Wie gemessen wurde
- PageSpeed Insights, mobil: Lighthouse 13.6, emuliertes Moto G Power mit simuliertem langsamem 4G, ausgeführt auf Googles Servern (Teststandort: Asien). Jede:r kann die Tests über die Links unten wiederholen.
- „Vorher“ ist ein Lauf der Version, die seit Stunden live war. „Nachher“ ist der Median aus drei Läufen (nach LCP), nach einem zusätzlichen Lauf, der nach dem Deploy den Edge-Cache von Vercel aufwärmt.
- Bytes und Main-Thread-Zeit stammen aus Lighthouse 12.8 gegen einen lokalen Production-Build (Median aus 3), weil sie kaum vom Netzwerk abhängen.
Was diese Zahlen nicht zeigen
- Auf Produkt- und Kollektionsseite liegt der PageSpeed-Unterschied im Rauschen: Derselbe Code lag je nach Lauf zwischen 2,0 und 3,7 s LCP, bei Serverantworten unter 10 ms. Der Gewinn dort liegt in dem, was der Browser lädt (Bilder der Produktseite −55 %), nicht in einer belegbaren LCP-Änderung.
- Das sind Labordaten. Der Shop hat keinen echten Traffic, es gibt also keine Felddaten (CrUX) zur Bestätigung.
- Einzelne PageSpeed-Läufe schwanken um einige Punkte; kleine Unterschiede sind Rauschen.
- Der Liquid-Storefront liegt hinter dem Passwort des Dev-Stores, das PageSpeed nicht passieren kann – er fehlt daher in der Tabelle.
- Bilder kommen vom CDN von Shopify; der LCP auf einem echten Handy hängt vor allem vom Netz zwischen Besucher:in und CDN ab.
Code: vorher 993ba71, nachher 97e7b63.