Beim Start eines Website-Projekts stehen viele Entscheidungen an. Welches CMS soll es werden? Ok, WordPress, aber wie weiter? Divi, Elementor, Avada, Supertheme? Oder Gutenberg?
Wir bauen Websites ausschließlich mit Gutenberg. Der Start war etwas rumpelig. Am Anfang brauchte man viel Geduld und ohne CSS-Kenntnissen kam man oft nicht weiter. Aber inzwischen sind die Kinderkrankheiten überstanden und es macht richtig Spaß, Websites mit dem neuen Editor zu bauen.
Der alte Editor und die PageBuilder
Mit dem alten Editor konnte man keine Layouts bauen. Man konnte tricksen und sich mit Shortcodes und umgewidmeten Widgets behelfen. Aber diese Methode war kompliziert und schwer zu handhaben.
PageBuilder haben diese Lücke gefüllt. Der Editor spielt dabei praktisch keine Rolle mehr, die PageBuilder übernehmen Inhalt und Layout.
Das hat zur Folge, dass die Trennung von Inhalt, Design und Funktion – der Grund, warum das CMS erfunden wurde – nicht mehr funktioniert. Die Idee dabei ist, dass man eine der drei Komponenten verändern kann ohne dass das die anderen beiden durcheinander bringt. Mache ich was am Inhalt, bleiben Design und Funktionen unverändert. Ändere ich was an Design oder Funktion, wird der Inhalt davon nicht beeinflusst.
PageBuilder sind eigentlich funktionelle Bausteine, die man austauschen können sollte. Aber wenn alle Inhalte fest im PageBuilder eingebacken sind, ist das nicht mehr möglich. Gleiches gilt für das Design: Auch hier übernimmt der PageBuilder das Ruder, sobald die Einstellungen zum Design direkt in den PageBuilder-Modulen passieren.
Die drei Komponenten Inhalt, Design und Funktion sind bei PageBuildern nicht mehr unabhängig voneinander. Ändere ich an einer Stelle was, beeinflusst das immer das gesamte System.
LockedIn-Effekt
Aus einem PageBuilder kann man deshalb nicht so einfach aussteigen. Passt der Pagebuilder nicht mehr, muss man die Website neu aufbauen und z.B. die Inhalte per Hand Seite für Seite rauskopieren. Das gilt für alle Fälle, ob man von PageBuilder A auf PageBuilder B umsteigen will oder ob man zu Gutenberg wechseln möchte.
Auch im Gutenberg-Umfeld ist ein Theme-Wechsel mit Arbeit verbunden. Mal eben schnell ein neues Theme aktivieren und alles ist gut, das klappt eher selten.
Aber alle Gutenberg-Blöcke funktionieren mit jedem standardkonformen Theme. Nach dem Theme-Wechsel ist alles noch da.
PageBuilder-Module dagegen funktionieren nur innerhalb eines bestimmten Produkts. Pagebuilder-Themes und -Plugins sind eigenständige, in sich geschlossene Subsysteme. Sie verwenden WordPress nur noch als technische Basis und bauen darauf ihre eigene Welt auf.
Gutenberg bringt das Layout nach Hause
Mit Gutenberg werden Layout-Funktionen ins WordPress-System integriert, die man bisher nur mit einem PageBuilder umsetzen konnte. In WordPress 5.5 kommen die Block-Patterns hinzu, das ist ein großer Schritt in Richtung Pagebuilder-Funktionalität. Thomas Weichselbaumer hat einen Artikel zu Block-Patterns geschrieben.
Ein wichtiger Aspekt dabei ist, dass Gutenberg ein fester Bestandteil von WordPress ist. Während PageBuilder-Plugins und Theme-Plugin-Pakete wie Avada oder Divi von freien Entwicklern entwickelt und gepflegt werden, wird Gutenberg vom gesamten WordPress-Ökosystem getragen.
Das ist wichtig für die Planungssicherheit. Bei kommerziellen Themes oder Plugins kann es immer sein, dass die Autoren ihr Produkt eines Tages nicht weiterführen. Bei Gutenberg besteht diese Gefahr nicht.
Wie weit Gutenberg inzwischen gekommen ist, kannst du an diesem Experiment sehen. Munir Kamal hat die Startseite von Elementor mit Gutenberg nachgebaut. Das klappte fast ausschließlich mit Bordmitteln. Und der Unterschied im HTML Output ist bemerkenswert.
Gutenberg VS Elementor – HTML Bloat
Reise in die Zukunft mit leichtem Gepäck
Gutenberg ist schlank und modern. Die HTML-Struktur ist weit weniger verschachtelt als die von einem PageBuilder. Es werden keine zusätzlichen JS-Bibliotheken geladen, das CSS für die Standard-Blocks ist klein (< 50KB).
PageBuilder-Plugins sind in der Regel auf komplexen Frameworks wie Bootstrap aufgebaut. Hier kommen schnell einige hundert Kilobyte an CSS- und Javascript-Dateien zusammen.
Das hört sich erst Mal nicht viel an, aber für die Performance-Optimierung einer Website kann das zum Problem werden.
Muss ich meinen PageBuilder jetzt wegschmeissen?
Wenn du eine Website hast, die mit einem PageBuilder gebaut ist und du damit gut zurecht kommst, kannst du damit selbstverständlich weiterarbeiten.
Wenn du deine Website neu aufbauen möchtest, ist Gutenberg eine sehr interessante Option. Du machst dich nicht abhängig von einem einzelnen Produkt und hast gleichzeitig volle Gestaltungsfreiheit.
Aber mein Pagebuilder ist gutenberg-kompatibel
Die meisten PageBuilder können mit Gutenberg irgendwie umgehen. Wobei sich die Kompatibilität in der Regel darauf beschränkt, dass der PageBuilder auch Gutenberg-Blöcke als Module integrieren kann.
Die Systematik verändert sich dadurch nicht, der PageBuilder gibt weiter die Regeln vor. Oder anders gesagt: Gutenberg kann seine Stärken im PageBuilder-Umfeld nicht wirklich ausspielen. Dafür sind die Konzepte zu verschieden.
Vergleich Gutenberg und Pagebuilder
| PageBuilder | Gutenberg |
| Verschachtelter HTML-Output | Schlanker HTML-Output |
| Bringen komplexe CSS- und JS-Bibliotheken mit | Kein zusätzliches Javascript; CSS wiegt <50 KB |
| Funktionen, die man nicht braucht, lassen sich nicht deaktivieren, neue nicht ohne Weiteres ergänzen | Man setzt nur die Blöcke ein, die man braucht; individuelle Blöcke lassen sich beliebig ergänzen |
| Eigene technische Systematik | Standardkonforme WordPress-Systematik |
| Betreut von freien Entwickler-Teams | Betreut von den WordPress-Core-Entwicklern |
| Pro-Versionen mit Abo-Modell | In WordPress integriert (kostenlos) |
Kommentare
•
„Aus einem PageBuilder kann man nicht so einfach aussteigen. Man muss die Website neu aufbauen und z.B. die Inhalte per Hand Seite für Seite rauskopieren. Das gilt für alle Fälle, ob man von PageBuilder A auf PageBuilder B umsteigen will oder ob man zu Gutenberg wechseln möchte.“
Das ist auch der Grund, weshalb in den letzten Jahren die headless CMS einen solchen Schub bekommen haben. Dort ist eine klare Trennung von Content-Management und Präsentation. Das vereinfacht nicht nur den Wechsel von PageBuilder A zu PageBuilder B, sondern macht es auch viel einfacher, Content auf den unterschiedlichen Kanälen (E-Mail, Webseite, Social-Media) auszuspielen.
•
Danke für den Artikel zur richtigen Zeit: ich habe Arbeiten mit einigen Themes hinter mir. Und bin oft frustriert, wenn die Entwickler keine Lust mehr haben, das Theme weiter zu treiben. Vor allem die Builder, die einem den erleichterten Einstieg bringen, haben es in sich, wenn man weiter kommen möchte: schlechte Info zu Neuerungen, unkommentierte Bugs, Beschränkungen in der Responsiveness, proprietäre Eigenheiten, die brutal nervig werden können, schlechte Übersetzung… Wir arbeiten an einem neuen Projekt, das der Kunde dann selbständig mit Inhalten ergänzen möchte. Ich neige im Moment stark dazu, es von Beginn weg mit dem Block Editor zu versuchen. Da ist viel gegangen in letzter Zeit, und man darf auf mehr hoffen. Und annehmen, dass WordPress sich da keine Blösse geben und das Teil irgendwie hängen lassen wird.
•
Also ich glaube, dass der Gutenberg Block Editor jetzt schon besser ist, denn auch wenn Designoptionen vielleicht noch nicht perfekt sind, ist es das Problem von Updates und der Schnelligkeitsverlust nicht wert, einen anderen Page Builder zu nutzen. In Zusammenhang mit schlanken Themes, bietet der Gutenberg Editor jetzt schon alles, was man für schöne, schnelle Designs braucht