Mantys CoreSo beschleunigen Sie eine Divi-Website und verbessern ihre Core Web Vitals (Schritt für Schritt)
Die Zusammenfassung in einem Satz: Eine Divi-Website kann schnell sein, wenn Sie in der richtigen Reihenfolge optimieren, zuerst Bilder, dann CSS, dann JavaScript, und mit den Hebeln beginnen, die nichts kaputt machen können, bevor Sie die anfassen, die es können.
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.
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).
Hier kommt die Divi-spezifische Falle. Section- und Modul-Hintergrundbilder haben überhaupt kein srcset. Der srcset/sizes-Hebel kann sie schlicht nicht erreichen, also kann kein Tool sie für Sie richtig dimensionieren. Sie müssen diese vorgelagert komprimieren und dimensionieren, bevor sie als Hintergrund gesetzt werden. Dieser Fall von Bildern ohne srcset wird behandelt in unserem Leitfaden zu srcset und sizes.
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.
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
Mantys Core kann Ihre gesamte Performance-Schicht sein, Cache inklusive, oder parallel zu Ihrem bestehenden Setup laufen. Bei einer Divi-Website deckt es speziell jeden der obigen Schritte ab:
es übernimmt Critical und used-CSS Seite für Seite, und respektiert nicht optimierbare Blöcke, sodass beim Laden versteckte Menüs und Overlays ihre Styles behalten;
es misst die tatsächliche angezeigte Breite jedes Bildes, schreibt
sizesum, und generiert WebP, einschließlich der richtigen Größenanpassung, die Divis eigene Ausgabe verfehlt;es verzögert JavaScript mit Ausnahmen, die per URL-Fragment deklariert werden, und einem Document-State-Guard, sodass das Divi-Menü weiterhin beim ersten Tap reagiert;
und es trennt mobil und Desktop, sodass Sie nicht raten müssen, welcher Cache was ausliefert.
Die goldene Regel, eine Engine pro Zuständigkeit, wird für Sie umgesetzt: Sie schalten die entsprechenden Divi-Optionen aus, und Mantys übernimmt diese Aufgaben sauber, ohne dass zwei Engines gegeneinander arbeiten.
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.