3D in WordPress schnell halten.
WordPress-Seiten sind selten die schnellsten, 3D-Szenen auch nicht. Zusammen können sie trotzdem flott sein — wenn man ein paar Dinge konsequent richtig macht. Diese Seite zeigt, wo die Zeit verloren geht und wie du sie zurückholst, ohne auf 3D zu verzichten.
Die vier wirksamsten Maßnahmen: Skripte nur auf Seiten mit 3D laden, die Szene erst starten, wenn sie sichtbar ist oder angeklickt wird, bis dahin ein Vorschaubild zeigen, und die 3D-Skripte von „JavaScript verzögern“ und „Dateien zusammenfassen“ in Optimierungs-Plugins ausnehmen. Dazu kommen komprimierte Modelle und lange Cache-Zeiten.
Wo die Zeit verloren geht.
Bei einer WordPress-Seite mit 3D gibt es zwei ganz unterschiedliche Arten von „langsam“:
- Die Seite lädt langsam. Der erste Eindruck dauert zu lange, weil Three.js, Modelle und Texturen gleichzeitig mit der Seite geladen werden. Das kostet Besucher und wirkt sich auf die gemessene Ladezeit aus.
- Die Szene ruckelt. Die Seite ist geladen, aber das Drehen fühlt sich zäh an, der Lüfter läuft, das Smartphone wird warm. Das ist ein Problem der Szene selbst.
Für das erste Problem ist vor allem die Einbindung in WordPress verantwortlich — darum geht es in den Punkten 1 bis 5. Das zweite Problem liegt in der 3D-Umsetzung, dazu Punkt 6 und ausführlich der Ratgeber Three.js Performance optimieren.
Typische Ursachen im WordPress-Umfeld:
| Ursache | Folge |
|---|---|
| Three.js wird auf allen Seiten geladen | Jede Seite wird schwerer, auch ohne 3D |
| Modell lädt sofort beim Seitenaufruf | Megabytes vor dem ersten sichtbaren Inhalt |
| Page Builder plus 3D auf derselben Seite | Viel JavaScript konkurriert um den Hauptthread |
| Optimierungs-Plugin bündelt 3D-Skripte | Szene startet nicht oder zu spät |
| Texturen in 4K oder 8K | Lange Downloads, hoher Grafikspeicher |
| Modelle ohne Cache-Header | Wiederkehrende Besucher laden alles erneut |
1. Skripte nur bei Bedarf laden.
Die häufigste und am leichtesten vermeidbare Ursache: Ein Plugin oder Theme lädt Three.js auf jeder Seite — auf der Startseite, im Impressum, im Blog. Dabei braucht nur eine einzige Seite die Szene.
Wird 3D über einen eigenen Block eingebunden, erledigt WordPress das automatisch über viewScriptModule (siehe Gutenberg-Block für 3D). Bei Shortcodes lädt man die Skripte in der Shortcode-Funktion selbst. Für andere Fälle hilft eine Prüfung, ob die Seite den 3D-Inhalt enthält.
<?php
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_singular() ) {
return;
}
$post = get_post();
$hat_3d = has_block( 'manuel/modell-3d', $post )
|| has_shortcode( $post->post_content, 'konfigurator' )
|| get_post_meta( $post->ID, '_hat_3d', true ); // z. B. fuer Elementor-Seiten
if ( ! $hat_3d ) {
return;
}
wp_enqueue_script_module(
'szene-3d',
plugins_url( 'build/szene.js', __FILE__ ),
[],
'1.2.0'
);
} );Bei Elementor steht der Inhalt nicht in post_content, deshalb hier zusätzlich ein Metafeld als Schalter. has_block und has_shortcode prüfen nur den Inhalt der aktuellen Seite, nicht Widgets oder Vorlagen.
2. Szene verzögert starten.
Auch auf einer Seite mit 3D muss die Szene nicht sofort laden. Liegt sie weiter unten, reicht es, sie zu starten, kurz bevor der Besucher dort ankommt. Bei großen Szenen oder Konfiguratoren ist ein Start-Button oft noch besser: Nur wer wirklich interagieren will, lädt die Megabytes.
Wichtig dabei: Three.js selbst wird dann ebenfalls erst per import() nachgeladen. So bleibt die Seite beim ersten Aufruf so leicht wie ohne 3D.
const container = document.querySelector( '.szene-3d' );
if ( container ) {
const io = new IntersectionObserver( async ( [ eintrag ] ) => {
if ( ! eintrag.isIntersecting ) return;
io.disconnect();
// Three.js und Szene erst jetzt laden
const { starteSzene } = await import( './szene-start.js' );
starteSzene( container );
}, { rootMargin: '300px' } ); // 300 px vor Sichtbarkeit beginnen
io.observe( container );
}rootMargin sorgt dafür, dass das Laden etwas vor dem Erreichen der Szene beginnt, damit sie beim Hinscrollen schon bereit ist. Liegt die Szene ganz oben auf der Seite, ist ein Start-Button mit Vorschaubild meist die bessere Wahl.
3. Vorschaubild für schnelle Ladezeit.
Bei der Messung der Ladezeit zählt, wann das größte sichtbare Element erscheint. Steht eine 3D-Szene oben auf der Seite, ist das oft ein leerer Canvas oder ein Ladebalken — und das größte Element erscheint erst, wenn das Modell fertig ist.
Die Lösung ist ein Posterbild: ein Standbild der Szene, als WebP optimiert, mit festen Maßen, das sofort angezeigt wird. Die Szene lädt im Hintergrund und blendet über, sobald sie bereit ist. Für den Besucher sieht es aus, als wäre die Szene sofort da. Das Posterbild bekommt fetchpriority="high", wenn es ganz oben steht, und darf dann nicht mit loading="lazy" versehen sein.
Genauso wichtig: Der Bereich der Szene hat von Anfang an eine feste Höhe oder ein Seitenverhältnis. Sonst springt der Inhalt darunter, sobald die Szene erscheint — ein Layout-Sprung, den Besucher und Messwerkzeuge gleichermaßen bemerken.
4. Caching- und Optimierungs-Plugins.
Hier entstehen die meisten rätselhaften Fehler. Optimierungs-Plugins haben Funktionen, die für normale Seiten sinnvoll sind und 3D-Anwendungen zerstören können:
- JavaScript verzögern: Skripte laden erst bei der ersten Nutzerinteraktion. Eine 3D-Szene bleibt dann leer, bis jemand scrollt oder klickt — oder startet nie, wenn die Reihenfolge durcheinandergerät.
- JavaScript zusammenfassen: Mehrere Dateien werden zu einer gebündelt. ES-Module und Import Maps vertragen das häufig nicht.
- JavaScript minifizieren: Meist unkritisch, bei bereits minifizierten Bibliotheken aber überflüssig und gelegentlich fehlerhaft.
- Lazy Loading für iframes und Bilder: Kann Posterbilder verzögern, die sofort sichtbar sein sollen.
- Seiten-Cache: Unkritisch für die Szene selbst, aber eigene Schnittstellen für Konfiguratoren, Warenkorb und Anfragen dürfen nicht gecacht werden.
Die Lösung ist nicht, diese Funktionen abzuschalten, sondern die 3D-Skripte gezielt auszunehmen. Alle verbreiteten Optimierungs-Plugins bieten dafür Ausschlusslisten, in die man Dateinamen oder Teile davon einträgt — etwa three, model-viewer, den Namen des eigenen Szenenskripts und importmap.
Nach jeder Änderung an einem Optimierungs-Plugin: Seite im privaten Browserfenster öffnen, ohne zu scrollen oder zu klicken warten und in der Browser-Konsole nach Fehlern schauen. Viele Probleme zeigen sich nur ohne Interaktion — und nur für nicht angemeldete Besucher, weil Optimierungen für Administratoren oft abgeschaltet sind.
5. Modelle und Auslieferung.
- Texturen verkleinern: 1K bis 2K statt 4K, als WebP oder KTX2. Meist der größte Hebel bei der Dateigröße.
- Geometrie komprimieren: Draco oder Meshopt, mit passendem Decoder im Viewer.
- Lange Cache-Zeiten: Modelle und Texturen ändern sich selten und können ein Jahr im Browser-Cache bleiben. Bei Änderungen neuer Dateiname.
- HTTP/2 oder HTTP/3: Bei den meisten aktuellen Hostern Standard. Viele kleine Dateien laden dann parallel.
- Bibliotheken selbst ausliefern: Three.js vom eigenen Server statt von einem fremden CDN spart eine Verbindung und ist datenschutzfreundlicher.
Wie GLB-Dateien mit korrektem Typ und Cache-Zeit ausgeliefert werden, steht in GLB-Dateien in WordPress hochladen.
6. Flüssig auf schwachen Geräten.
Wenn die Seite schnell lädt, die Szene aber ruckelt, liegt das Problem in der 3D-Umsetzung:
- Pixeldichte begrenzen: Hochauflösende Smartphone-Displays haben die drei- bis vierfache Pixeldichte. Auf höchstens 2 begrenzen spart enorm Rechenleistung.
- Nur rendern, wenn sichtbar: Ist die Szene aus dem Bild gescrollt oder der Tab im Hintergrund, pausiert die Animationsschleife.
- Nur rendern, wenn sich etwas ändert: Ein Konfigurator ohne Animation muss nicht 60-mal pro Sekunde neu zeichnen.
- Weniger Draw Calls: Viele kleine Einzelobjekte zusammenfassen oder per Instancing zeichnen.
- Licht vorberechnen: Schatten in Texturen backen statt in Echtzeit.
- Page Builder entlasten: Auf Seiten mit 3D auf Animationen, Slider und Parallax-Effekte des Page Builders verzichten, die denselben Hauptthread nutzen.
Richtig messen.
PageSpeed Insights und Lighthouse messen vor allem das Laden der Seite, nicht wie flüssig eine Szene läuft. Beides muss getrennt betrachtet werden:
- Laden: PageSpeed Insights mit der mobilen Messung. Achte auf das größte sichtbare Element, Layout-Sprünge und die Zeit, in der der Hauptthread blockiert ist. Messe die Seite einmal mit und einmal ohne 3D-Inhalt, um den Anteil der Szene zu sehen.
- Laufzeit: Die Szene auf einem echten Mittelklasse-Smartphone testen, nicht nur am Entwicklerrechner. Drehen, zoomen, konfigurieren — und nach einigen Minuten fühlen, ob das Gerät warm wird.
- Echte Besucher: Die Felddaten in der Search Console zeigen, wie schnell die Seite bei echten Besuchern lädt — aussagekräftiger als eine Einzelmessung.
Checkliste.
- Three.js und Szene nur auf Seiten mit 3D geladen
- Szene startet bei Sichtbarkeit oder per Button, Bibliothek per import() nachgeladen
- Posterbild mit festen Maßen, Bereich mit fester Höhe
- 3D-Skripte von Verzögern und Zusammenfassen ausgenommen, im privaten Fenster getestet
- Schnittstellen für Konfigurator, Warenkorb und Anfragen nicht gecacht
- Texturen maximal 2K, Geometrie komprimiert, lange Cache-Zeiten
- Pixeldichte begrenzt, Rendering pausiert außerhalb des Sichtbereichs
- Auf echtem Mittelklasse-Smartphone getestet
Die Horizont-Baureise läuft eingebettet in einer WordPress-Website. Die übrigen Demos laufen als eigenständige Three.js-Anwendungen — technisch dieselbe Grundlage, die sich genauso in WordPress einbinden lässt. Die Markennamen sind überwiegend erfundene Showcases.
Nicht glauben — ausprobieren.
Alle Demos laufen live im Browser, auch auf dem Smartphone.
FAQ — 3D in WordPress schnell halten.
Warum ist meine WordPress-Seite mit 3D so langsam?
Häufige Ursachen sind, dass Three.js auf allen Seiten geladen wird, das Modell sofort beim Seitenaufruf lädt, Texturen in 4K oder 8K vorliegen oder ein Optimierungs-Plugin die 3D-Skripte verzögert oder bündelt. Ruckelt die Szene nach dem Laden, liegt das Problem in der 3D-Umsetzung selbst.
Wie lade ich 3D-Skripte nur auf bestimmten Seiten?
Bei einem eigenen Block übernimmt WordPress das über viewScriptModule automatisch. Bei Shortcodes werden die Skripte in der Shortcode-Funktion geladen. Ansonsten prüft man im Hook wp_enqueue_scripts mit has_block, has_shortcode oder einem Metafeld, ob die Seite 3D-Inhalt enthält.
Warum funktioniert meine 3D-Szene nach Aktivierung von WP Rocket oder ähnlichen Plugins nicht mehr?
Funktionen wie JavaScript verzögern oder Dateien zusammenfassen verändern Ladezeitpunkt und Reihenfolge der Skripte, womit ES-Module und Import Maps häufig nicht zurechtkommen. Die 3D-Skripte sollten über die Ausschlusslisten des Plugins ausgenommen und die Seite im privaten Fenster ohne Interaktion getestet werden.
Verschlechtert 3D die Werte in PageSpeed Insights?
Nicht zwingend. Entscheidend ist, dass die Szene verzögert startet, bis dahin ein optimiertes Posterbild mit festen Maßen zeigt und Three.js erst bei Bedarf nachgeladen wird. So bleibt der erste Seitenaufbau nahezu so schnell wie ohne 3D.
Was ist ein Posterbild bei 3D-Szenen?
Ein optimiertes Standbild der Szene, das sofort angezeigt wird, während die eigentliche 3D-Szene im Hintergrund lädt. Es sorgt dafür, dass Besucher sofort etwas sehen, und verbessert die gemessene Zeit bis zum größten sichtbaren Element.
Warum ruckelt meine 3D-Szene auf dem Smartphone?
Oft wegen ungebremster Pixeldichte hochauflösender Displays, zu vieler Einzelobjekte, Echtzeit-Schatten oder einer Animationsschleife, die auch ohne Änderung ständig neu zeichnet. Hilfreich sind eine begrenzte Pixeldichte, Instancing, vorberechnetes Licht und Rendering nur bei Sichtbarkeit oder Änderung.
Brauche ich für 3D in WordPress teures Hosting?
In der Regel nicht. Die 3D-Berechnung findet im Browser statt. Wichtig sind HTTP/2, komprimierte Auslieferung und lange Cache-Zeiten für Modelle und Texturen, was aktuelle Hoster meist bereits bieten.
Das bin ich – rechts im BildErzähl mir, was du zeigen willst.
Ich sage dir ehrlich, ob sich 3D für dein Vorhaben lohnt — und wenn nicht, was stattdessen mehr bringt.
Antwort meist innerhalb von 24 Stunden · hallo@manuelkillert.de