A client handed us a site last spring that loaded 41 CSS files and 29 JavaScript files on the homepage. Total front-end payload before images: just under 2.1 MB. The theme was a well-known multipurpose one with a six-figure sales count, and the agency that built the site had used exactly one of its 90-odd demos, then overridden half of it with custom CSS. Nobody had touched a single theme option in two years.

That site is the argument against multipurpose themes in one screenshot. But here’s the part the hot takes leave out: we rebuilt it on the same theme, with asset loading trimmed and the page builder removed from three templates, and got the homepage down to 410 KB and an LCP of 1.3s on a throttled 4G profile. The theme wasn’t the problem. The way it was installed was.

So let’s have the honest version of this argument, because the listicles are useless on both sides.

What you’re actually buying

A multipurpose theme is not 200 designs. It’s one theme, one options panel, one set of custom post types or widgets, and 200 saved configurations of that machinery. The demos are JSON and SQL dumps. Understanding this changes how you evaluate the purchase.

What you get for your money, realistically: a layout system hammered by tens of thousands of installs, a header builder that handles sticky, transparent, mega menu and mobile off-canvas without you writing a line, WooCommerce templates that already work, RTL support, and a support desk that answers in a day. Building those from scratch is 80 to 150 hours of work on a good day. The theme costs the price of lunch.

What you don’t get: a content model that fits your client, markup you control, or any guarantee that the next major version won’t change how a single filter behaves. We’ve written about what it takes to ship and maintain a commercial theme, and the pressures are real. A theme author with 60,000 customers cannot break backwards compatibility, which is precisely why old code accumulates in these products.

Where the bloat actually comes from

“Multipurpose means bloated” is lazy. Here are the four sources, in order of how much damage they do.

1. Unconditional enqueuing

The single biggest offender. The theme registers its slider CSS, lightbox JS, carousel library, counters, parallax and icon fonts on wpenqueuescripts with no condition. A contact page with a heading and a form pulls down a 180 KB animation library. Good themes gate this behind a check for whether the element exists on the page. Many don’t, because detecting a shortcode inside a builder’s serialised data is genuinely hard.

2. The page builder

If the theme ships with or requires Elementor, WPBakery or a bundled builder, that builder’s CSS and JS is a floor you cannot go below. Elementor’s base stylesheet plus widget styles is typically 120 to 250 KB uncompressed before your theme adds anything. Every page, forever. If you’re reconsidering that trade, moving off a page builder to native blocks is harder than it looks but usually worth it on sites with a long life.

3. Icon fonts

Four icon font families bundled “for choice” means four font files, four @font-face blocks, and a FOIT on every page. We cover why SVG sprites beat icon fonts on almost every metric, but theme authors keep shipping Font Awesome 4, 5, 6 and a custom set side by side for backwards compatibility.

4. The demo import

Importing a demo installs 40 pages, 200 attachments, 12 custom post entries and often six bundled plugins. Nobody deletes the unused ones. Six months later the site has a wp_postmeta table with 90,000 rows and an admin that takes four seconds to load. This is self-inflicted, and it’s fixable with a proper plugin audit before launch rather than after the client complains.

The honest case for a multipurpose WordPress theme

Three situations where buying beats building, and we’d argue it’s not close.

Fixed-budget brochure sites. A ten page site for a local firm, £3,500, three week turnaround. A custom theme eats the entire budget in build time and leaves nothing for content, photography or QA. A bought theme gets you to a styled, responsive, accessible-ish baseline on day two, and you spend the remaining time on things the client can actually see.

Clients who will self-serve. If the handover involves a non-technical marketing person adding pages for the next four years, a visual editing layer is not a compromise, it’s the requirement. We’ve watched beautifully hand-built block themes rot because nobody on the client side could add a two-column section without calling us.

Prototyping and pitching. Standing up a credible, interactive version of a proposed site in four hours wins work. Nobody cares what the prototype is built on.

There’s a fourth, less obvious one: internationalisation. Mature multipurpose themes have been through WPML and Polylang compatibility testing that you will absolutely get wrong the first time. If the project needs proper multilingual structure and hreflang, inheriting a tested setup saves days.

The case against, by failure mode

Content lock-in. This is the one that actually costs money. When your layout lives in shortcodes or builder JSON inside postcontent, switching themes in 2029 means re-entering every page by hand. We quoted a migration last year at 60 hours purely because 140 pages were full of [vcrow][vc_column width="1/2"]. The theme licence cost $59. The exit cost was five figures.

Update roulette. Major version bumps on big themes change option keys, rename CSS classes, and occasionally restructure the header builder entirely. If you have 300 lines of child theme CSS targeting .header-wrap .nav-inner, you find out the hard way. Pin the version, test on staging, and budget for it.

The 80 percent trap. The theme does 80 percent of what the client asked for. The last 20 percent requires fighting the options panel, and you end up writing more override code than you would have written building the feature from scratch. The warning sign appears early: if in week one you’re reaching for !important more than twice, the theme is wrong for the brief.

Performance ceilings. You can optimise a bought theme a long way. You cannot optimise it past its own architecture. If the theme renders every section inside four nested wrapper divs with inline styles, your CLS and your CSS specificity war are both baked in.

Evaluate any theme in 30 minutes

Forget the demo gallery. Here’s the protocol we run before committing to a theme on a client project.

Step 1: weigh an empty page. Install on a clean WordPress, activate the theme, publish a page containing one paragraph. Load it and measure. Chrome DevTools, disable cache, filter by CSS and JS.

# Quick headless check of total transferred bytes for CSS and JS
npx lighthouse https://staging.example.com/blank-test/ \
  --only-categories=performance \
  --throttling-method=devtools \
  --output=json --output-path=./report.json

Then pull the resource summary
node -e "const r=require('./report.json');console.log(r.audits['resource-summary'].details.items)"

Our threshold: under 150 KB combined CSS and JS, uncompressed, on a page with nothing on it. Between 150 and 400 KB means you’ll be dequeuing things. Over 400 KB, walk away unless the client is paying for the demo, not the performance.

Step 2: check what you can turn off. Look for conditional enqueues in the theme source. Grep for it:

grep -rn "wpenqueuestyle\|wpenqueuescript" wp-content/themes/yourtheme/ \
  --include="*.php" | wc -l

Then check how many sit inside a conditional
grep -rn -B3 "wpenqueuescript" wp-content/themes/yourtheme/inc/ \
  --include="*.php" | grep -c "if ("

If the ratio is poor, you’ll be doing this in your child theme, which works but is fragile across updates:

addaction( 'wpenqueue_scripts', function () {
    // Only ship the slider bundle where a slider can actually render.
    if ( ! isfrontpage() && ! ispagetemplate( 'template-slider.php' ) ) {
        wpdequeuestyle( 'theme-slider' );
        wpdequeuescript( 'theme-slider' );
    }
    // Legacy icon set kept for backwards compat; we use the v6 sprite instead.
    wpdequeuestyle( 'theme-fontawesome-4' );
}, 100 ); // priority 100: after the parent theme has enqueued

Step 3: inspect the stored content. Build a page with the theme’s own tools, then look at it in the database:

wp db query "SELECT LEFT(postcontent, 400) FROM wpposts WHERE ID = 42;"

If what comes back is clean HTML or core block comments, you can leave. If it’s a wall of proprietary shortcodes or base64, you now know your exit cost. Decide with that number in front of you.

Step 4: check the theme’s relationship with the block editor. In 2026 a theme that still fights theme.json is a theme with a short remaining life. If you’re unclear on what that boundary looks like, our breakdown of block themes versus classic themes covers what actually changed for developers.

The approach we actually ship

We stopped treating this as binary around 2023. The pattern that holds up: buy the system, own the content layer.

1. Use the theme for chrome. Header, footer, navigation, archives, WooCommerce. The parts that are genuinely generic and genuinely annoying to build.
2. Own the repeating content. Anything the client will create more than ten of (case studies, team members, products, locations) gets a registered post type with ACF or native block patterns, rendered by a template file you wrote. Not builder pages.
3. Use builder pages only for one-offs. The homepage, the about page, a campaign landing page. Pages nobody duplicates.
4. Keep forms outside the theme. Theme-bundled form modules are the most commonly abandoned part of these products. Use a dedicated plugin or, on static and hybrid builds, point the markup at an endpoint like WebForms and keep your form logic independent of whatever theme ships next year.
5. Write down the dequeue list. Literally a comment block at the top of the child theme’s functions.php listing what you turned off and why. The next developer, possibly you, will need it.

If you want the multipurpose breadth without the plugin stack, CanvasWP was built around this exact constraint: the demo library and layout system, but with asset loading scoped so an empty page stays light. That’s the trade we’d argue is worth paying for in any theme you consider, ours or anyone else’s.

When to skip all of this and build custom

Build custom when any two of these are true: the site has a content model that doesn’t map to pages and posts, the client has an in-house developer, the roadmap runs past 18 months, or performance is a contractual requirement rather than a preference. Build custom when the design is genuinely original too, because fighting a theme into an unfamiliar shape costs more than starting from a modern starter workflow.

Don’t build custom because a bought theme feels unprofessional. That’s ego, and clients don’t pay for it. We’ve shipped sites on commercial themes that outperform bespoke builds, because the time saved went into image optimisation, caching and content instead of reinventing a mega menu.