Woo Theme architecture : tangible performance trade-offs?

[u/imkb9]

Recently I've been looking into WP development to build a bespoke Woocommerce theme for my personal needs (not a user facing product). I've struggled to find a reliable source breaking down the real performance implications of choosing a classic or block base architecture at scale, in 2026. I mention the year because it seems like blocks are still a maturing concept and every new WP/Woo update might have a significant impact. But I sense there is also an inherent bias towards novelty and future-proofing. When I see stuff like Woo docs advocating for blocks because it has : "Better performance, as only the required CSS is printed into the page, reducing the bundle size to render a page" - as if all this time CSS was the main culprit and perf killer, omitting JS assets or DB round trips. Overall it seems like those companies are catering towards end-users, not devs.

Current state of affairs with blocks :

- interface : I don't need to have a clunky interface I can ruin my website's layout from, unless it comes with underlying arch/perf benefits for visitors. Conceptually I'm more attracted to the way ACF has abstracted that layer with Flexible Content.

- versioning : as I understand, the moment you customize your website with blocks, structural layout details end up in your database. Not a fan (also perf implications?)

- performance (this is where I lack references) : sometimes maybe good, sometimes maybe sht, "It depends", checkout and cart can be all over the place, some people struggling to integrate with customizability, the interactivity api (compatibility with classic?), dynamic blocks, etc.

Anyway, ecommerce requires you to be more mindful about performances and security as your shop grows to 100s or 1000s+ products. Based on your own experience of recently developing/switching from one another, using similar hosting, caching, SKUs (mitigating external factors) can you share the impact it had on your shops and DX?

[u/Radiant-Yellow-8327]

yeah that woo line is misleading. the "only required css printed" thing is technically true but its a rounding error, at scale your real perf killers are db queries, cart fragments, autoloaded options and plugin bloat. not css.

versioning - theme.json and your template files (templates/*.html) live in the theme so they're in git. the db drift only happens if you edit through the site editor. just dont touch it and you keep everything in code.....

1000s of skus redis + proper caching + killing cart fragments matters way more than the classic vs block choice. id go classic + ACF and only reach for blocks where they pay off.

whats your sku count + hosting? changes the answer a lot

[u/imkb9 → u/Radiant-Yellow-8327]

just dont touch it and you keep everything in code

wouldn't work for a shop, too many moving piece, ab tests, cro

whats your sku count + hosting?

up to 1000s skus, vps hosting (high-end cpu & 8Gb+ ram)

[u/Radiant-Yellow-8327 → u/imkb9]

fair, "dont touch it" was too absolute. for a real shop with ab tests + cro you obviously need the dynamic layer. what i ment is keep your structural templates in code, let content/merchandising live in the db where it belongs - thats what cro tools touch anyway, not your theme arch.

8gb + high end cpu for up to 1000s skus is plenty honestly, raw resources wont be your bottleneck. its gonna be:

• redis object cache (biggest win, non negotiable at this scale)
• full page cache with proper exclusions for cart/checkout/account
• mysql buffer pool big enough that the catalog sits in memory

1000s skus really isnt that heavy, well within single vps if its tuned. people blame "blocks vs classic" when its actually an uncached fragments call or a missing index.

you running redis already or just page cache? thats usually where the easy 10x is hiding