I measured 49 of my own WordPress builds against 20 theme demos. The demos lost.

Ernest K. — Tue, 13 Oct 2026 18:48:35 +0000

I've been building WordPress sites for small businesses for a long time. No page builders, no ThemeForest themes - custom templates, a short plugin list, done. I've always said this approach is faster and easier to maintain. At some point "I've always said" stopped being good enough, so I measured it.

Full research here https://advancedwebdesigner.com/research/wordpress-development-research/

On 19 April 2026 I ran PageSpeed Insights on 49 live sites I built between 2018 and 2026, and on 20 public demo sites for popular themes and page builders (The7, JupiterX, WoodMart, Bridge, TheGem and others, on Elementor or WPBakery).

This post is the short version for developers. Full tables and methodology are on the research page, and the paper is archived on Zenodo (DOI: 10.5281/zenodo.19697029).

First, the bias - and which way it runs

The comparison set is theme demos, not real client sites. Demos are the theme authors' own showcase installs: clean content, minimal plugins, usually good hosting. Real sites built on those themes almost always perform worse.

So the setup favours the templates. Keep that in mind for every number below.

I also split my own 49 sites honestly. 11 of them are "unoptimised" - older builds where the client wanted bespoke design and performance wasn't part of the brief, or sites nobody has touched in years. They're reported separately rather than hidden.

The headline numbers

Show Image

Group n PSI mobile avg Sites 90+ mobile
Custom, optimised 38 89.9 24 / 38
Custom, unoptimised 11 65.2 0 / 11
Template / builder demos 20 53.9 0 / 20

Roughly 36 points apart on mobile. And not one of the 20 demos scored 90 or above. These are the theme authors' best presentation of their own product.

Core Web Vitals on lab data (LCP ≤ 2.5s and CLS ≤ 0.1, INP left out because field data was too sparse):

Custom optimised: 45% pass
Custom unoptimised: 0% pass
Template demos: 10% pass

Half the demos (50%) had LCP over 4 seconds. On the optimised custom side that was 13%.

CLS is where the gap is widest

Show Image

28 of 38 optimised custom sites recorded CLS of exactly 0.00. On the demo side, 3 of 20.

This one doesn't surprise me much. When you write the templates yourself, you know the dimensions of everything. Images have width and height, fonts are handled deliberately, nothing gets injected above the fold after load. Builders stack wrappers, sliders and late-loading widgets, and something always moves.

INP pointed the same way (82ms average custom vs 152ms demos), but only 5 custom sites and 11 demos had field data. Treat that as a hint, not a finding.

The builder isn't really the variable

Two themes in the demo set exist in both a WPBakery and an Elementor version:

Buconz: 51 (WPBakery) vs 47 (Elementor)
Essentials: 75 (WPBakery) vs 78 (Elementor)

A few points either way. Switching builders doesn't fix much. The ceiling seems to be set by the theme architecture - the global CSS and JS, the abstraction layers, the markup - not by which builder sits on top.

Plugin count tracks performance decline

Show Image

63% of my sites run 10 or fewer plugins. The optimised group averages 9.3 plugins, the unoptimised group 13.6.

The worst site in the whole portfolio scored 50 on mobile with a 10.5 second LCP. It runs 38 plugins and hasn't been updated in years. Custom code didn't save it. Which is the honest takeaway here: "custom" isn't magic, discipline is.

Big sites don't break it

The usual objection is that custom builds are fine for brochure sites but fall over at scale. Three of the larger sites in the sample:

Pages PSI mobile LCP
2,832 (e-commerce catalogue) 90 0.64s
11,342 (news archive) 91 2.8s
585 (construction products) 90 1.14s

Not perfect, but scale clearly isn't the problem.

Maintenance - the part clients actually feel

This isn't timer data, it's my own records from notes and invoices over 12-24 months, so take it as practitioner observation:

Custom builds: around 1-2 hours per site per year
Emergency fixes across all 49 sites in 24 months: zero
Template sites I see through audits and rescues: closer to 8 hours a year, before anything actually breaks

The most common cause of breakage I see on template sites isn't WordPress. It's the host bumping PHP or the database version and exposing old builder code that was quietly hanging on.

Two before/after migrations

Show Image

Camille Beauté: 39 → 96
Eram Service: 43 → 89

Two sites, not a controlled sample. They show what's recoverable, nothing more.

What this doesn't prove

Worth being upfront, because someone in the comments will be anyway:

It's one practitioner's portfolio. Not random, not representative of WordPress as a whole
n=49 and n=20 is fine for direction, not for statistics
PSI lab scores move a few points between runs, and these are single runs
My CWV pass rate uses lab data. Google's real assessment uses 28-day field data, so don't compare my 45% directly with the Web Almanac's 40% WordPress field pass rate - they're not the same measurement
Construction is overrepresented (10 of 49 sites)

And the fair point on the other side: a template build is much cheaper and quicker up front. For some businesses that's the right call. I just think it should be a conscious trade-off, not a default nobody questioned.

If you want to dig in
Full data tables, sector breakdown and methodology: Custom WordPress development research
Paper on Zenodo: 10.5281/zenodo.19697029
The practical side of how I get there: WordPress speed optimisation checklist

I'm planning to re-measure the same sites over time to see how they drift. If you've got your own numbers from builder vs custom builds, I'd genuinely like to see them - especially if they disagree with mine.

DEV Community: Ernest K.

I measured 49 of my own WordPress builds against 20 theme demos. The demos lost.