Why We Turned Page Builder Off

Page Builder gives editors a lot of freedom. On the Magento stores we have worked on, that freedom tended to bring the same three problems sooner or later: a page that looks wrong on a phone because someone dragged a block into a row it doesn’t fit, a home page that weighs more each month, and a layout shift nobody can fix because the content decides its own size.

On caruselbooks.ro, Page Builder is turned off. Editors don’t arrange blocks; they fill in fields, and the layout around those fields is written once, in PHP templates. We call the idea rigid flexibility: flexible where the content changes, rigid where the page could break.

What editors get instead

A landing page for every book

A book doesn’t sell from a cover and a price, so under the buy box each product page can carry a whole pitch. It is a set of fields in the product’s admin page, stored in a table of its own with one row per product:

• a banner above and one below, each with a desktop and a phone image, a line of text over it and a link;
• a grid of illustrations from the book, with captions;
• a fragment of the book, a page or two;
• two short lists: who the book is for, and who it isn’t for;
• reviews, with the book’s rank in its categories.

Each part appears only when its fields are filled in. A book with a single banner looks finished, not half-built, because there is no empty frame waiting for content. You can see one on this product page.

A home page made of sections

The home page is a list of sections managed in the admin, each switched on or off and placed in order. Every section has a type, and every type has its own fields: product sliders with a choice of source (new, featured, a category, a curated mix), illustrated bands, featured authors, books coming soon, a bestseller spotlight, the latest blog posts, and an editorial hero.

The hero shows how far fields can go. Editors choose a kicker, a heading, body text, two buttons, a desktop and a phone image, a background, the text colour, and a layout: image beside the text or text over the image. What they can’t do is break the alignment with the header, the spacing, or the way it stacks on a phone. Those are decided in code, once.

What we gained

Pages that don’t break. A save in the admin changes content, never structure. There is no combination of fields that produces a page we haven’t seen.

Lean HTML. No wrapper divs and inline styles for every row and column a drag-and-drop editor creates. The markup is what the template says, and nothing else.

Layout shift we can control. This one decided it for us. To keep things from jumping while a page loads, the browser must know how much room every image will take before the image arrives. With fields, the template knows exactly which images exist, so the server reads each one’s real width and height and reserves the space, including for images in auto-width grid columns, where width and height attributes alone reserve nothing. Today the product page and the home page have a Cumulative Layout Shift of 0 on desktop. Content from a free-form editor can’t be measured that way.

Images we choose the format of. Banners drawn in Illustrator are uploaded as SVG and placed in the page with the site’s own font. On upload they are cleaned of anything executable and their IDs made unique, so two banners on one page can’t clash. Photos become WebP in several widths. The editor uploads a file; the code decides how it reaches the browser.

A cache that clears itself. Each section and banner tells the full-page cache which pages it appears on. Save a banner, and the home page refreshes on its own, without anyone flushing the cache.

What it costs

It would be dishonest to stop there.

A new kind of section needs a developer. If marketing wants something no section type does yet, it waits for us. Once built, the new type is there for good, with its own fields, but the first time is development work, not a minute in the admin.

One-off pages are harder. A campaign page with a layout nobody will use again is exactly what Page Builder is good at, and exactly what fields are bad at.

Someone has to think in types. The work moves from arranging blocks to deciding, up front, what a page is made of. That is design work, and it doesn’t happen by itself.

When to keep Page Builder

If your team makes many one-off landing pages, has no developer close at hand, and can live with the performance cost, Page Builder earns its place. If your pages follow a few patterns that repeat across hundreds of products, and the store’s speed matters to your sales, fields and templates will serve you better, and the patterns are usually fewer than you’d think.

For us the answer was easy: a bookshop has thousands of product pages that should look alike, a home page that changes every week, and readers who mostly arrive on a phone. More of the story, with the numbers, is in the case study.