Gutenberg Block Editor

WordPress: Brauchen Sie einen Page Builder oder reicht der «Gutenberg» Block Editor?

Unsere Kunden haben die Wahl: Metoki baut Websites mit der Standard-Funktionalität von WordPress («Gutenberg» Block Editor), mit dem Divi Builder oder mit dem Bricks Builder. Diese Entscheidung hat weitreichende Konsequenzen und sollte deshalb gut überlegt sein. In diesem Artikel versuchen wir, die Vor- und Nachteile dieser drei Varianten herauszuarbeiten.

WordPress: Vom Blog-System zum Web CMS

Dass wir unsere Kunden überhaupt vor diese – zugegebenermassen nicht ganz einfache – Entscheidung stellen müssen, hat historische Gründe. WordPress wurde ursprünglich als Blog-System entwickelt, und entsprechend limitiert waren seine Layout-Möglichkeiten. Denn für ein traditionelles Blog reicht eine Hauptspalte und eine Randspalte.

Das wurde zum Problem, als WordPress im Verlaufe der letzten 20 Jahre immer häufiger als Content Management System für «normale» Websites eingesetzt wurde. Mit dem damaligen Editor (der heute als «Classic Editor» bekannt ist) konnte man nur einfache, einspaltige Layouts bewirtschaften, deren Design durch das Theme vorgegeben war. Es gab zwar viele kreative Ansätze, um diese Limitierung zu umgehen, aber keine moderne, benutzerfreundliche Lösung.

Hier sprangen die sogenannte Page Builders in die Bresche. Sie ersetzen den Classic Editor durch eine völlig neue Benutzeroberfläche, oft mit Frontend Editing und WYSIWYG. Damit können Content Managers per Drag and Drop Webseiten frei layouten und im Detail designen. Zudem bieten sie viele vorgefertigte Module (z.B. Buttons, Bildergalerien, Sliders, Akkordeons, Testimonials, Preistabellen), die man einfach im Layout platzieren und mit Inhalt befüllen kann. Dank der Page Builders – die teilweise als Plug-in, teilweise als Theme installiert werden – wurde WordPress zu einem «richtigen» Content Management System.

Risiken und Nebenwirkungen von WordPress Page Builders

Die Entwicklung von Page Builders für WordPress ist ein lukratives Geschäft. Populäre Produkte wie Elementor, Divi oder Beaver Builder erreichen eine sechs- bis siebenstellige Zahl an Installationen. Daneben buhlen aber noch Dutzende weitere Anbieter um die Gunst der WordPress Community. Das reichhaltige Angebot hat Vor- und Nachteile: Einerseits gibt es eine grosse Vielfalt und einen gesunden Wettbewerb – andererseits nutzt fast jede WordPress Website einen anderen Page Builder, so dass man die Bedienung immer wieder neu erlernen muss.

Page Builders haben zudem den generellen Nachteil, dass sie kein integraler Teil des Systems sind, sondern nachträglich aufgepfropft wurden. Das führt nicht nur zu einer uneinheitlichen Benutzeroberfläche, sondern immer wieder auch zu Kompatibilitätsproblemen zwischen Page Builder und Basissystem oder zwischen Page Builder und anderen Plug-ins.

Zudem führen Page Builders zu einem klassischen Lock-in: Hat man seinem Website einmal mit einem bestimmten Page Builder erstellt, dann gibt es keinen Weg zurück. Weder kann man zum Standard-Editor zurückkehren noch kann man auf einen anderen Page Builder wechseln, ohne die Website mehr oder weniger neu zu bauen.

Dieser Lock-in ist dann fatal, wenn ein Page Builder nicht (mehr) in Kombination mit einem wichtigen Plug-in funktioniert. Wenn man beispielsweise seine Website mit einer zweiten Sprachversion ausstatten und dazu das populäre Plug-in «WPML» nutzen will, dann ist man zwingend darauf angewiesen, dass WPML den betreffenden Page Builder unterstützt.

Wirklich dramatisch kann es werden, wenn der Page Builder nicht mehr weiterentwickelt wird. Treten dann nämlich Inkompatibilitäten oder Sicherheitslücken auf, dann muss man seine Website von Grund auf neu erstellen – unter Umständen innert kürzester Zeit.

Ein weiterer Nachteil von Page Builders betrifft die Performance. Auch wenn es Unterschiede zwischen den einzelnen Produkten gibt: Ein Page Builder macht eine WordPress Website immer langsamer. Denn einerseits erzeugen die meisten Page Builders keine besonders effizienten Code, und andererseits verleiten die üppigen Modul-Bibliotheken dazu, häufig komplexe Elemente wie Sliders, Akkordeons u.ä. einzusetzen.

Das Projekt «Gutenberg»: Ein neuer Editor für WordPress

Natürlich war auch den Entwicklern des WordPress-Basissystems bewusst, dass der ursprüngliche Editor nicht mehr zeitgemäss ist. Im Rahmen des Projekts «Gutenberg» (das insgesamt vier verschiedene Aspekte von WordPress modernisieren soll) lancierten sie deshalb 2018 einen neuen Editor, der oft als «Gutenberg Editor» bezeichnet wird, offiziell aber ganz einfach «Block Editor» heisst.

Der Block Editor bietet letztlich dieselben Vorteile wie ein Page Builder: flexible Layouts, mehr Design-Optionen und eine grosse Auswahl an vorgefertigten Modulen, die hier Blocks heissen. Im direkten Vergleich mit den etablierten Page Builders war der neue Block Editor von WordPress 5.0 allerdings ziemlich rudimentär und entsprechend unpopulär.

Seither hat sich viel getan: Nach über vier Jahren intensiver Weiterentwicklung ist der Block Editor solide und effizient. Es gibt zudem eine grosse Auswahl an Plug-ins, welche den Block Editor mit zusätzlichen Blocks oder zusätzlichen Funktionen ausstatten, sofern man diese braucht. Und in Kombination mit dem in WordPress 5.9 eingeführten Site Editor ist es sogar möglich, komplette Seiten-Templates inklusive Header und Footer nach demselben Prinzip zu erstellen (was als Full-Site Editing oder kurz FSE bezeichnet wird). Anders ausgedrückt: Dank dem Site Editor kann man ohne Programmierkenntnisse eigenen Themes erstellen und ist nicht mehr darauf angewiesen, im Theme Directory ein einigermassen passendes Theme zu finden.

Die Grundsatzfrage bei WordPress Websites: Block Editor oder Page Builder?

Wofür also sollten Sie sich entscheiden, wenn Sie eine neue Website erstellen oder in Auftrag geben? Für das Standard-WordPress mit Block Editor und Site Editor («Gutenberg») – oder für einen Page Builder wie Divi oder Bricks?

Argumente für den Block Editor

Für den Block Editor spricht, dass er ein Teil des WordPress Core (also des Basissystems) ist. Das bedeutet:

  • maximale Kompatibilität mit Plug-ins und Themes
  • gute Performance – sowohl für den Content Manager als auch für die Website-Besucher
  • grosses Angebot an Plug-ins, welche zusätzliche Blocks oder neue Funktionalitäten implementieren
  • maximale Zukunftssicherheit

Auf der andern Seite ist der Block Editor noch nicht ganz so ausgereift wie gute Page Builders – weder bezüglich Funktionsumfang noch bezüglich Benutzerfreundlichkeit. Content Management mit dem Block Editor bietet zwar viel mehr Möglichkeiten als mit dem Classic Editor, ist aber nicht immer ganz intuitiv und gelegentlich etwas hakelig. Auch bei den meisten Web-Agenturen ist der Site Editor (noch) nicht das bevorzugte Werkzeug, um Websites zu entwickeln, weil im Detail noch so einiges eher umständlich und teilweise unfertig ist.

Allerdings darf man sich darauf verlassen, dass der Block Editor auch in Zukunft intensiv weiterentwickelt und verbessert wird. Gerade mit WordPress 6.2 hat der Site Editor nochmals einen grossen Entwicklungsschritt gemacht (und ist entsprechend auch nicht mehr als «beta» gekennzeichnet). Damit bietet «Gutenberg» für viele Websites bereits alles, was man braucht. Wer diesen Weg geht, setzt auf den zukünftigen Standard und erhält ein schlankes, wartungsfreundliches System ohne Lizenzkosten.

Argumente für den Divi Builder

Divi ist das pure Gegenteil, nämlich eine ausgereifte, leistungsfähige und in sich sehr schöne Lösung – die aber dem System einiges an Ballast hinzufügt. Solange der Block Editor noch in den Kinderschuhen steckte, war Divi die naheliegende Lösung, wenn man ein modernes Content Managent System auf Basis von WordPress wollte. Deshalb hat sich ein eigenes Ökosystem rund um den Divi Builder entwickelt: Zahlreiche Entwickler bieten Plug-ins mit zusätzlichen Modulen oder fertig gestaltete Layouts an.

Inzwischen muss man sich aber tatsächlich fragen, ob Page Builders wie Divi eine Zukunft haben. Insbesondere der Einfluss auf die Performance ist nicht zu unterschätzen: Mit Divi gebaute Websites sind nach unserer Erfahrung spürbar langsamer als solche, die auf Gutenberg oder Bricks basieren. Auch die gesamte Architektur – die zwar auf WordPress basiert, aber wesentliche Systemkomponenten komplett ersetzt – ist auf Dauer keine ideale Lösung. Die Entwickler haben denn auch im letzten Herbst angekündigt, Divi in grossen Teilen neu zu entwickeln, um genau diese Probleme zu adressieren. Bisher wurden allerdings erst Alpha-Versionen für Entwickler veröffentlicht, und somit werden wir wohl erst im Verlaufe dieses Jahres sehen können, wohin die Reise mit Divi 5 geht.

Argumente für den Bricks Builder

Bricks ist ebenfalls ein Page Builder, aber in vielerlei Hinsicht ganz anders als Divi. Technisch gesehen handelt es sich zwar um ein Theme, aber wenn man es frisch installiert, hat die Website (anders als bei jedem anderen Theme) zunächst keinerlei Design. Denn Bricks ist dafür gedacht, dass man sein eigenes Design von Grund auf selbst erstellt, frei von jeglichen Vorgaben eines Theme-Entwicklers und mit allen Möglichkeiten, die HTML und CSS bieten. Im Bricks Builder baut man Webseiten ähnlich wie ein Entwickler – allerdings schreibt man keinen Code, sondern man nutzt einen komfortablen WYSIWYG-Editor mit Drag-and-Drop-Funktionalität.

Dieser Ansatz zahlt sich vor allem dann aus, wenn man etwas speziellere Designs detailgetreu implementieren möchte. Denn so bequem es ist, fixfertige Designs in Form von Themes oder Layout Packs herunterzuladen, so mühsam kann es auch sein, diese anschliessend so anzupassen, dass sie den Vorgaben eines Designers entsprechen.

Was ebenfalls für Bricks spricht, ist seine Performance: Nicht nur die Arbeit im Builder ist sehr flüssig, auch die resultierenden Websites laden ausgesprochen schnell. Wir haben kürzlich eine umfangreiche Divi Website mit Bricks neu gebaut, und der Performance-Gewinn war signifikant.

Der Bricks Builder ist also eine sehr innovative Lösung für Websites, bei denen Design und Performance gleichermassen wichtig sind. Er setzt etwas mehr Kenntnisse in HTML und CSS voraus, ist dafür aber in jeder Hinsicht hoch effizient und sehr flexibel. Für Content Managers, die nur Texte und Bilder einpflegen, gibt es eine vereinfachte Oberfläche, die nicht komplizierter ist als bei jedem anderen Editor auch.

Allerdings muss man sich bewusst sein, dass Bricks ein sehr junges Produkt ist, hinter dem lediglich zwei Entwickler stehen. Zwar haben die beiden innert kürzester Zeit eine wirklich überzeugende Lösung geschaffen, und es werden laufend neue Versionen veröffentlicht. Trotzdem fehlen noch einige Dinge, und Bricks ist noch nicht mit allen wichtigen Plug-ins vollständig kompatibel. Und ob sich Bricks ähnlich gut in der WordPress-Welt etablieren kann wie Gutenberg oder Divi, muss sich erst noch weisen.

Eine interessante Option: Block Editor und Page Builder kombinieren

Muss man sich zwingend für eine dieser Lösungen entscheiden? Nicht unbedingt: In der Praxis hat sich auch eine Kombination aus Block Editor und Page Builder bewährt. Das bedeutet, dass man gewisse Seiten im Block Editor, andere hingegen mit einem Page Builder (z.B. Divi oder Bricks) erstellt und bewirtschaftet. Da der Block Editor bei WordPress sowieso immer dabei ist, ist das technisch problemlos möglich.

Die Idee dahinter ist, dass man komplexere Seiten mit dem Page Builder baut, einfachere dagegen mit dem Block Editor. So ist man für alle Fälle gerüstet und hat zudem den direkten Vergleich zwischen den beiden Ansätzen. Als Content Manager muss man lediglich darauf achten, dass man jeweils den richtigen Editor erwischt. Und für den Website-Besucher ist nicht erkennbar, wo welcher Editor zum Einsatz kommt, d.h. die Website wirkt trotzdem aus einem Guss.

Beratungsgespräch

Dürfen wir Sie beraten?

Die technische Plattform einer Website ist ebenso wichtig wie ihr Inhalt und ihr Design. Als WordPress-Spezialist mit vielen Jahren Erfahrung beraten wir Sie gerne dabei, wie Sie dieses CMS optimal nutzen.

Vereinbaren Sie jetzt ein unverbindliches Gespräch, um uns besser kennenzulernen!