Block theme or page builder for a new WooCommerce store

Open the plugin list of a slow WooCommerce store and the pattern is usually the same: a page builder, a multipurpose theme with its own builder, three or four add-on packs for the builder, and a caching plugin bought to hide the cost of the first four.

A new store does not need any of it. WordPress has had a block editor since 2018 and full site editing, which means block themes, since version 5.9 in 2022. WooCommerce ships its product, cart and checkout pages as blocks. The layout tool is already installed.

TLDR

For a new WooCommerce store, build on a block theme. It renders less code, it is edited in the editor WordPress already has, and there is one less plugin family to update. A page builder still makes sense on an existing store that is built on one, or when the person editing pages daily already knows it well.

What a page builder costs

Not the license. The cost is on every page load. A page builder renders each section as several nested wrappers with inline styles, loads its own CSS and JavaScript on every page, and adds its own copy of features WordPress already has: a query loop, a grid, a button. The multipurpose theme it lives in adds a second layer of the same.

The result on a product page is a Largest Contentful Paint over the 2.5 seconds that Core Web Vitals treats as the limit, and a layout that shifts as the builder’s scripts run. A caching plugin helps the home page. It does not help the cart, the checkout or a logged-in customer’s account page, which are the pages where money changes hands, because those pages cannot be cached.

There is a second cost: updates. A builder, its add-ons and the theme each update on their own schedule, and each one is a chance for something to change under the store. More plugins is more of that.

What a block theme changes

A block theme describes the design in one file, theme.json, and builds templates from blocks. Colors, type, spacing and layout width are settings, not CSS the theme ships. WordPress generates only the styles the page uses.

{
  "version": 3,
  "settings": {
    "color": { "palette": [ { "slug": "ink", "color": "#1c2230", "name": "Ink" } ] },
    "layout": { "contentSize": "720px", "wideSize": "1160px" }
  }
}

Templates live in the site editor. The shop page, a single product, the cart and the checkout are WooCommerce blocks with their own settings. A store owner who wants to move the related products above the reviews does it in the editor, with no developer and no builder.

Fewer plugins follow from this. A block theme store we build ships with WooCommerce, a payment gateway, an SEO plugin, a form plugin if the store needs a form, and whatever the business genuinely needs. Sliders, icon packs, header builders and the rest are not installed because the blocks already do the job.

Where a page builder still wins

An existing store built on Elementor or Divi with hundreds of pages is not a candidate for a switch on a whim. The pages would be rebuilt, not converted. The right call there is usually to keep the builder, remove the add-ons nobody uses, and fix the actual bottleneck, which is often not the builder at all. Measure first. We wrote about how to find what is slowing a WooCommerce store.

The other case is the editor. If the person who updates the store every day has years in Elementor and the site editor feels foreign, the builder’s cost in speed may be worth the cost in training saved. That is a real trade and it should be made on purpose.

And a block theme is not automatically fast. A heavy multipurpose block theme with forty patterns and its own framework carries the same weight as a builder. Light and custom is the point, not the word “block”.

What the store owner edits without a developer

The practical difference shows up the week after launch. In a block theme store, the site editor under Appearance is where every template lives: the home page, the shop page, the single product template, the cart and the checkout. Each one is blocks.

Moving the reviews above the related products on the product template is a drag in the editor. Changing the number of columns on the shop page is a setting on the Product Collection block. Adding a “free shipping over $50” line under the add-to-cart button is a paragraph block in the product template.

Patterns are the other half. A pattern is a saved arrangement of blocks, a hero with an image and a heading, a three-column feature row, a testimonial band. The theme ships with the store’s own patterns, named for what they are, and a new landing page is a matter of inserting three of them and changing the words. That is the same thing a page builder sells, in the editor WordPress already has, with nothing extra loading on the front end.

The limits are real too. A layout the theme’s patterns do not have needs a developer to add a pattern, which is an hour, not a project. Animations and effects that page builders make trivial are not in the block editor, and most stores are better off without them. And the site editor has a learning curve of an afternoon for someone who knows the post editor, and a day for someone who knows Elementor and has to unlearn it.

Numbers to expect

A block theme store built the way described here, on decent hosting, tends to land in these ranges on a product page over a throttled mobile connection, measured with PageSpeed Insights before launch:

The left column is what we see when auditing existing stores, and the range is wide because it depends on the host and on how many add-ons the builder has. The right column is a target, not a promise, and the guide on measuring a slow store covers how to check it on a real page rather than the home page.

The plugin count row is the one that matters for the next three years. Every plugin is a thing that updates, a thing that can conflict, and a thing that can be abandoned by its author. Fewer of them is fewer Monday mornings spent finding out why the checkout looks different.

The build, step by step

For a new store, the order we follow:

1. Design first. A Figma file, or a design built directly in the site editor for a store with a simple brand. The design decides the patterns.
2. Write theme.json. Colors, type scale, spacing, layout widths, and which core settings the editor exposes. This is where the brand becomes settings.
3. Build the templates. Home, shop, product, category, cart, checkout, account, and the page and post templates. WooCommerce provides the store templates as blocks; the theme styles them and adds what the store needs.
4. Build the patterns. Every section the store will reuse, named and categorized so they show up in the inserter.
5. Configure WooCommerce. Payments, shipping, tax, emails. Install the plugins the store genuinely needs, and nothing else.
6. Load the products. Real ones, with real images, compressed on upload.
7. Test on a phone. Product page, cart, checkout, account, with the network throttled, against the Core Web Vitals thresholds.
8. Launch, and hand over a one-page guide to the site editor written for the person who will use it.

The theme can be exported from the site editor with the Create Block Theme plugin, which turns the templates and patterns into theme files, so the design survives a reset and lives in version control with the rest of the store.

Moving an existing builder store

A store already on a page builder is a different project, and the first step is measuring rather than migrating. Many builder stores are slow for one or two reasons that are fixable in place, and a rebuild is a store build project, from $4,500, that should be chosen because the store has outgrown the builder, not because a blog post said builders are slow.

When the rebuild is right, products, orders and customers stay where they are. The templates and pages are built again in the site editor, page by page for the ones that matter and pattern by pattern for the ones that repeat. Old builder pages can stay live during the rebuild and switch over one at a time, which is also how the store owner learns the editor before the cutover. The builder and its add-ons are deactivated at the end, and the plugin list gets shorter by a third.

How we build one

The design comes first, in Figma or in the browser. The theme is written as theme.json plus a handful of templates and patterns, and nothing else. WooCommerce templates are customized in the site editor and exported into the theme so they survive a reset. We test the product page and the checkout on a phone over a throttled connection, with the field data thresholds as the target, before the store sees a real order.

The launch checklist is short because there is less to check. Which is the whole argument.

Questions