WordPress Pagebuilder: Ja, Nein, Vielleicht?

Der größte Vorteil dabei liegt eigentlich auf der Hand. RedakteurInnen, AutorInnen oder Content-ManagerInnen können einzelne Bereiche, Seiten oder sogar ganze Websites erstellen, ohne dafür Programmierkenntnisse zu benötigen. Außerdem können so sehr schnell Unterseiten - wie zum Beispiel Landingpages - erstellt werden, ohne EntwicklerInnen anfragen zu müssen.

Die größten Nachteile sind für mich, dass diese Pagebuilder-Seiten oft deutlich langsamer sind als sauber programmierte WordPress-Themes.

Klar, kann man hier beispielsweise sinnvollem Caching und Code-Komprimierung Abhilfe schaffen, im Großen und Ganzen erreicht man aber selten die Werte, die mit einem Custom Theme erreicht werden können.

Das liegt vor allem daran, dass Pagebuilder das Layout der Seite oft mit in der Datenbank speichern. Wird eine Seite aufgerufen, müssen also nicht nur die Inhalte aus der Datenbank geholt werden, sondern auch die Layouts. Diese müssen am Server dann noch in HTML umgewandelt werden, was wiederum dauert.

Außerdem ist man auf den Pagebuilder angewiesen. Hat man sich einmal für einen Pagebuilder entschieden, kann man diesen eigentlich nicht mehr wechseln, ohne die gesamten Inhalte neu bauen zu müssen.

Zudem bieten Pagebuilder-Seiten oft nur zum Schein Flexibilität für die EndkundInnen. Damit diese nämlich wirklich gute Seiten erstellen können, benötigen sie Vorwissen zu responsiver Web-Entwicklung, zu Design und vor allem auch echt viel Einarbeitungszeit.

Ich kenne einige EntwicklerInnen und Agenturen, welche sich bei Pagebuilder-Seiten über ihre KundInnen beschweren, da diese die vermeintlich gute Referenz mit ihren eignen Seiten zerstört haben.

An dieser Stelle muss ich noch anmerken, dass sich auch auf dem Builder-Markt in letzter Zeit viel getan hat. Das Team von GREYD zum Beispiel hat eine richtig gute All-in-One WordPress Suite entwickelt, die ich auch guten Gewissens weiterempfehle. Oder ein Freelance-Kollege von mir, Patrick Zach, baut echt coole Seiten auf Basis des Elementor-Pagebuilders

Mein Ansatz: ACF flexible Fields

In meinen Web-Projekten verwende ich keine Pagebuilder. Stattdessen greife ich auf eine andere Technologie zurück: Flexible Felder. Im Großen und Ganzen sieht mein Workflow hier folgendermaßen aus:

Ich erhalte ein Design oder erarbeite gemeinsam mit einer DesignerIn ein Design für meine KundInnen. Danach definiere ich die einzelnen Sektionen, welche in diesem Design vorkommen. Diese Sektionen entwickle ich danach für das Frontend als Module, die auf allen möglichen Screensizes funktionieren.

Im Backend lege ich mittels "Advanced Custom Fields" fest, welche Felder in jedem Modul vom Kunden befüllt werden können.

Meine KundInnen können im Anschluss aus all diesen Modulen beliebig viele Seiten zusammenbauen. Die Module sind aber vordefniert. Deshalb wird in der Datenbank auch nur der Inhalt gespeichert, nicht das Layout. Das macht meine Seiten schneller.

Die Seite sind auch einfacher wartbar. Anstatt unzähliger Optionen müssen RedakteurInnen nur die offenen Felder befüllen. Alles andere ist schon umgesetzt.

Sollte sich das Design eines Moduls ändern, kann man diese Änderungen einmal im Code durchführen. Für alle weiteren Module wird diese Änderung gleich mit übernommen.

Außerdem ist man nicht auf eine Frontend-Darstellung festgelegt. Man kann diese Felder auch problemlos über eine API-Schnittstelle auslesen.

Fazit

Pagebuilder sind in der WordPress-Welt irgendwie gekommen, um zu bleiben. WordPress entwickelt ja selber gerade einen "Block-Editor" - Gutenberg.

Man kann mit Pagebuildern tolle Seiten - mit den oben genannten Vor- und Nachteilen - umsetzen. Das ist nur eben nicht mein Weg, um Websites zu erstellen