So beschleunigen Sie eine Divi-Website und verbessern ihre Core Web Vitals (Schritt für Schritt)

Divi hat den Ruf, schwergewichtig zu sein. Es lädt viel CSS und JavaScript, damit der visuelle Builder alles leisten kann, und von Haus aus schlägt sich dieses Gewicht in Ihren Core Web Vitals nieder. Die gute Nachricht: Eine Divi-Website kann trotzdem schnell sein, und Sie müssen sie dafür nicht ausschlachten.

Der Trick besteht darin, in der richtigen Reihenfolge zu optimieren und mit den Hebeln zu beginnen, die nichts kaputt machen können. Diese Safe-First-Methode bildet das Rückgrat dieses Leitfadens. Wir gehen die Reihenfolge Bilder, dann CSS, dann JavaScript durch, vom sichersten zum heikelsten, und jeder Schritt baut auf einem eigenen Leitfaden auf, in den Sie tiefer einsteigen können. Dieselbe Reihenfolge gilt für jede WordPress-Website: unser Ratgeber zum Beschleunigen von WordPress behandelt, was davor kommt, das Messen und das Finden der durchgefallenen Metrik, und dieser hier wendet sie auf Divi an.

Schritt 1: Bilder (der sicherste Hebel)

Bilder sind fast immer der größte Gewichtsposten auf einer Divi-Seite, und Divi verschärft das auf eine bestimmte Weise: Es setzt stark auf viele Bilder in voller Breite und viele CSS-Hintergrundbilder (Section- und Modul-Hintergründe).

Die sicheren Maßnahmen sind die üblichen, und keine davon kann etwas kaputt machen: Komprimieren Sie Ihre Bilder, liefern Sie sie als WebP oder AVIF aus, und liefern Sie sie in den richtigen Abmessungen statt einer riesigen, per CSS verkleinerten Datei. Laden Sie Bilder unterhalb des sichtbaren Bereichs per Lazy-Load, aber niemals das Hero-Bild ganz oben (den LCP), sonst verlangsamen Sie ihn. Und legen Sie width und height (oder ein aspect-ratio) fest, damit das Layout nicht mehr springt (CLS). Die Divi-spezifischen Ursachen für Layout-Verschiebungen finden Sie in unserem CLS-Leitfaden.

Hier ist der Divi-spezifische Haken: Hintergrundbilder von Sektionen und Modulen haben überhaupt kein srcset. Der srcset/sizes-Hebel kann sie schlicht nicht erreichen, daher kann kein Tool ihre Größe für Sie anpassen. Sie müssen diese Bilder im Vorfeld komprimieren und dimensionieren, bevor sie als Hintergründe gesetzt werden. Dieser Fall von Bildern ohne srcset wird in unserem Leitfaden zu srcset und sizes behandelt. Ein Hero als Hintergrundbild startet zudem spät, was unser Leitfaden zu Hero-Bereichen mit Hintergrundbild erklärt.

Und bei den regulären Bildern ist das sizes Attribut, das Divi und WordPress erzeugen, oft falsch, sobald ein Bild in einer Spalte oder einem Grid sitzt, was bei einem Divi-Layout meistens der Fall ist, sodass der Browser zu viel herunterlädt. Warum das passiert und wie Sie es in dreißig Sekunden in den DevTools erkennen, ist Thema desselben srcset-Leitfadens.

Schritt 2: CSS

Divi hat ein eigenes Performance-Panel (Theme Options → Performance). Aktivieren Sie Dynamic CSS: Anstatt Divis komplettes Stylesheet zu laden, lädt es nur das CSS der auf der Seite tatsächlich verwendeten Module. Das ist ein großer, sicherer Gewinn. Dynamic Module Framework und Dynamic Icons funktionieren nach demselben Prinzip und laden nur das, was eine Seite tatsächlich braucht.

Divi hat außerdem eine Critical CSS-Option. Wenn Sie bereits ein externes Critical-CSS-Tool einsetzen, verwenden Sie nicht beide gleichzeitig. Schalten Sie Divis Critical CSS aus und überlassen Sie die Aufgabe einer einzigen Engine. Zwei Engines, die um dieselbe Zuständigkeit konkurrieren, sind der Grund für inkonsistente, schwer zu debuggende Seiten. Nennen wir das die goldene Regel: eine Engine pro Zuständigkeit.

Genau hier passiert der klassische Divi-Bruch. Critical CSS und das Entfernen von ungenutztem CSS behalten nur das, was beim Laden oben auf der Seite sichtbar ist. Ihr mobiles Menü, Such-Overlay und Mega-Menü sind in diesem Moment ausgeblendet, sodass ihre Styles entfernt werden und sie geöffnet oder ungestylt erscheinen. Die dauerhafte Lösung besteht darin, diese interaktiven Regeln in einem nicht optimierbaren Block nach wp_head(), damit sie mit dem Theme mitziehen. Die vollständige Methode und die Fallstricke rund um Caches pro URL sowie mobil/Desktop finden Sie in dem Critical-CSS-Leitfaden.

Noch eine Divi-Gewohnheit: Nach einer größeren Änderung regenerieren Sie Divis statisches CSS. Ein veralteter Divi-Cache kann ein abgeschnittenes Stylesheet ausliefern, was genau wie eine kaputte Optimierung aussieht. Leeren und neu generieren, dann das tatsächliche Rendering prüfen.

Schritt 3: JavaScript (und das Divi-Menü)

Divi lädt jQuery, und auf den meisten Websites ist es das Menü, das dies erzwingt. Das Verzögern von JavaScript ist ein großer Gewinn, aber genau hier geht auch am ehesten etwas kaputt, wenn man es unvorsichtig angeht.

Der klassische Fall ist das Burger-Menü, das sich erst beim zweiten Klick öffnet. Divi hat dafür sogar eine eigene Einstellung, Defer jQuery And jQuery Migrate, und sie naiv zu aktivieren löst genau diesen Bug aus: Der erste Tap weckt nur das Laden des Skripts, statt das Menü zu öffnen.

Die Lösung, bei der das Divi-Menü erhalten bleibt, besteht darin, die gesamte Abhängigkeitskette gemeinsam von der Verzögerung auszuschließen: jQuery, jQuery Migrate und das Menü-Skript. Adressieren Sie sie über ein eindeutiges URL-Fragment (nicht über das interne Handle, das entfernt werden kann), und behalten Sie eine Document-State-Guard bei, damit das ausgeschlossene Skript ein frühes Ausführen toleriert. Tun Sie das, und das Menü reagiert wieder beim ersten Tap. Wenn Sie die Kette nicht handhaben können, lassen Sie Defer jQuery ausgeschaltet, statt ein Menü mit zwei Taps auszuliefern. Die Schritt-für-Schritt-Anleitung finden Sie in dem Burger-Menü-Leitfaden.

Sobald das Menü gelöst ist, können Sie den Rest (Slider, Lightboxen und so weiter) bedenkenlos deferren oder verzögern, das bringt den Großteil des JavaScript-Gewinns. Wenn etwas anderes nicht mehr funktioniert, hilft die Methode, um das verantwortliche Skript zu finden weiter.

Schritt 4: Die Reihenfolge und die Methode

Bringen Sie das mit der Safe-First-Methode zusammen. Aktivieren Sie zuerst alle sicheren Gewinne: Bildkomprimierung und -abmessungen, lazy-load außerhalb des Viewports (niemals den LCP), Minifizierung, Server-Komprimierung, Browser-Caching, font-display. Sie können nichts kaputt machen, daher müssen Sie sie nicht einzeln testen.

Dann messen Sie Ihre Core Web Vitals, um zu sehen, was noch übrig bleibt. Gehen Sie erst danach die zu testenden Hebel an, critical CSS und JavaScript-Verzögerung, einen nach dem anderen, und prüfen Sie nach jeder Änderung mobil UND Desktop sowie Ihre wichtigsten Abläufe (Menü, Suche, Warenkorb). Die vollständige Begründung finden Sie in dem Pillar-Artikel zu sicheren Optimierungen.

Mit Mantys Core

Zusammenfassung

• Divi kann schnell sein; optimieren Sie in der Reihenfolge Bilder, dann CSS, dann JavaScript, und beginnen Sie mit dem, was nichts kaputt machen kann.
• Bilder: komprimieren, WebP, richtige Abmessungen, lazy-load außerhalb des Viewports (niemals das Hero-Bild); Divi-Hintergrundbilder haben kein srcset, also vorgelagert dimensionieren.
• CSS: Dynamic CSS aktivieren; eine Critical-CSS-Engine behalten, nicht zwei; beim Laden versteckte Menüs und Overlays schützen; Divis statisches CSS nach größeren Änderungen regenerieren.
• JavaScript: Um das Divi-Menü bei aktivierter JS-Verzögerung zu erhalten, die gesamte jQuery-Kette per URL-Fragment mit einem Document-State-Guard ausschließen, oder Defer jQuery ausgeschaltet lassen.
• Methode: zuerst alle sicheren Gewinne, dann Core Web Vitals messen, danach die riskanten Hebel einzeln testen, mobil und Desktop.