Bricks 1.9 vs Elementor 3.x: the DOM depth tax
Same three-column hero, two builders, very different output. I rebuilt one landing page in both and counted nodes.

— Elementor wraps every column in section > container > column > widget-wrap > widget. That hero shipped 38 div nodes.
— Bricks output the same layout in 11 nodes, no forced wrappers, semantic tags you pick yourself.

Pros (Bricks): lean markup, flat DOM, faster style recalc on long pages.
Cons (Bricks): you hand-build structure, fewer guardrails, steeper first week.
Pros (Elementor): the nesting just works, huge template pool.
Cons (Elementor): div soup inflates CLS risk and CSS specificity wars.

Best for: Bricks if you read your own HTML; Elementor if speed-to-first-draft beats page weight.

Gutenberg isn't automatically lighter than a builder
The "core blocks = zero bloat" line is half true. Test it before you believe it.

— A plain post with 6 core blocks loads ~9KB of block-library CSS, deferred, fine.
— Add one third-party block pack (Kadence, Stackable, GenerateBlocks) and you're back to enqueuing a global stylesheet on every page.
— Block patterns inline a lot of utility classes; copy-paste a fancy pattern and your HTML balloons.

Pros: native, no builder lock-in, blocks render without a runtime.
Cons: third-party block libs re-introduce the exact bloat you left a builder to escape.

Best for: editorial sites that stick to core blocks plus one disciplined block library, not pattern-hoarders.

The real cost of builder lock-in: shortcode rot
Migrating off a builder isn't "export and done." I moved a 40-page site off WPBakery and measured the damage.

— Every saved row leaves [vc_row][vc_column] shortcodes baked into post_content.
— Deactivate the plugin and those shortcodes render as raw text across all 40 pages.
— Cleanup meant regex on the database, not a button.

Pros of staying: nothing breaks, content keeps rendering.
Cons of leaving: orphaned shortcodes, lost layouts, hours of find-replace.

Bricks and Gutenberg store cleaner markup, so they're cheaper to exit than shortcode-based builders.

Best for: if exit cost matters, pick a builder whose output survives without it running.

Quick rec — @EdgeOfGloryCDN keeps a tight feed on CDN (content delivery networks). If today's post landed, that one's for you.

Template libraries are technical debt you import on purpose
That 700-template kit is a feature in the sales page and a liability six months later.

— Most pro kits assume a specific builder version; update the builder and spacing drifts.
— Imported templates carry their own global colors and fonts, often duplicating yours.
— One kit I imported registered 14 extra Google Font weights I never used.

Pros: instant structure, good for pitching layout ideas fast.
Cons: font bloat, duplicate globals, version coupling, hard to audit later.

Best for: wireframing and client demos. Strip the template down to your own globals before launch, never ship a kit page as-is.

How to set a page-weight budget the builder can't blow
Builders don't bloat on their own, they bloat because nobody set a ceiling. Here's the one I use.

— CSS budget: 120KB total. If the builder's global stylesheet alone eats 80KB, you're in trouble before you start.
— JS budget: 150KB. Watch for builder "motion" and "sticky" add-ons that each load their own library.
— DOM budget: under 1,500 nodes per page (Lighthouse flags 1,500).

Pros of budgeting: forces you to disable unused widgets and global features.
Cons: some builders make per-page asset loading a paid tier.

Best for: any builder, but essential on Elementor and WPBakery where defaults run heavy.

GenerateBlocks vs Bricks: two roads to lean output
Both aim for minimal markup, but they live in different editors.

— GenerateBlocks runs inside Gutenberg, four primitives (Container, Grid, Headline, Button), near-zero runtime.
— Bricks is a full standalone builder with its own canvas and global classes.

Pros (GenerateBlocks): stays in native editor, tiny footprint, no builder lock-in.
Cons (GenerateBlocks): fewer elements, you assemble complex sections manually.
Pros (Bricks): complete builder, query loops, custom code, global class system.
Cons (Bricks): it's still a separate ecosystem to learn and maintain.

Best for: GenerateBlocks if you want lean and Gutenberg-native; Bricks if you need a full builder without the Elementor weight.

Global CSS file vs inline styles: how builders ship your design
Where a builder writes your CSS changes everything about caching.

— Elementor (default) writes per-page CSS files into uploads, cached separately, good for browser caching but messy on CDN purges.
— Bricks can output one global stylesheet plus per-page, cleaner to cache.
— Some setups dump critical styles inline in <head>, which kills caching but helps first paint.

Pros (external files): cacheable, reusable across pages.
Cons: render-blocking unless deferred, CDN purge headaches.
Pros (inline): no extra request, faster first paint.
Cons: re-downloaded every page, fattens HTML.

Best for: external cached files for content-heavy sites; inline only for single landing pages.

Elementor Pro vs Bricks: the renewal-year math
First-year price is marketing. Year two is the real number.

— Elementor Pro: yearly subscription, you lose updates and template access if you stop paying.
— Bricks: one purchase includes lifetime updates on the tiers that offer it, no annual renewal pressure.
— Across a 25-site agency over three years, the subscription model compounds fast.

Pros (Elementor): steady update cadence, big ecosystem, predictable support.
Cons (Elementor): recurring cost per year, lifetime-deal rugpull history elsewhere makes buyers cautious.
Pros (Bricks): lifetime tier, no renewal anxiety.
Cons (Bricks): smaller third-party add-on market.

Best for: Bricks for multi-site agencies counting year-two cost; Elementor if you value ecosystem over price.

The hidden JS cost of builder motion effects
That parallax scroll and entrance animation looks free in the editor. It isn't on mobile.

— Enabling Elementor Motion Effects loads its scroll-tracking JS sitewide, even on pages without animation.
— Each "sticky" element attaches a scroll listener; ten sticky widgets on one page means ten listeners firing per scroll.
— On mid-range Android, parallax forces layout recalcs that tank scroll FPS.

Pros: polished feel, good for premium-feel landing pages.
Cons: sitewide JS load, scroll jank, main-thread blocking on cheap phones.

Best for: use motion on hero sections of marketing pages only. Disable the feature globally and enable per-template, never sitewide by default.

Oxygen vs Bricks: same lineage, different bet
Bricks came from people who knew Oxygen's pain points. The contrast is instructive.

— Oxygen stores everything outside post_content, so uninstalling wipes layouts hard, brutal lock-in.
— Bricks also detaches from the classic editor but ships a cleaner data model and active update cadence.
— Oxygen pioneered lean markup; Bricks kept that and added a friendlier canvas.

Pros (Oxygen): extremely lean, full template control, lifetime license.
Cons (Oxygen): harsh exit cost, slower development pace lately.
Pros (Bricks): similar leanness, momentum, larger community.
Cons (Bricks): still a niche ecosystem vs Elementor.

Best for: Bricks over Oxygen for new builds; only stay on Oxygen if a working site already runs it.

No-code handoff: which builder survives a non-technical client
The builder you love might be the one your client breaks. I judge by handoff risk.

— Elementor: clients can edit text safely but drag a column and the layout collapses; high "oops" rate.
— Gutenberg with locked patterns: you can lock blocks so clients edit content, not structure.
— Bricks: powerful, but one wrong global-class edit cascades across the whole site.

Pros (Gutenberg locking): template_lock and block locking genuinely fence clients in.
Cons: less visual flair than a full builder.
Pros (Elementor): familiar, but needs role-based editing add-ons to be safe.

Best for: Gutenberg with locked patterns for client self-edits; full builders only when you keep editing rights.