Bricks oder Gutenberg: welche Bauweise passt zu welchem Projekt?

Beide Wege führen zu einer schnellen, sauberen WordPress-Seite. Bricks nehmen wir, wenn das Layout frei und aufwendig sein soll: viele eigene Vorlagen, Abfragen, Filter, Animationen. Gutenberg nehmen wir, wenn die Redaktion viel selbst schreibt und Seiten im vertrauten WordPress-Editor zusammenstellen soll.

Das Paket und der Preis bleiben gleich. Welche Bauweise passt, klären wir vor dem Start. Dabei zählt nicht, welches Werkzeug gerade beliebter ist, sondern wer die Seite in den nächsten Jahren pflegt und wie viel Gestaltung sie tragen muss.

Bricks und Gutenberg sind dabei keine Gegner. Bricks ist ein Theme mit eingebautem visuellem Builder. Gutenberg ist der Block-Editor, den WordPress selbst mitbringt. Ein Beitrag kann sogar beides enthalten: WordPress-Inhalt und Bricks-Daten liegen getrennt nebeneinander ^[2].

Gestaltung ohne Umweg. In Bricks entsteht ein ungewöhnliches Layout direkt im Builder. Dieselbe Idee braucht in Gutenberg oft einen eigens entwickelten Block. Je mehr Sonderfälle eine Seite hat, desto stärker wiegt das.

Abfragen und Filter. Mit dem Query Loop zeigt Bricks Beiträge, Begriffe oder eigene Inhaltstypen in jeder Form an und ergänzt sie um Filter ^[8]. Der Query-Loop-Block von WordPress listet ebenfalls Inhalte auf ^[6]. Für aufwendige Listen mit Filtern für Besucher brauchen wir dort aber eigene Entwicklung.

Bewegung ohne eigenen Code. Einblenden, Umschalten und Reaktionen auf Klicks lassen sich in Bricks als Interaktion einstellen ^[9]. In Gutenberg bauen wir das als Teil eines eigenen Blocks.

Vorlagen für alles. Header, Footer, Archive, Einzelseiten und Bedingungen liegen an einem Ort. Das hält größere Seiten übersichtlich.

Es gehört zu WordPress. Der Editor kommt mit jedem Update mit. Es gibt keinen zusätzlichen Anbieter, keine Lizenz für den Editor und einen Baustein weniger, der zur nächsten WordPress-Version passen muss.

Die Redaktion ist sofort zu Hause. Wer einen Beitrag schreiben kann, kann auch eine Seite aus unseren Blöcken zusammenstellen. Damit nichts aus dem Corporate Design fällt, begrenzen wir die Auswahl: Blöcke lassen sich sperren, Muster geben Layouts vor, theme.json legt Farben und Schriften fest ^[4][5].

Der Text bleibt WordPress-Text. Blöcke speichert WordPress als HTML mit Kommentaren. Bei statischen Blöcken steht der Text damit direkt im Inhalt und bleibt lesbar, auch ohne uns. Dynamische Blöcke speichern nur ihre Einstellungen und brauchen weiter ihren Code ^[3]. Das sagen wir offen, denn eigene Blöcke müssen bei einem Wechsel mitziehen.

Eigene Blöcke statt Baukasten. Für Kundenprojekte entwickeln wir Blöcke nach dem Corporate Design, zum Beispiel mit ACF ^[10]. Die Redaktion füllt Felder aus und sieht das Ergebnis direkt im Editor.

Ein Page Builder gilt schnell als langsam, ein Editor als schnell. Die Messdaten geben das so nicht her. Im September 2026 bestanden laut HTTP Archive 54,8 % der Bricks-Websites die Core Web Vitals am Handy, bei Websites mit dem Block-Editor waren es 52,0 %. Am Desktop steht es 62,4 zu 57,8 % ^[1].

Auch beim Gewicht liegen beide nah beieinander: Am Handy wiegt eine typische Seite 2,33 MB mit Bricks und 2,28 MB mit dem Block-Editor, davon 578 und 627 KB JavaScript ^[1]. Diese Zahlen beschreiben die Websites da draußen, nicht allein das Werkzeug. Beim Block-Editor sind das über 540.000 Websites jeder Art, bei Bricks rund 10.700. Für uns heißt das: Tempo entsteht durch sauberes Bauen, nicht durch die Wahl zwischen den beiden.