On this page
My WordPress authoring stack now has a winner for new custom builds after building and revising the same page in Bricks, Etch, and pure FSE.
If I were starting a custom marketing or content site today, I would choose Etch first.
I would keep FSE plus Block MCP as the portability and governance standard. I would keep Bricks on sites where its deeper visual system already provides a concrete advantage, but I would not make it the default for new work.
That position is less tidy than naming one universal winner. It is also more useful.
The decision is about maintenance, not generation
All three stacks can create an attractive page. That is no longer a meaningful threshold.
The long-term platform has to support:
- Repeated precise edits by humans and agents.
- Reusable tokens, components, and templates.
- Safe revisions and rollback.
- Predictable plugin interoperability.
- Lean, semantic frontend output.
- A credible migration and exit path.
The benchmark used mundane edits because mundane edits are the work. Changing one headline without rewriting the document is more important than generating an impressive first draft that becomes fragile later.
Why Etch leads
Etch combined the best agent-facing interface with the best measured frontend output. The performance teardown and AI-operability analysis contain the detailed evidence.
Its Connector API mapped directly to text, movement, variable, style, and stylesheet operations. It scored 15/15 on the atomic update suite. The native page delivered a median LCP of 657 milliseconds with two requests and 25.7 KB of decoded response bodies.
It also retains WordPress block storage. That matters for portability, revisions, plugin interoperability, and fallbacks. Block MCP could already update and move tested Etch blocks; the main gap was discovering attribute-backed text.
Etch therefore sits in an attractive middle ground: more purpose-built than Core FSE, less detached from Gutenberg than a separate builder document, and significantly lighter than Bricks in this fixture.
Why FSE remains part of the standard
FSE plus Block MCP scored 8.86 against Etch’s 8.95. That is effectively a close contest, not a consolation prize.
FSE keeps the content in standard Core blocks and the design system in theme.json, templates, and theme source. Block MCP adds stable references, revisions, tree moves, and concurrency-aware saves for governed content operations.
It is the safest escape hatch because it is not merely an export format. It is WordPress’s own authoring model.
There will be sites where that matters more than Etch’s stronger visual development environment: public-interest publishing, highly controlled editorial workflows, long-lived institutional sites, or projects with low tolerance for vendor dependency.
My preferred standard is therefore not “Etch everywhere.” It is “Etch by default, FSE by design.”
Why Bricks does not become the default
Bricks remains the raw flexibility winner. Its components, classes, variables, theme styles, permissions, and element system are deep. On a site already built in Bricks, those capabilities may be worth preserving.
The benchmark also exposed costs:
- 1,356-millisecond median LCP versus 657 for Etch.
- Seven requests versus two.
- 460.6 KB of decoded response bodies versus 25.7 KB.
- No atomic move ability in the tested beta.
- A failing high-level AI preview-import route.
- Canonical page storage in Bricks post meta rather than Gutenberg
post_content.
Existing sites need different decisions
Existing FSE
The FSE-to-Etch retrofit preserved the original content hash and restored near-pixel frontend parity through a narrow legacy CSS and token bridge. Existing Core layouts remain Gutenberg content and Etch passthroughs until rebuilt.
That supports a low-risk migration sequence instead of a flag-day conversion.
Existing Bricks
Tokens, class concepts, and visual rules can be ported to Etch for faster parity. The canonical Bricks element document cannot simply become native Etch blocks. Plan a structured reconstruction of templates and components, beginning with the shared system.
The matched performance test reduced LCP by 51.5% and decoded response bodies by 94.4%. Those numbers justify investigation, not an automatic migration.
Plugin-owned Gutenberg blocks
Keep canonical product functionality in server-rendered WordPress blocks wherever practical. Etch can pass unsupported blocks through WordPress; Bricks can render them through Post Content. The AI-operability comparison explains the editing boundary, while the FSE-to-Etch experiment covers the migration path. Native builder adapters should remain optional usability layers rather than new canonical implementations.
Portability is not one feature
“Can I export it?” is too small a portability test. A platform decision has to separate page sharing, whole-site design systems, versionable artifacts, behavior without the builder, and builder-to-builder migration.
| Portability surface | FSE | Etch | Bricks |
|---|---|---|---|
| Page/content storage | Core block markup | Gutenberg storage with Etch blocks | Bricks document in post meta |
| Whole-theme export | Native Site Editor/theme ZIP | WordPress templates plus Etch project data | Global import/export inside Bricks |
| Component sharing | Patterns, plugins, and theme source | Portable JSON includes referenced styles, loops, and components | Template/component export includes dependencies |
| Remote/cloud library | Git, ZIP, pattern directory, any WP host | Plain JSON supports a custom registry; no managed cloud library proven here | Native Remote Templates between Bricks sites |
| Without the builder | Core blocks and templates remain native | A tested converter can return native Etch pages to editable Core blocks; advanced features still need mapping | Bricks output requires Bricks |
| Builder-to-builder | Best source format; complex layouts still need mapping | Core passthrough helps coexistence; native Etch structures need conversion | Strong inside Bricks; leaving requires reconstruction |
FSE has the lowest structural lock-in
The Site Editor can export the active block theme with its templates, template parts, and style settings. Theme files, theme.json, patterns, and registered blocks can live in Git and move through ordinary WordPress deployment. Core blocks remain editable without a third-party builder.
The caveat is that database-authored templates and Global Styles need an explicit export or Create Block Theme workflow to become reproducible source. Custom plugin blocks also remain dependencies even though the surrounding format is Core-native.
Etch is more portable than a traditional builder, but not builder-free
Etch authors templates into WordPress’s FSE template system and stores page content as Gutenberg blocks. Its public API can copy a block subtree into plain JSON together with the global styles, loops, and components it references; pasting remaps those dependencies to new IDs. That is a strong foundation for site-to-site sharing and a self-hosted or cloud-backed component registry.
The lock-in boundary is the etch/* block vocabulary and its style/component runtime. WordPress retaining the records is not the same as another builder understanding them. However, the reverse bridge test converted the native page into 99 editable Core blocks while preserving every text value, link, heading level, semantic wrapper, and CSS class. That makes an FSE exit practical, although complex components, dynamic loops, interactions, and exact visual parity still need dedicated mapping.
Bricks has the strongest same-builder distribution system
Bricks 2.4’s global import/export can move templates and broader design-system data, and template exports include required component definitions. Remote Templates can localize supported components and design dependencies from another configured Bricks site. For an agency standardized on Bricks, that is a mature distribution story.
It is also the clearest vendor boundary. The canonical page document lives in Bricks post meta, and another builder cannot edit it as Gutenberg content. A Bricks-to-Etch or Bricks-to-FSE migration can port tokens, class concepts, assets, content, and visual rules, but the native structure must be rebuilt.
My portability ranking is contextual: FSE wins exit portability, Bricks wins same-ecosystem distribution, and Etch offers the best middle ground. Its dependency-aware JSON supports distribution inside the Etch ecosystem, while the tested Etch-to-FSE converter shows that native pages can be recovered as editable Core blocks rather than abandoned as opaque records. A polished exporter still needs broader mappings, but the exit path is technically credible.
The remaining validation is operational rather than existential: route-level field data, real client content, and longer multi-user revision cycles. Those are normal production acceptance checks for the chosen stack—not reasons to withhold the recommendation.
The decision in one sentence
Use Etch as the leading default for new custom builds, keep FSE plus Block MCP as the durable portability standard, and require Bricks to justify itself per site.
That recommendation is a default, not dogma. Production telemetry and real client work can still overturn it, but the benchmark, migration, and exit tests are strong enough to make the decision now.
Disclosure: I may earn a commission if you purchase Etch through links in this article, at no additional cost to you.
This is the concluding essay in the WordPress AI Builder Test series. The complete comparison, performance data, AI architecture, and FSE migration experiment contain the underlying evidence.