Eine konvertierte Seite kann genauso schnell sein wie eine von Hand erstellte – oder spürbar langsamer, abhängig von einigen Entscheidungen während und nach der Konvertierung.
Bevorzugen Sie native Widgets gegenüber HTML-Blöcken
Der mit Abstand wichtigste Faktor. Eine Seite, die in ein einziges großes HTML-Widget gelegt wird, bringt ihr gesamtes ursprüngliches Stylesheet mit – einschließlich Regeln für Elemente, die auf der Seite gar nicht vorkommen. Der Modus „Native Komponenten“ erzeugt echte Widgets, deren Styles Elementor pro Seite generiert und zwischenspeichert. Dadurch liefern Sie deutlich weniger ungenutztes CSS aus – und erhalten als Bonus eine bearbeitbare Seite.
Entscheiden Sie, was mit dem ursprünglichen Stylesheet geschehen soll
Inline-Styles beizubehalten ist während der Konvertierung nützlich, denn nur so lassen sich klassenbasierte Styles korrekt erfassen. Sobald die Widgets jedoch ihre eigenen Einstellungen tragen, ist der verbleibende CSS-Block am Seitenanfang oft überflüssig. Entfernen Sie ihn testweise und prüfen Sie das Layout – wenn sich nichts verschiebt, haben Sie gerade ein Stück Ballast gelöscht.
Bilder verdienen die größte Aufmerksamkeit
- Laden Sie echte Bilder in die Mediathek hoch, statt Data-URLs einzubetten. Ein Base64-Bild kann nicht skaliert, separat zwischengespeichert oder per Lazy Loading geladen werden und bläht das HTML der Seite selbst auf.
- Lassen Sie WordPress responsive Größen ausliefern, statt überall eine einzige große Größe zu erzwingen.
Was die Option zur Bildoptimierung tatsächlich tut
Diese Option ist enger gefasst, als der Name vermuten lässt. Wenn Sie die Grenzen kennen, erwarten Sie nichts, was sie nicht leistet.
Sie läuft nur im High-Fidelity-Modus und nur bei Base64-Datenbildern – PNG, JPEG oder WebP –, die größer als etwa 135 KB sind. Diese werden dekodiert, so verkleinert, dass ihre längste Seite höchstens 2560 px beträgt, und neu kodiert. Die Ergebnisansicht zeigt, wie viele verarbeitet wurden und wie viel eingespart wurde.
Was sie nicht tut: Sie rührt keine Bilder an, die per URL referenziert werden, denn das sind Dateien auf einem Server, die das Tool nicht umschreiben sollte. Im Modus „Native Komponenten“ läuft sie überhaupt nicht – Base64-Bilder werden dort zu beschrifteten leeren Platzhaltern, die Sie aus der Mediathek füllen können, was ohnehin das bessere Ergebnis ist.
Ehrlich zusammengefasst rettet diese Option also einen bestimmten Fall: einen High-Fidelity-Import einer Seite, deren Bilder alle inline eingebettet waren – in der Regel eine von einem KI-Tool generierte Seite. Wenn Ihre Bilder richtige URLs sind, ist die Option irrelevant, und die echte Optimierung findet dort statt, wo sie hingehört – in Ihrer Mediathek, wo WordPress responsive Größen erzeugt.
Achten Sie auf die Verschachtelungstiefe
Tief verschachtelte Container-Bäume sind nicht nur unangenehm zu bearbeiten – jede Ebene ist ein weiterer DOM-Knoten und ein weiterer Satz generierter CSS-Regeln. Zeigt die Strukturübersicht eine Tiefe von sieben oder acht, vereinfachen Sie die Quelle oder setzen Sie eine Kopierwurzel tiefer im Baum. Flachere Ausgaben sind sowohl schneller als auch leichter zu pflegen.
Schriftarten
Eine konvertierte Seite benennt die Schriftarten, die die Quelle verwendet hat. Wenn das keine Schriftarten sind, die Ihre Website bereits lädt, registrieren Sie sie entweder ordnungsgemäß oder wechseln Sie zur Website-Typografie, damit die Seite Schriftarten verwendet, die Sie bereits ausliefern. Vermeiden sollten Sie, eine zweite Schriftfamilie nur für einen importierten Abschnitt zu laden.
Verhalten nativ wieder einbauen
Skripte werden bei der Konvertierung entfernt, was sowohl für die Performance als auch für die Sicherheit gut ist. Wenn Sie Slider, Tabs oder Zähler neu aufbauen, verwenden Sie Elementors eigene Widgets, statt Skripte von Drittanbietern wieder einzufügen – sie sind bereits Teil des Pakets, das Sie laden.
Warum eine konvertierte Seite nicht automatisch aufgebläht ist
Die Sorge ist berechtigt, dass eine automatisierte Konvertierung die Seite unter Einstellungen begräbt und all diese Einstellungen zu CSS werden. Zwei Dinge verhindern das.
Erstens werden responsive Werte nur dort geschrieben, wo sie vom Desktop abweichen. Ein Container mit demselben Padding bei jeder Breite erhält einen Padding-Wert, nicht drei. Bei einer Seite mit sechzig Widgets ist das der Unterschied zwischen einem schlanken Stylesheet und einem, das zu zwei Dritteln überflüssige Regeln enthält.
Zweitens werden Wrapper, die nachweislich nichts bewirken, entfernt statt konvertiert. Jeder Container, der übrig bleibt, ist ein echtes <div> mit eigenen generierten Regeln. Das Entfernen derjenigen ohne sichtbaren Styling-Effekt beseitigt also sowohl einen DOM-Knoten als auch dessen CSS.
Was all das nicht beheben kann, ist Quell-Markup, das von Anfang an tief verschachtelt war. Der Konverter spiegelt Ihr HTML; er gestaltet es nicht neu. Eine sieben Ebenen tiefe Quelle erzeugt eine schwere Seite, egal wie sorgfältig jede Ebene behandelt wird. Deshalb ist das Vereinfachen an der Quelle mehr wert als jedes Aufräumen nach dem Import.
Messen, dann aufräumen
Testen Sie die Seite vor und nach Ihrer Aufräumrunde mit einem Geschwindigkeitstest. Die Gewinne kommen in der Regel von drei Stellen: dem Entfernen des überflüssigen Stylesheet-Blocks, dem Ersetzen überdimensionierter Bilder und dem Vereinfachen eines zu tief verschachtelten Baums. Nichts davon dauert lange, und zusammen sind sie meist für den größten Teil des Unterschieds verantwortlich.
Achten Sie auf die richtigen Kennzahlen. Das Gesamtgewicht der Seite und Largest Contentful Paint reagieren auf die Bildoptimierung. Cumulative Layout Shift reagiert darauf, dass Bilder explizite Abmessungen erhalten – ein Platzhalter, den Sie aus der Mediathek eingefügt haben, hat sie, ein Base64-Bild oft nicht. Und die Anzahl der DOM-Knoten, die die meisten Berichte anzeigen und die meisten Menschen überspringen, ist der Wert, der Ihnen sagt, ob die Verschachtelung unter Kontrolle ist.