Insights · Technik

3D auf der Website: Was es bringt und was es kosten darf

Von mowa.studio · Webdesign, Branding & Animation aus Wien · Veröffentlicht im Oktober 2026 · Aktualisiert im Oktober 2026

Eine Leuchte dreht sich, und plötzlich versteht man ihre Form. Ein Gebäude lässt sich von der Hofseite ansehen. Eine abstrakte Form reagiert auf den Zeiger und gibt einer Marke einen unverwechselbaren Einstieg. Für solche Momente kann 3D auf einer Website sehr gut sein.

Die weniger schöne Variante kennt man auch: Erst lädt eine Szene, dann ruckelt sie, und auf dem Handy liegt der Kontaktbutton irgendwo darunter. Ob eine 3D-Website überzeugt, hängt deshalb mindestens so sehr von der Umsetzung ab wie vom Modell.

3D lohnt sich, wenn räumliche Darstellung etwas erklärt oder einen gezielten Markenmoment schafft. Ladezeit, Bedienbarkeit und eine funktionierende Alternative gehören von Anfang an ins Konzept.

Muss das wirklich in Echtzeit laufen?

Bevor wir über WebGL oder Three.js sprechen, klären wir, was Besucher mit einer Szene machen sollen. Wenn die Kamera immer dieselbe Fahrt zeigt und niemand eingreifen kann, kann ein gut vorbereitetes Video die passendere Lösung sein. Geht es nur um eine besondere Perspektive, reicht möglicherweise ein gerendertes Bild.

Echtzeit-3D wird interessant, wenn Interaktion einen Nutzen hat: drehen, einen Ausschnitt betrachten, Varianten wechseln oder eine räumliche Beziehung erkunden. Diese Funktion braucht wiederum eine verständliche Bedienung. Niemand sollte erst erraten müssen, dass sich ein Objekt ziehen lässt.

Die Tabelle ist eine Entscheidungshilfe, keine Rangliste. Ein Bild kann für die Aufgabe besser sein als eine technisch aufwendige Szene. Und eine kleine, gut gebaute Szene kann genau den Unterschied machen, den ein austauschbares Titelbild nicht schafft.

Wo eine 3D-Website langsam werden kann

Die Dateigröße ist nur ein Teil. Modelle und Texturen müssen geladen und verarbeitet werden; danach berechnet das Gerät fortlaufend Bilder. Eine Szene kann schnell erscheinen und trotzdem beim Scrollen oder Bedienen zu viel Leistung beanspruchen.

Die WebGL-Empfehlungen von MDN behandeln unter anderem Speicherverbrauch, Zeichenaufrufe und eine angepasste Renderauflösung. Für ein Projekt heißt das praktisch: Wir brauchen ein Budget für Detailgrad, Texturen und Effekte. Ein Modell aus einer Produktvisualisierung ist nicht automatisch für den Browser vorbereitet.

Darüber sollte man früh sprechen. Ist auf einem Smartphone nur ein kleiner Ausschnitt zu sehen, braucht dieser nicht dieselbe Detailmenge wie eine großformatige Nahaufnahme. Ein ständig bewegter Hintergrund muss auch nicht weitergerechnet werden, wenn er längst außerhalb des sichtbaren Bereichs liegt.

Was zuerst sichtbar sein sollte

Besucher kommen wegen eines Angebots, eines Produkts oder einer Information. Der Text, die Navigation und der Weg zur Anfrage sollten unabhängig davon funktionieren, ob die 3D-Szene schon bereit ist.

Eine gute Vorbereitung sieht deshalb einen festen Platz für die Szene vor, dazu ein passendes Vorschaubild. So springt der restliche Inhalt beim Laden nicht plötzlich nach unten. Für Szenen weiter unten auf der Seite lässt sich prüfen, ob sie erst bei Annäherung geladen werden müssen. Ein wichtiger Aufmacher braucht dagegen eine eigene Ladeplanung; pauschales Nachladen ist dort nicht immer sinnvoll.

Auch die Inhalte selbst gehören ins HTML. Produktdaten, Leistungsbeschreibungen und Links sollten außerhalb der Zeichenfläche erreichbar sein. Eine Suchmaschine und ein Screenreader sollen nicht auf die Beschriftung eines drehenden Objekts angewiesen sein.

Welche Messwerte zählen?

Bei den Core Web Vitals geht es um das Laden des größten sichtbaren Inhalts, die Reaktion auf Eingaben und unerwartete Layoutverschiebungen. Als gute Werte gelten LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, jeweils am 75. Perzentil realer Aufrufe. Die Grundlagen erklärt Googles Dokumentation zu den Core Web Vitals.

Ein einzelner Lighthouse-Test beantwortet allerdings nicht, wie sich eine Szene auf allen Geräten verhält. Zusätzlich gehören echte Smartphones, langsamere Verbindungen und längere Nutzung zum Test. Lässt sich das Menü noch flüssig bedienen? Bleibt Scrollen zuverlässig? Wird das Gerät bei längerem Aufenthalt auffällig warm?

Ein universelles Limit wie „jede Szene darf höchstens zwei Megabyte haben“ wäre dafür zu grob. Wir würden das Budget am tatsächlichen Inhalt und an den Zielgeräten festmachen und dann messen. Ein technischer Grenzwert allein sagt noch nichts darüber aus, ob die Szene ihren Platz verdient.

Manche Menschen möchten weniger Bewegung

Die Systemeinstellung für reduzierte Bewegung lässt sich über prefers-reduced-motion berücksichtigen. Sie ist ein konkreter Hinweis, nicht bloß eine gestalterische Vorliebe des Teams.

Für eine dekorative Szene kann eine ruhige Ansicht genügen. Wenn Interaktion notwendig ist, sollten Funktionen ohne dauernde Kamerafahrten oder automatische Rotation erreichbar bleiben. Tastaturbedienung, verständliche Beschriftung und eine Alternative bei technischen Problemen müssen separat geplant werden. Die Media Query erledigt das nicht von selbst.

Wie wir eine Szene beurteilen würden

Unsere eigene Website nutzt WebGL im Einstieg; auf Über uns kommt eine räumliche Logodarstellung dazu. Das sind Beispiele für Markeninszenierung. Sie sind kein Beleg dafür, dass jedes Unternehmen 3D braucht oder dass eine Szene automatisch mehr Anfragen erzeugt.

Für ein neues Projekt würden wir zunächst einen kleinen Prototyp bauen und drei Fragen prüfen: Versteht man damit etwas besser? Passt die Bewegung zur Marke? Funktioniert die Seite auch unter weniger günstigen Bedingungen?

Erst danach lohnt sich die Ausarbeitung von Material, Licht und Übergängen. Auf unserer Seite zu 3D-Webdesign geht es um diese Verbindung aus Gestaltung und Entwicklung. Wer zunächst den gesamten Auftritt einordnen möchte, findet im Artikel über Premium-Webdesign die Kriterien jenseits eines einzelnen Effekts.