Yes, Adobe Commerce Page Builder works on a Hyva storefront. Hyva ships a compatibility module that re-renders Page Builder content with Tailwind CSS and Alpine.js instead of Magento’s default JavaScript. Most content types render correctly out of the box. A handful that depend on jQuery widgets, such as sliders and tabs, need rewiring or a Hyva-native replacement.
That one-paragraph answer hides a set of decisions every merchant on Hyva eventually faces. Page Builder is the drag-and-drop editor your content team already knows. Hyva is the frontend that made your store fast. The two were built by different people with different priorities, and the seams show. This guide covers exactly what renders, what needs work, and when it makes sense to move off Page Builder entirely.
How Page Builder renders on a Luma store versus Hyva
On a standard Magento 2 Luma store, Page Builder saves its output as HTML with a large amount of inline styling and data attributes. The frontend then loads jQuery, Knockout, and several RequireJS modules to hydrate interactive content types like sliders and tabs. That JavaScript payload is a big part of why Luma stores struggle with Core Web Vitals.
Hyva throws out that stack. A Hyva theme has no jQuery, no Knockout, and no RequireJS. It uses Alpine.js for interactivity and native browser features wherever possible. So when Page Builder content lands on a Hyva page, none of the scripts it expects are present. Without a translation layer, an accordion would render as a stack of always-open panels and a slider would show every slide at once.
The translation layer is the Hyva Page Builder compatibility module. It parses the HTML Page Builder produced and applies Tailwind utility classes plus small Alpine components so the content looks and behaves the way the editor intended, without pulling the legacy JavaScript back in.
What renders out of the box, and what needs work
Content types split into three groups: those that work immediately, those that work after minor styling, and those that need a genuine reimplementation.
| Page Builder content type | Status on Hyva | What is involved |
|---|---|---|
| Text, headings, HTML blocks | Works | Rendered as-is, styled with Tailwind |
| Images, banners, buttons | Works | Native rendering, lazy-loading supported |
| Columns and layout rows | Works | Flexbox and grid via Tailwind classes |
| Products, product lists | Works | Uses Hyva product card templates |
| Accordions and tabs | Needs Alpine wiring | Interactivity reimplemented with Alpine directives |
| Sliders and carousels | Needs replacement | Legacy slider JS is gone; use a Hyva slider |
| Video and maps | Usually works | Depends on embed method and third-party script |
| Dynamic blocks and banners | Works | Rendered server-side |
The pattern is clear. Static content is fine. Anything that relied on a jQuery widget to move on the page needs an Alpine equivalent. The good news is that Hyva provides reference implementations for the common interactive patterns, so this is scoping work, not research work. A developer who understands Hyva can rebuild a slider content type in hours, not days. If your team is still learning the stack, budget more, and expect the same extension-adaptation questions that come up when adapting third-party Magento extensions to Hyva.
The Hyva CMS alternative, and why it exists
Adobe built Page Builder for the Luma world. It carries assumptions about the frontend that do not hold on Hyva, and its editing experience frustrates content teams: no live preview, no drafts, no version history, and a save-and-refresh loop for every change.
Hyva’s answer is Hyva CMS, part of the Hyva Commerce suite. It is a native content editor built on the same Tailwind and Alpine stack as the theme, so the content it produces needs no translation layer at all. It adds the workflow features Page Builder never had:
- Live preview across devices, store views, and languages without saving
- Drafts and scheduling, so a campaign page can be built ahead of launch
- Version history, so you can roll back a bad edit
- Components that map to your design system, so content stays on-brand
Critically, Hyva CMS does not force a hard cutover. You can enable it per page or per block. Existing Page Builder content is retained, and Hyva CMS can import that content into its editor so you build on it or replace it at your own pace. That per-block control is what makes the migration path realistic for a live store.
How to migrate Page Builder content to Hyva CMS
A content migration off Page Builder is not a single event. It is a phased rollout that lets your team keep publishing while you move. The sequence that works:
- Install and adapt. Add the Page Builder compatibility module first so every existing page renders correctly on Hyva. Nothing breaks, and you buy time.
- Audit your content. List every CMS page and block. Flag the ones using sliders, tabs, or custom widgets, because those carry the migration cost. Most stores find that ninety percent of pages are static content that moves trivially.
- Rebuild interactive content types. For each flagged pattern, build the Hyva-native version once and reuse it. A single well-built slider component covers every slider on the site.
- Enable Hyva CMS per template. Turn it on for new campaign pages first, where the workflow features pay off immediately. Leave high-traffic evergreen pages on the compatibility layer until you are ready.
- Migrate evergreen pages last. Move your homepage and top category landing pages only after the components and the team’s confidence are proven.
This order keeps revenue-generating pages stable while your team gets comfortable. It mirrors the phased discipline behind any well-run Hyva theme build: prove the pattern on low-risk surfaces, then scale it.
The performance angle nobody mentions
The reason to care about any of this is speed. Page Builder’s default output on Luma is heavy. Even on Hyva, a page stuffed with third-party embeds and oversized images will score poorly on Core Web Vitals. Moving to Hyva rendering removes the legacy JavaScript tax, but it does not fix bloated content.
The largest wins come from combining three things: the Hyva compatibility layer removing the script overhead, disciplined image handling with width and height attributes plus lazy loading, and content built from lightweight components rather than nested embeds. A Hyva storefront gives you the fast foundation. The content team decides whether that speed survives contact with the homepage. This is where broader Magento development discipline matters as much as the frontend theme.
What the compatibility module does under the hood
It helps to understand the mechanism, because it explains the failure cases. Page Builder stores content as HTML in the database, decorated with data-content-type attributes and inline styles. On Luma, a set of JavaScript initializers reads those attributes and attaches behavior after the page loads.
The Hyva compatibility module intercepts that HTML at render time. It maps each data-content-type to a Hyva template that outputs Tailwind classes for the styling and, where interactivity is needed, small Alpine.js directives instead of the Luma initializers. A tabs content type, for example, becomes a set of Alpine x-data and x-show bindings rather than a Knockout-driven widget.
This tells you where the edges are. If a content type has a clean HTML structure and a documented Hyva mapping, it renders. If a third-party extension injected a bespoke content type with its own JavaScript, the module has no mapping for it, and you get unstyled or inert output until someone writes that mapping. That is the whole compatibility story in one sentence: mapped content renders, unmapped content waits for a developer.
Common mistakes teams make
Three errors show up repeatedly on stores running Page Builder over Hyva.
The first is skipping the content audit and discovering broken sliders in production. The compatibility module handles the common types, but a store that has accumulated custom widgets over years will have surprises. Audit before you cut over, not after.
The second is treating image handling as an afterthought. Page Builder makes it easy to drop in a full-resolution hero image with no dimensions set. On a fast Hyva theme, one unsized 2 MB image can undo the Core Web Vitals gains the migration was supposed to deliver. Set width and height, use the lazy-loading support, and compress before upload.
The third is over-nesting. Content teams build deeply nested column structures inside Page Builder because the editor allows it. Each level adds markup and layout cost. Flatter content built from purpose-made components renders faster and survives redesigns better.
When to keep Page Builder versus move to Hyva CMS
Not every store needs Hyva CMS. Use this decision frame:
- Keep Page Builder on the compatibility layer if your content is mostly static, your team rarely touches CMS pages, and you are not licensing the Hyva Commerce suite. The compatibility module is enough.
- Move to Hyva CMS if content velocity is high, your marketing team is blocked by the save-and-refresh loop, or you run frequent campaigns that benefit from drafts and scheduling. The workflow gains compound quickly for busy teams.
For most mid-market merchants running frequent promotions, the editor experience is the deciding factor, not the rendering. A team that ships landing pages weekly will feel the difference in the first month.
Frequently asked questions
Does Page Builder content break when I migrate a Luma store to Hyva?
Not if you install the compatibility module. Static content renders immediately. Interactive content types like sliders and tabs need Alpine reimplementation, so audit those before you cut over. Everything else moves without changes.
Is Hyva CMS free?
Hyva CMS is part of the Hyva Commerce suite, which is a paid product separate from the free Hyva theme core. The Page Builder compatibility module is included with Hyva, so you can run Page Builder content on Hyva without buying the suite.
Can I use Page Builder and Hyva CMS at the same time?
Yes. Hyva CMS enables per page and per block, so you can run new pages on Hyva CMS while existing pages stay on Page Builder through the compatibility layer. This is the recommended migration path for a live store.
Will third-party Page Builder extensions work on Hyva?
Some commercial page builders publish Hyva-compatible versions. Others assume the Luma frontend and need adaptation. Check each extension for stated Hyva support before you rely on it, the same way you would vet any extension for a Hyva build.
Does moving off Page Builder improve site speed?
Moving to Hyva rendering removes the legacy JavaScript that Page Builder loads on Luma, which helps. But the biggest performance factor is what the content itself contains. Lightweight components and disciplined images matter more than the editor you use.
Where this fits
Page Builder on Hyva is a solvable problem with a clear phased path: adapt first, audit, rebuild the interactive pieces once, then move to Hyva CMS where the workflow earns its cost. The mistake is treating it as all-or-nothing on cutover day.
Bemeir is a Brooklyn ecommerce agency and the first US-based Hyva partner, with a deep technology partner ecosystem across the Magento and Adobe Commerce space. We build, adapt, and support Hyva storefronts, and we work across Shopify, Shopware, and BigCommerce for merchants whose needs point elsewhere. You can read more about Bemeir and how we approach frontend performance work.
External references worth reading: the Hyva CMS content documentation, the Hyva Commerce suite overview, and the public Hyva roadmap.
