Neulich versetzte mich die WordPress-Webseite eines guten Freundes in einen Zustand von Verzweiflung und Frustration. Wie das? Auf ihr war der Page Builder WPBakery installiert. Im ersten Moment wollte ich offen sein, mich trotz böser Vorahnungen darauf einlassen.
Doch der gute Wille hielt nicht lange an. Wenn du auch eine Webseite hast, auf der WPBakery läuft, dann lies weiter und teil mit mir mein Leid. 😉
Historie von WPBakery/Visual Composer
Bis zu diesem Zeitpunkt hatte ich tatsächlich noch gar keine Erfahrung mit dem Page Builder WPBakery. Jedoch habe ich meine ersten Schritte auf WordPress 2013 mit Visual Composer gemacht.
Visual Composer und WPBakery werden heute zwar von unterschiedlichen Firmen entwickelt, aber sie teilen sich die Abstammung.
Gemäß der Erklärung von Visual Composer hieß der “WPBakery Page Builder” früher “Visual Composer Page Builder” – welches wohl eben jenes Produkt war, mit dem ich meine ersten Design-Experimente auf WordPress getätigt habe.
Visual Composer wurde dann im Jahr 2018 als neues Produkt neu veröffentlicht. Es ist kein Wunder, dass diese Vorgehensweise zu Verwirrung geführt hat, die bis heute anhält. Ich bin auf einige Videos (wie dieses hier) gestossen, in dem die Creator resigniert abwinken.
Damals im 2014 aber unterhielt ich die Webseite meines damaligen Arbeitgebers. Noch immer habe ich vor Augen, wie viel Rechenleistung Visual Composer dem Server abzuverlangen schien: Drag’n Drop in einem Schneckentempo, dass man sich dazwischen nen Kaffee holen konnte.
Diese Menge an Reibungsverlust reicht aus, um mich fortan einen riesen Bogen um WPBakery und Visual Composer machen zu lassen.
Wann immer ich auf neuere Reviews stieß, schienen diese meine Haltung zu diesen beiden Proukten zu bestätigen.
Warum wird das Produkt so häufig erworben?
Viele Agenturen verkaufen unterdessen Webseiten, die auf einem gekauften WordPress-Theme anstatt einem maßgeschneiderten, von Grund auf programmierten basieren. Für Firmen mit kleinem Budget ergibt das auch durchaus Sinn. Besonders angesichts der schieren Anzahl an Themes, die man kaufen kann.
Aber auch WordPress-versierte PrivatanwenderInnen sind Zielgruppe jener Themes.
Und diese kommen gerne einerseits als “kompatibel mit” deklariert.
Und anderseits sogar auch viel zu häufig im Bundle mit WPBakery.
Besonders neue WordPress-AnwenderInnen, die sich dann an des Tool gewöhnen, halten WPBakery wohl entweder für einen untrennbaren Teil von WordPress, oder sie wagen es nicht, andere Page Builder auszuprobieren. Schließlich sind wir Gewohnheitstiere und außerdem ist Zeit Geld.
So kommt es, dass WPBakery noch immer auf zahlreichen Webseiten Content Creators quält.
Backend- und Frontend-Editor
Im Gegensatz zu anderen modernen Page Buildern hat WPBakery auch einen Backend-Editor, der lediglich eine abstrakte Version der Seite darstellt.
Besonders bei vielen Elementen und einer sehr hohen Seite ist es unheimlich leicht, die Übersicht zu verlieren.
Der Workflow im Backend-Editor resultiert so schlicht in einer Zumutung.
Der Frontend-Editor ist geringfügig besser: Man sieht wenigstens, was man tut.
Die Schaltflächen für den Wechsel von Kolumne zu Section und zurück sind leider jeweils eine Zielübung, da sie nahe beieinander liegen.
Ist man ein wenig fortgeschrittener unterwegs und will eine CSS-Klasse hinzufügen, muss man sich dafür zum letzten Tab einer Kolumne klicken, um das Feld dafür zu finden.
Solche für mich nicht nachvollziehbaren Entscheide trüben das Erlebnis mit dem Pagebuilder für mich sehr: Das Geschwindigkeitsproblem des Editors ist seit 2014 behoben worden. Spass macht es mir aber immer noch nicht, mit WPBakery zu arbeiten.
Shortcode-Reste bei Deaktivierung
Für WordPress-Seiten macht es keinen grossen Unterschied, ob man einen Shortcode–basierten Pagebuilder verwendet oder nicht: Wenn man den Pagebuilder entfernen will, dann hat man in beiden Fällen Arbeit: Entweder man muss die Seiteninhalte vom Shortcode befreien.
Oder der Seiteninhalt verschwindet mit dem Plugin gleich mit und man muss ihn von Grund auf neu einfügen.
Zugegeben, Seiteninhalte ohne Pagebuilder zu erstellen ist nicht praktikabel. Daher führt hier kaum ein Weg am zusätzlichen Aufwand vorbei.
Jedoch gibt es in WordPress ja nicht nur Seiten, sondern auch Beiträge. Und da sieht es schon anders aus.
Beiträge sollten im WordPress-eigenen Editor “Gutenberg” erstellt werden und dann dynamisch in einem Single-Beitrag-Template geladen werden. Auf diese Weise sind wenigstens die “unversehrt”, sollte man den Pagebuilder jemals los werden wollen.
Jedoch wird mit WPBakery der User oder die Userin dazu verführt, auch Beiträge mit dem Pagebuilder zu erstellen. So fand ich auch auf der Seite meines Freundes etliche Beiträge, die in WPBakery verfasst worden sind.
Geschwindigkeit der Seite im Frontend
Ich habe mit der Seite schließlich standardmässig Speed-Tests durchgeführt. Einerseits mit Gtmetrix, um die Ladestruktur zu analysieren. Nachfolgend die Resultate:
Und anderseits mit dem Google Speed Test:
Für jene, die das nicht wissen: Man installiert in der Regel ein Caching-Plugin, welches die Geschwindigkeit bereits erheblich verbessern kann, in dem die Webseite beim ersten Besuch lokal auf dem Computer der User gespeichert wird. Auf diese Weise kann die Seite beim nächsten Besuch schneller geladen werden. Ein solches Plugin (namens LiteSpeed Cache) war bei diesem Test bereits installiert und aktiv. Auch habe ich die Ausgabe der Bilder in komprimierten Formaten, aktiviert.
Ich habe meinem Freund vorgeschlagen, seine Seite mit einem meiner Lieblings-Pagebuilder nachzubauen: Bricks Builder.
Ohne Optimierungen erzielt die optisch identische Webseite nun die folgenden Resultate auf Gtmetrix:
Und auf Google Speed Test:
Warum Agenturen WPBakery für ihre Kunden und Kundinnen verwenden
Mein Freund hat seine Seite von einer Agentur erstellen lassen. Wenn WPBakery so schlecht ist, dann sollten die doch Bescheid wissen darüber?
Ich kann nur spekulieren, was diese sich dabei dachten.
Der Pagebuilder kommt mit dem Theme
Annahme
Wenn der Pagebuilder, wie in diesem Fall beim Theme Uncode, schon dabei ist, dann kann die Agentur den Webseiten-Preis an dieser Rechnungs-Position ein wenig konkurrenzfähiger sein, als eine Agentur, die noch eine Pagebuilder-Lizenz in Rechnung stellt.
Konter
In der Theorie spricht hier nichts dagegen. Die Erfahrung zeigt jedoch, dass das eine sehr bequeme Marketingstrategie seitens WPBakery ist, um qualitativ nicht mithalten zu müssen. Kein anderer Pagebuilder könnte sich ohne diese Deals mit den Themes leisten, was WPBakery sich qualitativ erlaubt. Kein Developer würde sich WPBakery antun, bloß damit seine Kunden Texte und Bilder umherschieben können. Die Opportunitätskosten, die WPBakery längerfristig generiert, übertreffen meiner Meinung nach die eingesparten 56$ um Längen.
Elementor ist weniger schnell
Annahme
Elementor Pro ist der wohl benutzerfreundlichste Pagebuilder und aufgrunddessen einer der populärsten. Jedoch ist er berüchtigt für seinen “bloated” code; zu viel Code, der die Webseitengeschwindigkeit im Frontend negativ beeinträchtigt. Möglicherweise war das für die ehemalige Agentur meines Freundes ein Grund, der in die Entscheidung für WPBakery mit rein spielte.
Konter
Mit einer unzureichenden Ladegeschwindigkeit der Webseite muss man sich auch mit einem trägen Pagebuilder nicht zwingend abfinden. Es gibt diverse “Schräubchen”, an denen man drehen kann, um sich einem optimalen Ergebnis zu nähern. Jedoch ist WPBakery in solchem Maße klobig, dass sich das meiner Meinung nach weniger lohnt, als ein wenig mehr Zeit in die Optimierung von Elementor zu stecken und dafür von dessen Benutzererlebnis zu profitieren.
Bessere Pagebuilder
Aber letztendlich bin ich ohnehin verwöhnt: Wenn es Pagebuilder gibt, die einen solche sauberen Code liefern, dass man weniger schräubchendrehen muss, dann wiegt das sehr schwer bei meinen Abwägungen.
Meine bevorzugten Pagebuilder für die Erstellung von Webseiten sind darum die folgenden:
Oxygen Builder
Ganz ehrlich: Oxygen Builder von Soflyy hat eine steile Lernkurve. Es gibt allerdings unterdessen zahlreiche Tutorials auf YouTube und eine Community auf Facebook, in der man jederzeit Unterstützung findet. Der Oxygen Builder wird gerne mit Webflow verglichen.
Das Oxygen-Team stellt auch eine Sandbox bereit, in der man den Builder testen kann: https://oxygenbuilder.com/try/
Preise:
einmalig 129 $ für 1 Webseite
einmalig 149 $ für unlimitiert viele Webseiten
Vorteile
- sauberer Code, somit gute Voraussetzungen für top Ladegeschwindigkeit
- designtechnisch alles ohne Einschränkungen möglich
- Benutzt Entwickler-Technologie, was wiederum das Verständnis für HTML und CSS stark fördert
- Lifetime-Deals
Nachteile
- Um das Potential von Oxygen voll auszuschöpfen, sind HTML, CSS und JS-Kenntnisse Voraussetzung
- Die Kombination von Oxygen Builder, des Woocommerce-Plugin und dem Überetzungsplugin Polylang generiert zur Zeit leider noch ein Plugin-Konflikt
Breakdance
Das neuste Baby aus dem Hause Soflyy, welches auf die Zielgruppe von Elementor abzielt. Also soll Breakdance benutzerfreundlich und massentauglich sein.
Ich habe den Pagebuilder noch nicht getestet, jedoch bin ich zuversichtlich, dass das Team von Soflyy auch Breakdance mit einem sauberen Code programmieren wird und eine damit erstellte Website auch leicht für eine gute Ladegeschwindigkeit optimiert werden kann.
Zum Zeitpunkt des 24.07.2022 ist Breakdance noch in der Beta-Version. Der Preis steht noch nicht fest.
Bricks Builder
Der Bricks Builder hat erst Jahrgang 2021. Dafür dass er so jung ist, hat er bereits eine erstaunliche Entwicklung hinter sich. Im Gegensatz zu Oxygen Builder und Breakdance ist Bricks Builder kein Plugin, sondern ein Theme. Das kann allerdings ein Vorteil sein: Ein perfektes Zusammenspiel zwischen Pagebuilder und Theme ist somit garantiert. Und da man mit Bricks das komplette Theme bauen kann, erübrigt sich ohnehin die Notwendigkeit eines anderen Themes.
Preise:
Einmalig 79 $ für 1 Webseite
Einmalig 199 $ für unlimitierte Anzahl Webseiten
Vorteile
- Sauberer Code, somit beste Voraussetzungen für Speed-Optimierung
- Direkte Wechsel zwischen den Editor-Bereichen möglich (Beispielsweise von “Home” zu “Header”)
- Allgemein schnelle Ladezeit von Editor
- Entwicklungs-Team arbeitet sehr schnell an neuen Features
- unschlagbarer Liftetime-Deal
Nachteile
- Entwicklung hinkt zur Zeit noch den anderen Pagebuildern hinterher und hat noch weniger features (noch!)
- Funktionen in den einzelnen Elementen sind zum Teil ziemlich ineinander verschachtelt und darum manchmal leicht übersehbar (Kritik auf hohem Niveau)
Was ist mit Visual Composer?
Diese Frage kann ich leider nicht beantworten. Ich habe auch den neuen Visual Composer nie mehr ausprobiert, da es dafür keinen Anlass gab. Von den Features her scheint er aber deutlich besser zu sein, als WPBakery siehe auch Features Vergleich auf: https://visualcomposer.com/visual-composer-vs-wpbakery-review
SEO-Wrap up
Ladegeschwindigkeit ist ein wesentlicher Faktor, wenn es um eure Website-Health, also um eure Webseiten-Gesundheit geht. Diese ist elementar für eure technische SEO-Optimierung. Somit appeliere an euch, wenn ihr eine Website auf WordPress kaufen oder selber machen wollt: Verzichtet auf WPBakery oder verhindert, dass jemand anderes eure Website auf WPBakery baut.
Falls euch jedes die Ladegeschwindigkeit egal ist und ihr einfach etwas besonders benutzerfreundliches wollt, wählt in diesem Fall Elementor Pro. Selbst wenn Elementor Pro pro Website 49 $ jährlich kostet: Eure Nerven werden es euch danken.
Hast du auch WPBakery und ärgerst dich nur darüber? Kontaktier mich!
