Kann eine 3D-Website schnell sein? Ratgeber zu Core Web Vitals und WebGL-Performance
Der Satz „3D-Websites sind langsam“ stimmt nicht; richtig ist: „Schlecht umgesetzte 3D-Websites sind langsam.“ Der Unterschied liegt ausschließlich in den technischen Entscheidungen. In diesem Beitrag zeigen wir Schritt für Schritt, wie wir Googles Ladezeit-Metriken auf animierten und 3D-Websites im grünen Bereich halten.
Zuerst die Metriken: Was genau misst Google?
Google nutzt drei Core Web Vitals als Rankingsignal, und eine 3D-Website gefährdet jede dieser Metriken auf andere Weise:
- LCP (Largest Contentful Paint) – die Zeit, bis das größte Element im sichtbaren Bereich angezeigt wird. Liegt die 3D-Szene im ersten Bildschirm und gibt es kein Posterbild, wartet der LCP auf das Laden der Szene. Das ist das Worst-Case-Szenario.
- INP (Interaction to Next Paint) – wie schnell die Seite reagiert, wenn Nutzer mit ihr interagieren. Blockiert WebGL den Main Thread, bekommt jemand, der auf das Menü tippt, keine Reaktion.
- CLS (Cumulative Layout Shift) – Layoutverschiebungen auf der Seite. Wenn die Szene nachträglich lädt und plötzlich Platz beansprucht, schiebt sie die Inhalte darunter nach unten. Ein Fehler, der sich vollständig vermeiden lässt.
Regel 1 – Kein 3D im kritischen Rendering-Pfad
Die Kette der Ressourcen, die eine Seite zum Anzeigen benötigt, nennt man „kritischen Pfad“. Die 3D-Engine darf in dieser Kette nicht vorkommen. In der Praxis heißt das:
- Die 3D-Bibliothek wird erst nach dem ersten Rendern der Seite geladen und steht nicht als blockierendes Script im HTML.
- Der Szenen-Code wird vom Haupt-Bundle getrennt und als eigener Chunk nachgeladen. So tragen Seiten ohne 3D diese Last überhaupt nicht.
- Schriften und kritisches CSS haben Vorrang; die Szene kommt ganz zum Schluss.
Regel 2 – Das Posterbild ist nicht verhandelbar
Der Container, in dem die Szene sitzen wird, muss schon beim ersten Rendern in der richtigen Größe und mit einem statischen Bild darin bereitstehen. Diese eine Entscheidung löst drei Probleme gleichzeitig: Der LCP wird mit dem statischen Bild abgeschlossen, der CLS sinkt auf null, weil der Container bereits an seinem Platz ist, und Besucher sehen ein aussagekräftiges Bild, selbst wenn JavaScript gar nicht ausgeführt wird.
Das Bild wird in einem modernen Format und in der passenden Größe ausgeliefert; für Mobilgeräte und Desktop gibt es getrennte Versionen.
Regel 3 – Kein einziger Frame, bevor die Szene im Viewport ist
Eine Szene weiter unten auf der Seite sollte erst laufen, wenn Nutzer dorthin scrollen. Moderne Browser-APIs unterstützen das direkt: Die Render-Schleife startet erst, wenn die Szene die Sichtbarkeitsschwelle erreicht, und stoppt, sobald sie den sichtbaren Bereich verlässt. Auch wenn der Tab in den Hintergrund wechselt, wird das Rendern angehalten.
Allein das senkt Akkuverbrauch und durchschnittliche CPU-Last drastisch; ein Großteil der Beschwerden über heiß werdende und ruckelnde Smartphones hat genau hier seine Ursache.
Regel 4 – Ein Budget für Modelle und Texturen
Bei 3D-Websites steckt das meiste Gewicht nicht im Code, sondern in den Assets. Ein Modell vom Designer kommt nie unverändert ins Web. Die Budgetdisziplin, die wir anwenden:
- Polygonreduktion. Details, die auf dem Bildschirm nie sichtbar werden, werden entfernt; für das Web wird eine eigene Low-Poly-Version erstellt.
- Texturkompression. Texturen werden in komprimierte Formate umgewandelt, die die GPU direkt lesen kann; das reduziert sowohl die Downloadgröße als auch den Grafikspeicherbedarf.
- Begrenzte Texturgröße. 4K-Texturen braucht kaum eine Web-Szene. Die Größe richtet sich nach der Pixelfläche, die die Textur auf dem Bildschirm tatsächlich einnimmt.
- Modellformat. Es kommen fürs Web optimierte Formate mit Kompressionsunterstützung zum Einsatz.
- Vorberechnete Beleuchtung und Schatten. Statt Echtzeitschatten liefert eine vorab gebackene Lightmap denselben Look zu einem Bruchteil der Kosten.
Regel 5 – Qualitätsstufen je nach Gerät
Eine Szene wird nicht allen Nutzern gleich ausgeliefert. Pixeldichte des Displays, Anzahl der Prozessorkerne und verfügbarer Arbeitsspeicher werden ausgelesen; danach wird die passende Stufe gewählt:
- Hohe Stufe: vollständige Szene, Schatten und Reflexionen aktiviert.
- Mittlere Stufe: Texturen in niedrigerer Auflösung, Schatten deaktiviert, begrenzte Bildrate.
- Niedrige Stufe: Die Szene wird gar nicht erst gestartet, das Posterbild bleibt stehen.
Der letzte Punkt ist der wichtigste. Eine ruckelnde 3D-Szene schadet geschäftlich mehr als gar keine 3D-Szene, weil Besucher die Website als „kaputt“ abspeichern.
Regel 6 – Den Main Thread frei halten
Hier wird die INP-Metrik gewonnen oder verloren. Rechenintensive Aufgaben werden aus dem Main Thread ausgelagert, das Dekodieren von Modellen und das Vorbereiten von Texturen läuft im Hintergrund, und die Animationsschleife wird an den Rendering-Takt des Browsers gekoppelt. Bei scrollgesteuerten Animationen werden Event-Listener als passiv markiert, und das Layout wird nicht in jedem Frame ausgelesen.
Regel 7 – Text gehört niemals in das Canvas
Das ist eine SEO- und zugleich eine Barrierefreiheitsregel. Text, der in ein Canvas gezeichnet wird, kann weder Google noch ein Screenreader lesen. Jede Beschriftung, jede Überschrift und jeder technische Wert in der Szene hat ein HTML-Pendant auf der Seite. Die 3D-Ebene ist eine Präsentationsebene – nicht der Inhalt selbst.
Die Details dieses Ansatzes erläutern wir in unserem Ratgeber zur 3D-animierten Firmenwebsite, die Technologiewahl im Beitrag Three.js oder Spline?
Checkliste vor dem Livegang
- Ist die Seite bei deaktiviertem JavaScript lesbar und verständlich?
- Gibt es ein Posterbild, hat der Container die richtige Größe, treten Layoutverschiebungen auf?
- Rendert die Szene, bevor sie in den Viewport kommt? (Prüfung mit dem Framezähler in den Entwicklertools.)
- Nach wie vielen Sekunden erscheint der erste Bildschirm auf einem Android-Smartphone der Mittelklasse?
- Wie groß ist die gesamte Downloadgröße, und welcher Anteil entfällt auf 3D-Assets?
- Gibt es Verzögerungen, wenn man auf Menü, Formular oder Buttons tippt?
- Stoppt die Szene, wenn die Einstellung „Bewegung reduzieren“ aktiv ist?
- Liegen LCP, INP und CLS in den Felddaten (Real User Monitoring) innerhalb der Schwellenwerte?
Warum wirkt sich die Ladezeit direkt auf den Umsatz aus?
Ladezeit zahlt sich über zwei Kanäle gleichzeitig aus. Erstens organisch: Die Seitengeschwindigkeit ist eines der Rankingsignale von Google und bestimmt, wie viel Ihre SEO-Arbeit maximal erreichen kann. Zweitens bei der Werbung: In Google Ads beeinflusst die Nutzererfahrung mit der Landingpage den Qualitätsfaktor, und ein höherer Qualitätsfaktor senkt den Klickpreis. Eine langsame Landingpage bedeutet also weniger Klicks für dasselbe Budget.
Performance ist bei einer 3D-Website also keine Geschmacksfrage, sondern ein direkter Kostenfaktor.
Häufig gestellte Fragen
Verschlechtert eine 3D-Szene den LCP?
Nicht, wenn es ein Posterbild gibt. Der LCP wird mit dem statischen Bild abgeschlossen, die Szene startet erst danach. Ohne Posterbild wartet der LCP auf das Laden der Szene, und die Metrik verschlechtert sich deutlich.
Müssen wir 3D auf Mobilgeräten abschalten?
Nein, eine Abstufung nach Gerät reicht aus. Moderne Mittelklasse-Smartphones stellen eine optimierte Szene problemlos dar. Nur auf sehr leistungsschwachen Geräten wird die Szene deaktiviert.
Lässt sich 3D in unsere bestehende, langsame Website einbauen?
Zuerst muss die grundlegende Ladezeit verbessert werden. 3D auf eine ohnehin langsame Website zu setzen, verdoppelt das Problem. Die Reihenfolge lautet: technische Bereinigung, Ladezeit, dann die 3D-Ebene.
Wie schnell sollte die Seite laden?
Unser Ziel ist, dass der erste aussagekräftige Inhalt auf Mobilgeräten in weniger als zweieinhalb Sekunden erscheint. Da dieser nicht auf die Szene wartet, darf das vollständige Laden der Szene länger dauern – das ist kein Problem.
Wie messen Sie die Ladezeit?
Labortests allein reichen nicht aus; maßgeblich sind echte Nutzerdaten. Der Core Web Vitals-Bericht in der Search Console und Feldmessungen werden gemeinsam ausgewertet.