Maja Benke
Bernhard Kau
In unserer ersten „richtigen“ Folge, möchten wir uns dem spannenden Thema Page Builder widmen.
Die Meinungen gehen hier weit auseinander. Manche lieben sie, manche verteufeln sie. Auch wir haben eine etwas zwiespältige Meinung zu Page Buildern und wollen euch daher unsere Ansichten mitteilen und ein paar Tipps geben, was beim Einsatz von Page Buildern zu beachten ist.
Shownotes:
Das Thema Page Builder in anderen Podcasts:
- PressWerk: PW007 – Pagebuilder
- WP Sofa: WordPress Page builder – Die Qual der Wahl (Folge 17)
Themes und Plugins:
- Divi Theme
- Divi Builder (Plugin)
- Enfold Theme
- Visual Composer (Plugin)
- Avia Builder Plugin (gibt es anscheinend doch noch nicht eigenständig)
- Elmastudio (Minimalistische WordPress-Themes, die auf Page Builder verzichten)
Artikel mit ausführlichem Test von Page Buildern:
Danke für den Beitrag!
Wir haben in einer kleinen Agentur gute Erfahrungen mit der Kombination Elementor als Page-Builder mit einem schlanken, aber gut anpassbaren Theme gemacht (in unserem Fall GeneratePress). Da ich da aber nur „aushelfe“ und keine jahrzehntelange WP-Erfahrung habe, kann ich das nicht mit anderen vergleichen.
Da unsere Kunden meist aus dem richtigen (=analogen) Leben stammen und einfach nur ihre Texte regelmäßig aktualisieren wollen, wird folgende Variante gut angenommen:
– das Layout der Seiten wird von uns per Elementor und Platzhalter-Texten eingerichtet und abgestimmt,
– der Page-Builder wird den Kunden über ihre Benutzerrolle „weggenommen“
– die variablen Texte werden vom Kunden im Backend über Custom-Fields (ACF-Plugin) eingepflegt
– und ersetzen dann per Hook die Platzhalter. (oder mit einem post-type spezifischen Elementor-Template, was aber Geld kostet..)
Das ist, da immer wiederkehrend, leicht implementiert und die Daten sind im Falle eines Falles leicht abzugreifen und weiterzuverarbeiten.
Und der sehr, sehr alte Software-Entwickler in mir ist auch beruhigt (Trennung von Layout und Content und so)
Danke für deinen interessanten Kommentar Werner!
Du verwendest also Elementor nur als Baukasten, um Page-templates zu bauen und der Nutzer verwendet dann ausschließlich ACF Felder zur Pflege der Inhalte? Das wäre wirklich ein interessanter Ansatz, wenn man schnell etwas bauen möchte.
Wenn man dem Page Builder wirklich einfach dem Nutzer „wegnehmen“ kann, es aber dennoch zu keinerlei Problemen führt, dann muss ich mir den auch mal ansehen 🙂 Eine Frage noch: Verwendest du die kostenlose oder die PRO Variante?
Die zusätzlichen Features der Pro-Variante brauchen wir in ca. der Hälfte der Fälle; da die Agentur eine ‚unlimited‘ Pro-Lizenz einsetzen kann, nehmen wir die auch her, obwohl es für die meisten Komponenten freie Alternativen gibt.
Zusätzlich kann auch alles andere was einen Shortcode oder ein Standard-Widget anbietet eingebaut werden.
Nur für die Variante „Standard-Elementor-Templates für Post Types“ kenn ich nur das Bezahl-Plugin anywhereElementor Pro.
PS.
Auf ‚keinerlei Probleme‘ lass ich mich nicht festnageln 🙂
Hallo ihr beiden! 🙂
Ich habe sowohl privat als auch beruflich Erfahrungen mit dem Divi-Builder, Enfold/Avia und Visual Composer gemacht. Meine grundsätzliche Meinung habe ich auch bereits im Oktober vergangenen Jahres niedergeschrieben:
https://www.pascalprohl.de/blog/visual-composer-nachteile/
Für mich persönlich überwiegen letztendlich die Nachteile. Page-Builder blähen den Quelltext auf, sorgen für längere Ladezeiten, binden unnötige Funktionen/Skripte ein und verleiten unbedarfte Nutzer dazu, eine Seite zu überfrachten. Und wenn man dann mal das Theme ändert, bei denen die Page-Builder-Inhalte eben nicht übernommen werden, ist der einstige Geschwindigkeitsvorteil bei der Erstellung der Website wieder dahin. Ich verzichte deshalb bei eigenen Projekten auf die Verwendung dieser Tools.
Gleichzeitig habe ich mittlerweile aber auch an mehreren bereits bestehenden Websites ohne bekannten Page-Builder gearbeitet, bei denen der jeweilige Entwickler des individuellen Themes die Verwaltung der Inhalte unzähliger Unterseiten über ACF und Co integrierte. Das war dann letztendlich aber wirklich so umständlich und unübersichtlich gemacht, dass ich mir dann doch wieder schnell den ungeliebten Page-Builder wünschte. Ich musste mich hier durch unzählige Menüs und Einstellungsseiten klicken, um Felder zu finden, die ich bearbeiten wollte.
Wenn man es aus Sicht eines Dienstleisters sieht, der nachträglich die Verwaltung einer Website übernimmt, kann also ein Page-Builder durchaus einen Vorteil bringen. Die Einarbeitung entfällt – man weiß eben, wie man welche Inhalte schnell verändern kann.
Auch wenn sich die Verwaltung der Inhalte ohne Page-Builder sicherlich auch einfacher gestalten lässt als ich es bisher erlebt habe. 😀
Beste Grüße,
Pascal
Danke für deinen Kommentar Pascal,
für mich als Entwickler überwiegen bei Page Buildern auch eher die Nachteile, daher habe ich sie auch nicht aktiv eingesetzt. Selbst ACF habe ich erst vor kurzem in Projekten verwendet, weil mir auch hier die Verzahnung mit Themes nicht wirklich gefällt. Aber in manchen Projekten, gerade wenn Zeit/Budget sehr klein sind, ist eine schnelle und vielleicht vorübergehende Lösung, die nicht ganz so nutzfreundlich ist, wichtiger als eine ordentliche Umsetzung ohne solche Tool.
Hallo, Ihr beiden!
Als ich den Titel Eurer ersten Folge gelesen hatte, wusste ich im Prinzip schon, was kommt. Ich schicke gleich vorweg: Es ist zwar nicht so schlimm, wie es oft in der deutschsprachigen Community gegenüber Page Buildern abgeht. Aber es tendiert dann doch in die Richtung.
Verallgemeinert und überspitzt gefragt: Warum mündet eine Diskussion über Page Builder meistens in einer letztendlich undifferenzierten und pauschalen Kritik? Gerade in der deutschsprachigen Community ist das gegenüber Page Buildern sehr auffallend.
Es gibt eine ganze Menge an Page Buildern auf dem Markt. Darunter sind solche, die Probleme haben und machen. Doch es gibt Page Builder, die haben und machen diese Probleme eben nicht.
Die Probleme und Schwierigkeiten, über die Ihr hier sprecht, habt Ihr bei zwei spezifischen Page Buildern festgestellt, mit denen Ihr Euch auskennt: Enfold und Divi (hier und da wird auch noch der Visual Composer erwähnt). Dann passiert es Euch leider viel zu häufig, dass Ihr anfangt zu pauschalisieren, also Probleme, die Ihr bei Enfold oder Divi festgestellt habt, auf alle anderen pauschal übertragt, indem Ihr plötzlich nicht mehr explizit und spezifisch von Problemen mit Enfold oder Divi, sondern über „die“ Page Builder verallgemeinernd sprecht. Das finde ich echt schade!
Werner hatte in einem Kommentar zuvor schon den Elementor Page Builder angesprochen. Aus eigener Erfahrung mit dem Elementor kann ich sagen, dass er einer jener Page Builder ist, der die viele Probleme, die Ihr ansprecht, schlicht nicht hat bzw. macht. Ein weiterer Page Builder, der hier auch aus eigener Erfahrung positiv zu erwähnen wäre, ist der Beaver Builder.
Bei beiden hat man weder das angesprochene „Lock(ed) In“ Problem, noch irgendwelche Performanceprobleme. Elementor und Beaver Builder trennen strikt zwischen Content und den Layoutanweisungen und wenn man sie abschaltet, ist der Content (auch Text und Bilder, die man mit dem Page Builder erstellt bzw. eingefügt hatte) noch da. Auch das berühmt-berüchtigte Shortcode-Massaker eines Visual Composer oder Divi bleibt einem erspart. Der Beaver Builder kommt sogar mit einer eigenen Funktion daher, auch den letzten Rest seiner Layoutanweisungen mit einem Klick zu entfernen.
Performanceprobleme hat man in der Regel aufgrund anderer Umstände, nicht, weil man einen Page Builder einsetzt. Zum Beispiel, wenn man zu große Bilder verwendet oder viel mit Slider-Elementen (und insofern mit Scripts, die extra geladen werden müssen) etc. arbeitet. Oder auch, wenn man die Seite(n) mit viel „Pling Pling“ und „Gedöns“ überlädt. Insofern stimme ich Maja zu: Ein Page Builder kann das fehlende Gespür und Auge für Layout und Design nicht ersetzen. Jetzt kommen wir aber zu entscheidenden Punkt: Das alles ist letztendlich kein grundsätzliches Problem von Page Buildern, sondern hier sitzt die Ursache der Probleme allzu oft zwischen den Ohren derjenigen, die vor dem Bildschirm sitzen 😉
Dann noch eine Sache, die mir aufgefallen ist und die regelmäßig beim Reden über Page Builder zu beobachten ist: die zumindest implizite Hochnäsigkeit von fach- und sachkundigen Entwicklern gegenüber dem Otto-Normal-Anwender oder dem Kunden, der ja keine oder zu wenig Ahnung hat und oft alles falsch macht. Ich habe ja schon erwähnt, dass es bei Euch beiden hier nicht so schlimm ist. Aber trotzdem meine ich, ein kleines bisschen dieser Erhabenheit gegenüber einem Anwender an einigen Stellen dieser Folge herausgehört zu haben.
Ich überspitze jetzt mal: Mich beschleicht manchmal das Gefühl, dass hier einer der Gründe schlummert, weshalb gerade in der deutschen Entwicklerszene die Page Builder so unbeliebt sind. Hier, wo die Trennung von Expertentum und Laien so ausgiebigst zelebriert wird, wie in fast keinem anderen Land. Klar! Würde der gemeine Anwender oder Kunde alles selbst können und auch richtig machen, hätten die Experten keine oder weniger Aufträge. Page Builder sind gefährlich für’s Geschäft. Sie versetzten den Anwender in die Lage, mit und auf seiner Homepage plötzlich Dinge tun zu können, die er ansonsten nicht umsetzen könnte, jedenfalls nicht, ohne eigene Kenntnisse in php, html und css zu haben oder halt den Experten, der es für ihn macht. Page Builder verkleinern diese zelebrierte Kluft zwischen Experten und Laien und bedrohen den Expertenstatus so mancher Entwickler.
Zum Schluss:
Der von Dir (Bernhard) erwähnte Artikel von Pippin Williamson (https://pippinsplugins.com/wordpress-page-builder-plugins-critical-review/) ist wirklich lesenswert, könnte aber wieder ein kleines Update vertragen (auch die Uhren von Page Builder Entwicklern ticken beständig weiter).
Ellen und Manuel haben ja in ihrem Interview im Presswerk (Folge PW031: https://presswerk.net/pw031/) zumindest zwischen den Zeilen angedeutet, dass sie über wohldosierte Implementierung von Page Builder Funktionalitäten bei kommenden Elmastudio-Themes nachdenken … hört, hört … Gutenberg, ick hör’ dir trapsen 😉
Und wenn wir schon beim Thema sind: Gutenberg wird hier wahrscheinlich einen immensen Impact haben, der die Stirn von so machen Nutzern wie Entwicklern (nicht zuletzt von Page Buildern) in Falten legen wird. Da bin ich echt gespannt drauf 😉
Sorry! Jetzt habe ich ziemlich »abgelästert« und vielleicht ein bisschen zu viel Frust bei Euch beiden abgeladen, wobei es – nochmals betont – bei Euch nicht so schlimm gewesen ist, wie bei so manchem Rant, den man über Page Builder hören und lesen kann.
Macht weiter so … ich freue mich schon auf die nächste Folge.
Cheers!
Vielen Dank für deinen ehrlichen und ausführlichen Kommentar Jens!
Du hsat vermutlich recht mit deiner Kritik, dass Page Builder insgesamt zu schlecht weggekommen sind. Das liegt vor allem auch an dem Frust, den wir beide jeweils damit hatten.
Ich hatte je versucht klar zu stellen, in welchen Fällen ich den Einsatz von Page Buildern durchaus positiv sehe, nämlich dann, wenn es weing Budget gibt oder wenn der Kunde sich mit einem Page Builder schon auskennt. Dennoch eliminiert das die Nachteile nicht.
Den angesprochenen Beaver Builder konnte ich mir bisher leider nur einmal kurz ansehen, hatte aber nicht genügend Erfahrung, um ihn im Podcast näher zu erläutern.
Den Gutenberg-Editor hatten wir auf dem letzten Meetup in Berlin zum Thema und werden hierzu auch eine kleine Folge machen. Dabei können wir dann gerne noch einmal auf die etwas besseren Page Builder eingehen und diese ein wenig positiver darstellen 😉
Aber wie du schon richtig bemerkst, gibt es gerade in der deutschsprachigen Community oft nur zwei extreme Lager: Pro oder Contra Page Builder. Ich bin unter anderem sehr viel in Facebook-Gruppen unterwegs und dort wird fast täglich den Einsteigern erklärt „mit Divi ist das alles kein Problem, damit kannst du alles machen, das ist das beste Theme – für alles“. Genau solche Aussagen halte ich eben für sehr gefährlich, da nur ganz selten auf die Nachteile eingegangen wird. Wenn man die als „sachkundiger Entwickler“ dann äußert, wird man nicht selten dafür angegriffen. Ich habe wir gesagt kein Problem mit Page Buildern generell und weiß, wieso sie oft verwendet werden. Mir war es aber wichtig, auch die Gefahren aufzuzeigen, die oft von vielen einfach unter den Teppich gekehrt werden, nach dem Motto „wieso soll das ein Problem sein, man ändert doch ohnehin NIE sein Theme, schon gar nicht Divi, denn es ist ja DAS BESTE, das es gibt“. OK, das ist jetzt auch wieder etwas zugespitzt und man könnte meinen, dass ich Divi per se nicht mag. Das stimmt nur dann, wenn man es Einstigern quasi aufzwingt. Für einen informiertern Nutzer können solche Themes wirklich gute Werkzeuge sein, wie es etwa Enfold für Maja ist. Unsere beider Geringschätzung für den Visual Composer liegt vermutlich auch darin begründet, dass er hauptsächlich in „Multipurpose Themes“ von ThemeForest enthalten ist, deren Qualität oft nicht überzeugt. Aber das ist Thema für eine andere Folge 🙂
Ich hoffe, ich konnte noch einmal ein wenig unsere Gründe offenlegen. Wir werden aber versuchen, in Zukunft noch etwas ausgewogener zu berichten.
Hallo Bernhard!
Vielen Dank für die rasche Antwort. Wie ich ja mehrmals betont habe: Ihr habt es ja nicht so schlimm getrieben, wie in so manch anderen Verrissen, die man über Page Builder lesen oder hören kann. Als ich Eure Folge angehört habe, ist bei mir so ein bisschen der Gaul durchgegangen und ich habe mir meinen Frust ein bisschen von der Seele geschrieben. Und ausgerechnet Euch, die es eigentlich nicht so ganz schlecht gemacht haben, trifft es … sorry, sorry, sorry!
Ich habe auch schlechte Erfahrung gemacht, gerade mit dem Visual Composer. Trotzdem würde ich ihn nicht vollends zum Teufel jagen, sondern auf die Schwierigkeiten und Probleme hinweisen, die man bekommen kann, wenn man auf ihn setzt. Vor allem ist zu unterscheiden, ob man den Visual Composer als Stand-Alone-Plugin einsetzt oder eingebunden in einem Theme. Ich habe Erfahrung mit beidem gemacht und kann nur sagen: wenn Visual Composer, dann als nur Stand-Alone-Plugin.
Du hast völlig Recht und deshalb ist Eure Folge hier wirklich nicht so schlecht bei mir angekommen, wie es nach meinem ersten Kommentar vielleicht den Anschein hat: Es ist wichtig, über die Umstände, Schwierigkeiten, Probleme und Konsequenzen aufmerksam zu machen bzw. aufzuklären, auf was man sich einlässt, wenn man auf Page Builder setzt. Aber gerade deshalb wäre hier Differenziertheit und ein bisschen weniger Verallgemeinerung so wichtig. Es gibt nämlich schlechte und gute Page Builder oder solche mit mehr und andere mit weniger Problemen. Mir geht es also gar nicht darum, grundsätzlich etwas gegen Eure durchaus sach- und fachkundige Kritik zu haben. Ganz im Gegenteil! Nur sollte man dann die Kinder beim Namen nennen (was Ihr bez. Divi, Enfold und Visual Composer ja auch getan habt), aber dann aufpassen, nicht in pauschale Verallgemeinerung zu verfallen.
Ich kann aus eigener Erfahrung den Beaver Builder und auch den Elementor sehr empfehlen, wenn man denn überhaupt einen Page Builder einsetzen möchte. Schaut Euch die mal an. Und wenn Ihr es bis zur nächsten Folge über Page Builder nicht geschafft habt, sagt einfach Bescheid. Ich stelle mich gerne zur verfügung und setze mich auf den heißen Stuhl … aber Vorsicht: ich bin „nur“ ein Anwender 😉
See ya‘
Du hast auf jeden Fall recht mit deiner Kritik, dass wir ein wenig zu verallgemeinert von Page Buildern gesprochen haben und zu wenig auf die besseren eingeganen sind. Den Beaver Builder wollte ich eigentlich erwähnt haben.
Ich stimme dir auch zu, dass der Visual Composer durchaus gut eingesetzt werden kann. Schlimm wird er oft im Zusammenspiel mit den ThemeForest Themes, die ihn einsetzen.
Sollten wir wirklich eine Fortsetzung machen, bis du natürlich herzlich eingeladen. Und dass du „nur“ Anwender bist, ist doch perfekt 🙂 Bis dahin muss ich dann nur noch die technischen Voraussetzungen für eine Aufnahme mit mehr als zwei Personen schaffen 🙂
Will mich ja nicht aufdrängen, aber mit Tipps zur Technik und Infrastruktur für Podcasts kann ich gerne aushelfen. Kenne mich da ein bisschen aus und hätte hier auch das nötige Equipment. Wie angeboten … meldet Euch einfach.
Wir hatten schon vor, auch mal Gäste dabei zu haben. Aber falls wir uns nicht zufällig auf dem WordCamp Köln treffen (Tickets sind seit 11 Uhr verfügbar), müssen wir das wohl remote machen. Und wenn du selbst Technik hast, kann ich ja vielleicht endlich mal StudioLink testen 🙂
Ja, ich würde mich auch über einen Folge-Beitrag mit Jens freuen, da ich auch glaube, dass ein PageBuilder-Beitrag ohne Blick auf die derzeit besten Produkte ein schiefes Bild abgibt.
Erster Google-Treffer zu „page builder vergleich“:
https://athemes.com/reviews/best-wordpress-page-builder-plugins-compared/
… Gerade in der deutschsprachigen Community …
Ist das so? Ein Forschungsbeitrag zum Thema „Bedenkenträgerei als Teil des deutschen Nationalcharakters“. Im Ernst: Kundenbrille aufsetzen, Chancen vor Risiken. In ein paar Jahren läuft eh eine andere Sau durchs Dorf.
.. weil mir auch hier die Verzahnung mit Themes nicht wirklich gefällt…
Das Erste, was ich mir abgewöhnt habe, als ich vor einem Jahr mit WordPress konfontiert wurde, ist die Erwartung an Verzahnung, Konsistenz, In-sich-stimmig- oder aus einem Guss sein. Muss für den Erfolg aber wohl auch nicht sein. Oder ist gerade der Grund dafür.
PS.
Performance: Hat irgendwer mal Größe/Geschwindigkeit von vergleichbaren Seiten handgemacht / mit unterschiedlichen PageBuilder mit/ohne Cache wirklich gemessen?
Also ich meinte mit der Verzahnung vor allem, dass die Page Builder in vielen Plugin nicht nur als Tool genutzt werden, sondern dass diese Themes ohne den Page Builder nicht nutzbar sind. Gerade hier ist dann ein Wechsel des Themes nur schwer möglich. Ich mag eben Themes, bei denen man sich für einen Page Builder entscheiden kann, aber nicht auf diesen angewiesen ist.
Und bezüglich der Performance muss man hier natürlich auch unterscheiden. Ein Page Builder, der mit Shortcodes arbeitet, hat hier wohl immer einen kleinen Nachteil. Aber auch ein Page Builder, der sauberes HTML produziert, dann aber viele externe CSS-Datei für die Darstellung laden muss, wird nicht schnell laufen.
Das ist wirklich ein Thema für eine andere Folge. Wir wollten auch nicht so sehr in die Tiefe gehen, sondern eben unsere persönliche Meinung zum Thema allgemein erzählen.
Studio Link wäre eine Möglichkeit und können wir sehr gerne bei dieser Gelegenheit testen 😉 Arbeitest Du also mit Reaper/Überschall? Der Notausgang wäre natürlich Skype. In Köln werden wir uns leider nicht treffen, obwohl von mir nicht allzu weit.
Ja, ich arbeite mit Ultraschall. Aktuell aber nur in der Nachbearbeitung, da ich mein Zoom H4nSP nicht ohne Brummen mit Kopfhörerverstärker am Laptop betrieben bekomme. Und da mir die Aufnahmequalität wichtiger ist, nehmen wir aktuell nur mit dem Zoom direkt auf.
Hallo Werner,
nein, ich habe bei meinem Kommentar natürlich etwas überspitzt, mit dem „typisch deutsch“ 😉
Mit Deiner Aussage: „Kundenbrille aufsetzen, Chancen vor Risiken. In ein paar Jahren läuft eh eine andere Sau durchs Dorf“ gebe ich Dir völlig Recht!
Wirklich gemessen habe ich die Performance im Vergleich nicht. Streng genommen müsste man hier noch zwischen Performance im Backend, also beim Bauen und Seitenladegeschwindigkeit im Frontend unterscheiden. Sowohl beim Elementor als auch Beaver Builder habe ich da keine merklichen (also nicht gemessen) Einbußen wahrgenommen. Voraussetzung ist natürlich alles andere, was man unabhängig vom Page Builder Einsatz in Sachen Performance beachten sollte 😉
Vielleicht zwei Artikel, die sich grundsätzlich mit dem Thema Performance beschäftigen, die ich sehr interessant finde:
– „Performance, Caching, PageSpeed: So macht man WordPress Beine“ von Frank Bültge: https://upload-magazin.de/blog/16199-wordpress-performance-caching-pagespeed/ und
– „Faster Sites: Beyond PageSpeed Insights“ von Benjamin Estes: https://moz.com/blog/faster-sites-beyond-pagespeed-insights
Beide Artikel relativieren hier so ein bisschen und holen die zum Teil gehypte Thematik wieder auf den Boden zurück.
Aber, wie würde Maja und Bernhard jetzt vielleicht sagen: das wäre ein Thema für kommende Folgen 😉